Shadowrocket’s Global Routing setting determines how connections are routed; it does not provide servers. This guide assumes you already have your own service provider and subscription. It explains when to use Config, Proxy, or Direct, how to switch between them, and how rule matching works. Follow a troubleshooting process that changes one setting at a time to distinguish server connection problems from routing-policy mismatches, then restore your usual configuration when testing is complete.
The three Global Routing modes: use Config day to day
In short: use Config for everyday routing when you have a working server and configuration. Switch temporarily to Proxy if you suspect a rule is sending a site down the wrong route, or to Direct to check whether the current network can reach a destination directly. These modes change routing behavior; they do not change the server address, port, password, or protocol settings.
Config: Route traffic by the active configuration
RecommendedUses the rules in the active configuration to select DIRECT, a proxy, or another defined policy. Connections that do not match earlier rules are handled by fallback rules such as FINAL; a rule miss does not necessarily mean a direct connection.
Best for: Everyday use when connections need different handling based on domain or destination IP.
Proxy: Route traffic through a proxy
Routes general connections handled by Shadowrocket through a proxy, making it easier to bypass regular routing rules temporarily for comparison. The server must still be valid, and the proxy protocol and transport settings must be correct.
Best for: Temporarily checking whether the proxy works and identifying routing differences in Config.
Direct: Connect without a proxy
Makes direct connections for general traffic handled by Shadowrocket, without forwarding it through a proxy server. This does not turn off the connection toggle or guarantee that the current network can reach every destination directly.
Best for: Comparing direct access on your current network and checking whether only the proxy route is failing.
“All” here describes the routing mode; it does not mean every packet on the device must take the same path. System routing, exclusions, local network access, and DNS settings can still affect what happens. If the menu also shows Scene, that option applies settings by scene. This guide keeps the scene unchanged and compares only Config, Proxy, and Direct to avoid automatic switching affecting the results.
Home → Global Routing: Check these three settings before switching
Global Routing, the selected server, and the active configuration are separate choices. Setting Global Routing to Config does not import or enable the configuration you need. Selecting a server in Home does not mean every policy group in Config will automatically use it. With configurations that have multiple policy groups, check which policy and member the connection in question actually uses.
- Check the server: Go to Home and confirm that your existing server has been imported, the required entry is visible, and its settings are complete. To add one manually, use Add Server and enter the protocol and port from your existing details. Import and update subscription content through Subscribe.
- Check the configuration: Go to Config and make sure the configuration you intend to use is active. If you need to edit it, keep a copy first so temporary test rules do not overwrite your everyday configuration.
- Select a mode: Return to Home → Global Routing and choose Config, Proxy, or Direct. Then return to Home to confirm the selected mode is what you expect.
- Start a fresh test connection: Make sure the connection toggle is on, then reopen the destination. Long-lived connections established before switching may keep using the old route. If needed, close and reopen the target app; restarting a connection interrupts active sessions, so avoid doing this during calls or downloads.
How Config matches rules: order and the FINAL fallback
Config depends on the rules and their order. In a standard rule list, connections are checked from top to bottom, and the first matching rule determines the policy. That is why specific domain rules usually belong above broad region or IP-range rules. A domain appearing somewhere in the configuration does not guarantee that its rule takes effect; check for an earlier matching rule.
The [Rule] snippet below illustrates rule order; it is not a complete configuration that can replace your existing file. example.com is an example domain. Before using this, confirm that the PROXY policy in your configuration is available. If your configuration uses a custom policy group name, keep its actual name and definition.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY: Matchesexample.comand its subdomains, then applies the PROXY policy. It does not match every URL that happens to contain this string.IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Matches the specified destination IPv4 range and connects directly.no-resolvemeans not to trigger a DNS lookup specifically to match this IP rule; it does not disable DNS for the entire client.GEOIP,CN,DIRECT: Selects DIRECT based on the destination IP’s region in the GeoIP database, not on the webpage language or domain suffix.FINAL,PROXY: Handles connections that did not match earlier rules. If the existing file usesFINAL,DIRECT, the fallback result is different. Check your everyday routing needs before changing it.
Websites often make requests to multiple domains for pages, images, sign-in, and APIs. If the homepage loads but sign-in fails, check the domains and policies for the failed requests rather than adding a rule only for the main domain. IP rules and GEOIP also depend on DNS results. Test DNS changes separately from routing-rule changes so you can tell which one affected the result.
Compare Proxy and Direct: separate rule issues from connection issues
For a useful comparison, keep the network, destination, and server the same; change only Global Routing. Do not update a subscription, switch Wi-Fi, change DNS, and select another server in the same test. Even if access is restored, you will not know what fixed it. The results below are troubleshooting clues, not guarantees for every network or predetermined speed-test results.
Comparison: Keep the destination fixed and test Proxy and Direct separately
The destination works in Proxy
- Record the destination and result, then switch back to Config and retry the same request.
- If only Config fails, check the matching rule and the policy group member actually in use.
- If Config uses a different server, select the same server in both modes before comparing.
- Check the connection log for the destination and policy to see whether an earlier DIRECT rule matched.
The destination works in Direct
- This shows that the current network has a working direct route to that destination.
- If Proxy fails, check server connectivity, authentication settings, and restrictions on accessing the destination.
- For example, if your existing settings specify port 443, check the port in Add Server rather than changing it to a commonly used value.
- Also check that TLS, Server Name, and transport settings match your existing details.
Bottom line: Comparisons help narrow down the cause. Proxy working does not prove that every configuration setting is correct, and Direct working does not prove that the proxy server is down. Restore Config when testing is complete.
If both Proxy and Direct fail, first check whether the device can open other known-working pages, then look at the destination service, DNS, and network restrictions. If only one app feature fails, record the specific action—for example, “the page loads, but sign-in times out after submission.” That is more useful than a vague report that the network is down.
Subscribe, protocols, and On Demand: Use the right troubleshooting path
Updating a subscription retrieves server details from a subscription you already have; it does not ensure that the active configuration contains suitable routing rules. Likewise, changing a domain rule in Config will not fix an incorrect server password. Before troubleshooting, check server details, configuration rules, and connection triggers as three separate layers.
| What to check | Location or details | What to verify |
|---|---|---|
| Server details | Home / Add Server / Subscribe | The address, port, authentication, and transport settings match your existing details. After updating a subscription, check that the entry is still valid. |
| Routing and configuration | Home → Global Routing；Config | The correct mode is selected, the intended configuration is active, and matching rules point to the expected policy. |
| On-demand connections | Settings → On Demand | Check whether the current trigger conditions will reconnect, and whether automatic behavior is changing the state during testing. |
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are protocol names, not Global Routing modes. Selecting Proxy will not change VLESS to Trojan or fill in missing authentication details. Enter protocol settings according to your existing details. For TLS connections, also check certificate validation, Server Name, and transport fields. Disabling validation should not be treated as a routine fix.
- If the connection turns back on automatically during testing, check Settings → On Demand and note the existing conditions. Temporarily disable the relevant conditions if needed, then restore them when you are done.
- If a server name or entry changes after updating a subscription, check the policy group’s member references to avoid rules pointing to a selection that no longer exists.
- If the connection is established but the destination fails, compare routing modes first. If the subscription request itself fails, check whether the subscription URL is valid separately instead of repeatedly rewriting all the rules.
Common Global Routing questions and recovery checks
I selected Config. Why does it look like every site still uses the proxy?
Open Config and check the active file’s rules and FINAL. If the destination does not match an earlier direct rule and the last rule is FINAL,PROXY, proxy routing is the expected result. Check the connection log to see whether a broad rule or policy group selection is overriding what you expected. Do not infer the route for every request from whether the homepage loads.
Proxy works, but Config times out. Should I import the subscription again?
Not yet. Keep the same server selected and compare the two modes. Check the rule matching the destination in Config and the policy group it uses. If the rule sends traffic to DIRECT or to another unavailable member, adjust that rule or member, then start a fresh connection and test again. Reimporting a subscription may change entries and add more variables to troubleshoot.
The connection indicator is still on after I select Direct. Did the switch fail?
Not necessarily. Direct controls routing; it does not turn off the client connection. Go to Home → Global Routing and confirm that Direct is selected. To stop the connection, use the toggle on Home and check whether Settings → On Demand will trigger another connection under its current conditions.
I changed a rule, but a video that is already playing still uses the old route. What should I do?
Stop playback and close the related page, then reopen it to test with a new connection. Existing connections may continue using the route they started with. If needed, reconnect the client when doing so will not interrupt important tasks. After testing, restore Global Routing to Config and confirm that any temporary On Demand changes have also been reverted.
Keep a brief record of the test destination, network type, server used, results for all three modes, and the one rule you ultimately changed. Do not include subscription tokens, passwords, or full authentication URLs. If the same issue comes up again, you can review what you already found instead of changing every setting from scratch.