Shadowrocket Global Routing: Config, Proxy, or Direct?

At a glance

When you have a working service and configuration and need traffic routed by destination, start with Config. Use Proxy to temporarily bypass Rule-based decisions and test the proxy path. Use Direct to compare results over your local network. This guide explains how each option handles requests and walks through switching modes, checking rules, and troubleshooting. Shadowrocket is a paid client; purchasing the app and obtaining connectivity service are separate. The steps below assume you already have your own service and subscription.

1. Global Routing controls traffic handling, not the connection switch

Open Global Routing on Home and check which option is selected before deciding how a request should be handled. Config uses the Rules in the active configuration to choose a policy. Proxy sends traffic handled by the client through the proxy route. Direct sends traffic handled by the client over a direct connection. “All” refers to traffic actually handled by the client; it does not mean every type of system communication on the device must take the same route.

The connection switch starts or stops the client connection. Global Routing determines how traffic is routed while the connection is active. Selecting Proxy does not establish a connection, and selecting Direct does not turn the connection off. When troubleshooting, check these separately so you don’t confuse connection status with routing mode.

3 options

Options covered in this guide: Config / Proxy / Direct

2 steps

Path: Home → Global Routing

4 types

Examples below: DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL

You may also see Scene in Global Routing. It relates to scene-based routing and should not be assumed to represent a fixed outbound route alongside Config, Proxy, and Direct. This guide covers only the three direct options. If you use Scene, note its settings before testing, then explicitly switch to the option you want to compare so scene conditions don’t affect the results.

2. When to choose Config, Proxy, or Direct

Config

Recommended

Uses the Rule order in the active configuration to choose a policy. Requests matching DIRECT connect directly; requests matching PROXY use the proxy. Rules can also specify other valid policies in the configuration. Requests that don’t match are handled by fallback settings such as FINAL at the end of the list—they don’t automatically go direct.

Use when: You have a working configuration and want to route traffic by destination for everyday use.

Proxy

Doesn’t select a direct or proxy route for each destination based on Rules. Instead, it uses the proxy route for traffic handled by the client. This is useful for temporarily removing Rules from a test, but it still depends on the selected service’s address, credentials, protocol settings, and availability.

Use when: You temporarily want all traffic handled by the client to use the proxy route, or want to compare results with Config.

Direct

Connects to the destination directly over your local network, without forwarding traffic through the selected proxy server. Use it to check the direct route. Whether the destination is reachable still depends on your network, DNS resolution, and the destination service’s status.

Use when: You want to check local network access or compare the direct and proxy routes to the same destination.

Config is recommended when the configuration meets your needs—not because it’s inherently faster than the other options. If FINAL points to PROXY, many requests that don’t match earlier Rules will still use the proxy. If FINAL points to DIRECT, unmatched requests connect directly. To understand why a site took a particular route, check the mode, the Rules, and the final policy together.

Proxy and Direct are bounded troubleshooting tools, not guarantees of connectivity. If a request still fails in Proxy, the issue could be the service settings, resolution, transport connection, or destination itself. If it fails in Direct, that alone doesn’t prove the configuration is broken.

3. How Config selects a policy using Rules

Open Config, make sure the configuration you need is selected and active, then review its [Rule] section. Rules are evaluated in order, and the first applicable match determines the request’s policy. The example below illustrates syntax and order; it is not a complete replacement for your configuration. example.com is a sample domain, and you must provide your own service for PROXY.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

DOMAIN-SUFFIX,example.com,PROXY: Matches example.com and its subdomains, such as www.example.com, and uses PROXY when matched.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Uses DIRECT for this IPv4 address range. no-resolve means this IP rule won’t trigger an additional domain lookup; it does not disable DNS globally.
GEOIP,CN,DIRECT: Matches CN based on the destination IP’s geographic data and selects DIRECT. It does not determine the match from webpage language, domain suffix, or the user’s location.
FINAL,DIRECT: Place this at the end of the list to route requests that didn’t match earlier Rules through DIRECT. Changing it to FINAL,PROXY also changes the fallback route.

In this example, a request that matches the first rule by domain is assigned PROXY and won’t continue to GEOIP for another decision. IP rules also depend on whether the client can obtain the destination IP and on resolution settings. When checking Rules, distinguish domain matches from IP matches; don’t rely on the text order alone.

4. Switch modes on Home and compare results for the same destination

Before testing, note the current mode, active configuration, and selected service. Change just one factor at a time so the results are comparable. Use the same destination that you’re authorized to access; there’s no need to add a service or change protocol settings.

Open Home, make sure your own working service is imported, and check which server is selected. Then open Config and confirm the active configuration.
Return to Home → Global Routing, select Config, and make sure the connection switch is in the required state.
Visit a known destination. Note whether it loads and which policy or outbound route appears in the request logs available in the app.
Switch to Proxy. Keep the same service, network, and destination, then send the request again. Avoid reusing an existing browser connection.
Switch to Direct and send a request to the same destination. After comparing results, return to Config and check the connection status again.

