How to Choose Shadowrocket Global Routing: Config, Proxy, and Direct Explained

At a Glance

When you already have service details and access information, Config is usually the right choice for everyday use: the active configuration determines how each request is handled. Use Proxy to temporarily route traffic through a proxy for comparison and troubleshooting, or Direct to test a direct connection. This guide covers what each mode affects, how to switch, and how to interpret results—so you can distinguish an active connection from a request that actually uses a proxy.

Choose a mode: Config follows rules; Proxy and Direct provide comparisons

Shadowrocket's Global Routing setting determines how requests within its handling scope are routed. It is not a server list and does not provide access to a service. Before choosing a mode, make sure usable server details are already available in Home. Without them, switching to Proxy will not create a working connection.

Config

Recommended

Use the rules and policies in the active configuration. A match may route to PROXY, DIRECT, REJECT, or a policy group defined in the configuration. If no earlier rule matches, the FINAL rule applies.

Best for: everyday use with established routing rules

Proxy

Route ordinary requests within its handling scope through a proxy instead of deciding their destinations rule by rule as Config does. The selected server must still be usable, and traffic exclusions set by the system or configuration still apply.

Best for: briefly verifying the proxy route and checking whether rules affect the result

Direct

Use a direct connection for ordinary requests within its handling scope, without forwarding them through the selected proxy server. The connection can remain enabled, so Direct does not mean the connection is off.

Best for: comparing access over your current network without a proxy

“All traffic” here does not mean forcibly taking over every system connection on the device. What Shadowrocket handles also depends on system routing, exclusions in the configuration, and how the app works. DNS has separate settings, so the mode name alone does not tell you which DNS resolver is used or how every DNS request is routed.

If you see Scene in Global Routing, treat it as a separate entry point for scene-based settings, not another name for Config. This guide establishes a baseline using the three clearly defined modes. For troubleshooting, select one mode manually first, then check whether a scene change altered the state.

How to switch: note the current settings, then establish a fresh connection

Find the mode under Home → Global Routing. Before switching, note the current mode, selected server, and configuration file in use under Config so you know what to restore after testing. The configuration file determines the rules; server details determine the proxy connection parameters. They are not interchangeable.

Check the server in Home. Make sure the selected entry uses access details you already have and are authorized to use. An entry appearing in the list does not mean it is currently working.
Open Global Routing. Choose Config for everyday rule-based routing, Proxy to test the proxy route, or Direct to check a direct connection.
Return to Home and check the connection toggle. Changing modes alone does not establish a connection. Reconnect if needed so the next test starts from a known state.
Make a fresh request. Close and reopen the test page, or restart the connection in the app you are testing. Do not rely only on content that is already playing or on an existing long-lived connection.
Restore your settings afterward. Return to your usual mode and confirm that the selected configuration and server are still the ones you expect.

If the connection turns back on automatically after you switch it off, check the trigger conditions under Settings → On Demand. On Demand controls when a connection starts; Global Routing controls how traffic is routed after it starts. An automatic connection does not mean the selected mode is right for your test.

Why Config works for everyday use: check the rules, then FINAL

Config lets you handle destinations differently instead of assuming that a particular type of site always uses a particular route. The outcome depends entirely on the active configuration. Rules are generally checked in order, and the first matching rule determines the policy. The same Config mode can therefore produce different results with a different configuration.

3 modes

Modes compared in this guide: Config, Proxy, and Direct

4 rule types

Examples below: DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL

1 rule

The FINAL fallback rule at the end of the example

The snippets below illustrate rule order. They are not a complete configuration or usable service details. The example domains are for demonstration only. When editing, keep a copy of the original file in Config before changing the target configuration.