If Config fails but Proxy works, the destination is reachable through the current proxy route, but that alone doesn’t prove a Rule is wrong. Check the matching Rule, its policy target, and DNS-related settings in Config. If Config uses a different policy group or server, note those differences before deciding whether the issue is with the Rules.

If all three options fail, focus first on the local network, destination availability, service settings, and resolution rather than repeatedly changing FINAL. Cached pages or persistent connections can affect what you see. Start a fresh request after each switch, reconnect if prompted in the app, and compare the newly generated logs.

Comparison checklist: Check the rule-based and local routes separately

Compare Config and Proxy

Use the same destination and proxy service.
Check which Rule actually matches in Config.
Check whether the Rule specifies a different policy or server.
Record the result of a new request; don’t reuse an existing connection.

Compare Direct and Proxy

Keep the current Wi-Fi or cellular network unchanged.
Check access over both the direct and proxy routes.
Record resolution failures separately from connection failures.
When testing is complete, restore the Config used for everyday routing.

Comparisons help narrow down the cause; a single success or failure doesn’t prove that the same route will work for every destination.

5. How Global Routing relates to On Demand, protocols, and subscriptions

Settings → On Demand manages connection behavior based on configured conditions. Global Routing selects how traffic is handled while the connection is active. If you need automatic connections, check the On Demand conditions and the current Global Routing option separately. Setting up On Demand won’t verify that your Rules are complete or supply server credentials.

Home: Check the selected service, connection status, and Global Routing to confirm how requests are being handled.
Config: Check the active file, Rule order, and policy names to see how requests are routed in Config.
Settings → On Demand: Check the conditions that trigger a connection. If it reconnects after you disconnect manually, start by reviewing these settings.
Protocol settings: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe how a service connects. Selecting Proxy won’t change the protocol or fix incorrect settings.
Subscription updates: After updating an existing subscription, check that the selected service is still valid and that the policies referenced in your configuration still point to available options.

Importing a single service, updating a subscription, and switching configuration files are different operations. Subscriptions typically maintain service entries, while configuration files may also include Rules and other settings. Updating a subscription doesn’t necessarily apply a new set of routing Rules. Review the actual contents after an update, then check your selections in Home and Config.

Don’t start troubleshooting by changing ports at random. The server port, TLS, transport method, and other settings must match the information for your existing service. Global Routing changes how traffic is routed; it can’t make an incorrect server address or port valid.

6. Common questions: When switching modes doesn’t help

I added DIRECT, so why is the request still going through the proxy?

First open Home → Global Routing and make sure Config—not Proxy—is selected. Then open Config, check which file is active, and see whether an earlier Rule matches the destination. Check the app’s logs for a new request; don’t use a connection from before the switch to judge the new Rules.

Config works, but Proxy doesn’t. Should I change the Rules?

Compare the actual outbound routes for both requests first. Config may route the destination through DIRECT or use a service assigned to another policy. Check the settings and availability of the service currently selected on Home. Keep the existing Rules until you understand the difference in outbound routes, and avoid changing multiple factors at once.

Why is the connection indicator still on when Direct is selected?

Direct is a routing mode, not a disconnect button. To stop the client connection, use the connection switch on Home. If it reconnects after you disconnect, check the trigger conditions in Settings → On Demand, then verify the connection status in both the system and the app.

What should I do if routing stops working as expected after a subscription update?

First check whether the service previously selected on Home is still available, then review the policy references in Config and confirm which file is active. Make sure Global Routing hasn’t been left in Proxy or Direct from a temporary test. Then send a new request to the same destination and check which Rule matched.

Should Proxy stay on all the time?

If you need to route destinations differently, use a Config you’ve checked. Choose Proxy only when you specifically need all traffic handled by the client to use the proxy route. After testing, return to Home → Global Routing → Config and check that the FINAL fallback matches your needs.

Use this order for a final check: connection status, Global Routing, active configuration, matching Rule, and actual outbound route. This helps separate “not connected,” “wrong mode,” “no Rule match,” and “service unavailable.” For related terms, see the quick reference glossary.

Get Shadowrocket and configure it for the first time

Shadowrocket is a paid client for Apple platforms and is available only on the App Store. Verify the developer, Shadow Launch Technology Limited, the official app icon, and app ID 932747118. The one-time app purchase is separate from any connectivity service plan. iPhone and iPad are the primary platforms; compatibility and system requirements for other Apple devices are listed on the App Store page. This site does not provide, sell, or recommend nodes or subscriptions.

Verify Shadowrocket on the App Store View the setup guide