[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: Routes example.com and its subdomains through PROXY. This does not mean other domains will also use the proxy.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Matches the specified IPv4 address range. no-resolve means the app will not initiate a domain lookup just to evaluate this IP rule.
GEOIP,CN,DIRECT: Matches the destination IP using the GEOIP data available to the app. It does not use the page language or website name.
FINAL,DIRECT: Uses a direct connection when no earlier rule matches. Changing it to FINAL,PROXY also changes the default route for unmatched requests.

REJECT denies a request; it is not the same as selecting an unavailable server. If the active configuration has a matching REJECT rule, that request may still be denied in Config even when the server test succeeds. For custom policy groups, check which option is selected inside the group rather than relying only on the group name in the rule.

Diagnosis: Proxy works but Config does not? Check the matching rule first

Keep the server and network unchanged. Check earlier rules matching the destination, the corresponding policy group, and FINAL before re-entering protocol settings. This comparison narrows down what to inspect, but you may still need DNS and connection logs to identify the cause.

Using Proxy and Direct: compare results while holding variables constant

Proxy is useful for temporarily bypassing rule-by-rule routing decisions; Direct provides a baseline for connecting over your current network. Neither guarantees faster speeds. If performance drops in Proxy, the proxy route or server load may have changed. If a site will not open in Direct, your current network may not be able to reach it directly. That alone does not mean the app configuration is broken.

Comparison plan: same destination, same network, same server

Test the proxy route: Proxy

Note whether you are on Wi-Fi or cellular, and do not switch networks during the test.
Keep the selected server unchanged, choose Proxy, and establish a fresh test connection.
Visit the same destination and note what happens, such as a successful connection, a timeout, or a dropped connection.
Switch back to Config and try again. Check whether the difference consistently follows the selected mode.

Test the direct route: Direct

Choose Direct, then make a fresh request to the same destination.
Record whether a connection is established; do not rely only on whether cached page content appears.
To check what happens when the connection is fully disabled, turn off the connection toggle and test separately.
When finished, restore Config so a temporary setting does not become your everyday mode.

Change only one mode at a time. Switching networks, servers, and DNS settings together makes the results much less useful for pinpointing the cause.

Use the sequence below to narrow down the cause. These are troubleshooting scenarios, not claims of completed test results. Use the results observed on your device during each test.

Observed result	Check first	Next step
Proxy works; Config does not	Matching rules, policy group, FINAL, and DNS differences	Return to Config and check the rules for the destination. Confirm that DIRECT or REJECT is not matching.
Direct works; Proxy does not	Selected server, authentication, and transport settings	Check the address, port, protocol, and TLS settings against the access details you already have.
All three modes fail	Basic network connectivity, destination status, DNS, and system time	First check whether other destinations are reachable, then troubleshoot one item at a time. Avoid changing multiple settings at once.
The result does not change immediately after switching	Cache, connection reuse, and whether the test used a fresh request	Reconnect and repeat the test using the same steps.

Keep the layers separate: protocol, subscription, and On Demand

Global Routing answers “Which route does this request take?” Protocol settings determine “How is the proxy connection established?” Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard each use different parameter formats. Changing modes will not fix incorrect authentication details or convert one protocol into another.

Address and port: Enter these as provided in the service details you already have. Even if an entry uses port 443, that alone does not identify its protocol—and it does not mean you should change other ports to 443.
Importing and updating a subscription: This retrieves or refreshes server details you already have. A successful update only confirms that the retrieval process completed. It does not prove that every listed entry works or that the active Config rules are set as expected.
Config: Check the active configuration file, rule order, and policy destinations. Importing server details does not configure routing rules.
Settings → On Demand: Check the automatic connection conditions. Verify these separately from the selection under Home → Global Routing.

After switching between Wi-Fi and cellular, first confirm that the current mode is still the one you expect, then run a test. If you use Scene or other automation, check what it actually changes. Do not mistake a settings change caused by the environment for random behavior in the same rule.

FAQ: Why is traffic taking the wrong route when the connection is on?

The connection is on. Why are some requests still going direct?

Go to Home → Global Routing and check whether Direct is selected. If Config is selected, check the matching rules and FINAL under Config. An active connection only indicates the connection state; it does not mean every request uses PROXY.

Does selecting Config automatically set up routing rules?

No. First confirm which configuration file is active, then check its rules and policies. If the configuration ends with FINAL,DIRECT, requests that match no other rule will connect directly. Config does not include a routing setup that works for everyone.

Can I leave Proxy selected after a temporary test?

You can keep it selected if that is what you need, but Proxy will no longer route requests according to Config's individual rules. If you normally rely on DIRECT for some destinations, return to Home → Global Routing → Config after testing and verify the result with a fresh request.

Is Direct equivalent to turning off the connection toggle for testing?

No. Direct keeps the app connection and its associated handling in place; turning off the toggle is a different state. Test both separately if you need to check whether the app connection environment is involved. Check Settings → On Demand during testing so its conditions do not turn the connection back on.

The connection still fails after a subscription update. Should I switch straight to Proxy?

First check in Home which updated entry is actually selected, then verify the service details you already have against the test result. Proxy can be useful for a brief comparison, but changing modes will not fix an incorrect address, port, or authentication details if the proxy connection itself fails.

For everyday use, follow this sequence: confirm the active configuration is correct, then use Config. If something goes wrong, keep the network and server unchanged and compare briefly with Proxy and Direct. Finally, restore your usual settings. Recording the mode, destination, and result for each test makes it easier to find the cause than changing several settings at once.