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

At a glance

For everyday use, choose Config in Shadowrocket when you have an enabled configuration that meets your needs. Use Proxy to temporarily route traffic through a single proxy path or compare results while troubleshooting; use Direct to test direct access. This guide is for users who have added their own provider subscription, can connect, but aren’t sure which mode to choose. It covers mode behavior, switching steps, rule order, and troubleshooting comparisons.

How the three modes differ: choose a routing behavior, then check the rules

Global Routing determines how Shadowrocket routes connections it handles. It is not a server protocol selector or a connection-speed setting. Changing Config to Proxy does not change Shadowsocks to VLESS, or automatically change the server address, port, or authentication details.

Config: Route according to the configuration

Recommended

Uses the rules in the currently enabled configuration to decide, in order, whether a connection uses DIRECT, PROXY, or a policy specified in the configuration. If no earlier rule matches, the final rule, FINAL, determines what happens; don’t assume unmatched connections will go direct.

Best for: everyday use with explicit routing rules.

Proxy: Use a single proxy route

Routes ordinary connections within the app’s handling scope through a proxy, rather than deciding the route rule by rule as Config does. Actual connectivity still depends on the selected server, DNS, protocol support, and network conditions.

Best for: temporarily using one proxy route or comparing results to troubleshoot routing.

Direct: Use a direct route

Connects ordinary traffic within the app’s handling scope directly to its destination, without using a proxy server as the exit. This does not turn off the connection toggle or remove the VPN configuration from the system.

Best for: checking the local network and testing whether a destination is directly reachable.

“All” is shorthand for what each mode does; it does not guarantee that every communication on the device follows that route. System traffic, tunnel coverage, exclusions, and existing connections can all affect what you observe. After switching modes, make a new request. Don’t judge whether the change worked based only on a video that is still playing or a page that was already open.

Use Config by default: check the configuration before changing modes

Config is the better everyday default when you need routing based on domains, IP addresses, or geographic conditions. It preserves different actions in the configuration, such as direct access, proxying, or rejecting a connection. Proxy and Direct are better suited to short-term comparisons. Whether Config behaves as expected depends on the enabled configuration and its rules—not on the mode name itself.

Check the server

Open Home and confirm that the selected server belongs to your own active subscription. Get the subscription link from your provider. Seeing a server list in the app only means connection details are present; it does not guarantee that the service is available.
Check the configuration

Open Config and confirm which configuration is enabled. Check its rules and the target of its final rule, FINAL. Don’t mistake a saved but disabled configuration for the one currently in use.
Choose a mode

Go to Home → Global Routing → Config. Return to Home to confirm the displayed mode, and make sure the connection toggle is on. The first time you connect, allow the VPN configuration when prompted by the system.
Test again

Reopen the destination and check the connection log for its domain, matched rule, and resulting policy. If the page reuses an existing connection, close it and open it again. If needed, reconnect when it’s safe to interrupt active tasks.

Home handles connection status and server selection, Config manages configuration files, and Settings controls app preferences. These are separate layers. Adding a Subscribe entry provides connection details; updating a subscription does not prove that all routing rules are fixed. When troubleshooting, check the currently enabled Config separately.

How Config matches rules: check the order, including FINAL

Read rules from top to bottom in their actual order in the configuration. The first match determines the action. DOMAIN-SUFFIX, GEOIP, and IP-CIDR are not automatically grouped into separate passes based on their names. Don’t check all domain rules first and IP rules in a separate round. FINAL handles connections that matched no earlier rule and should be placed last.

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

This is an example of rule order, not a complete file to replace your personal configuration with. The first rule routes example.com and its subdomains through PROXY. The second rule covers IPv4 addresses from 192.168.0.0 to 192.168.255.255. no-resolve means the app won’t actively resolve a domain to an IP address just to match this IP rule; it does not disable DNS resolution for the entire configuration.

4 rules

Example rules: DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL

/16

Example IPv4 range: 192.168.0.0/16

Last

FINAL handles connections that match none of the preceding rules

DOMAIN-SUFFIX: Matches a domain suffix, not an arbitrary substring. Also check whether the destination reaches rule evaluation as a domain name.
IP-CIDR: Matches an IP range. Whether the destination IP is known, and whether domain resolution is allowed for matching, can affect the result.
GEOIP: Uses geographic data associated with the destination IP—not the page language, website name, or user’s location.
FINAL: Specifies the action to take last. The example is FINAL,PROXY. If your configuration uses FINAL,DIRECT, connections that match no earlier rule will go direct.

If a destination takes the wrong route in Config, first check which rule matched instead of immediately adding a similar one. A new rule placed after an existing matching rule may never run. If a rule points to a custom policy, also check which server or action that policy actually selects.

Switch temporarily: change just one variable

Proxy and Direct provide routes you can compare. For a fair test, use the same device, network, destination, and server; change only Global Routing. If you also switch Wi-Fi or servers, you won’t know which change fixed the page.

Compare routes: one destination, two paths

Test with Proxy

Home → Global Routing → Proxy。
Keep the current server and make a new request to the destination.
Note whether it loads and whether a timeout occurs.
If it works, return to Config and check the rules, policy, and DNS.

Test with Direct

Home → Global Routing → Direct。
Keep the same network and revisit the same destination.
Check whether the destination is directly reachable on the current network.
If it works, check the proxy server and its exit route.

After comparing the results, switch back to Config. The test can help narrow down the cause, but one successful attempt does not prove that a rule or server is faulty.

Proxy does not guarantee faster access to every destination. Routing a service that is already reachable directly through a remote exit can add extra distance. Some local network services may also be unreachable through a proxy. Direct does not guarantee that every website will load either; it only tests direct access on the current network.

For payments, uploads, calls, or long downloads, finish the task before comparing modes. Existing connections may keep using their original route, or be interrupted when you switch modes or reconnect. Base tests on new requests, and distinguish between a page shell appearing and all of its resources finishing loading.

Still having problems after switching modes? Narrow down the cause by symptoms

A latency test returning a result does not mean that a page’s DNS, TLS, and resource requests are all working. A single page may connect to multiple domains, with the main page, images, and sign-in API matching different rules. Note the specific destination that failed rather than saying “the whole network is down.”

Test result	Check first	Next step
Config fails; Proxy works	Matched rule, selected policy, DNS route	Return to Config and check the rule for the failing domain. Make sure it isn’t using DIRECT or the wrong policy.
Proxy fails; Direct works	Current server, authentication details, exit reachability	Check the server address, port, and protocol fields, and confirm your subscription is active.
Both modes fail	Local network, destination service, DNS, and system connection status	First check whether the current network requires sign-in. Then check the destination’s DNS resolution and connection errors.
No change after switching	Existing connections, cache, Scene, and automatic connection conditions	Make a new request, check the mode shown in Home, and make sure automation conditions aren’t interfering with the test.

Troubleshoot On Demand separately from routing modes

Settings → On Demand configures automatic connection behavior when specified conditions are met, such as conditions related to the network. Global Routing determines how connections are routed after they’re handled by the tunnel. These are separate controls. If the connection status changes automatically during a test, check whether On Demand is enabled and review its conditions. Then check the mode shown in Global Routing; don’t mistake an automatic reconnection for a failed manual mode change.

Check DNS and protocol settings separately

If the log reports a resolution failure, first check the DNS settings in the current configuration and whether the DNS server is reachable. Switching to Proxy alone does not guarantee that DNS problems will be fixed.
If the server connection fails, check the protocol and authentication fields against your provider’s details. Parameters for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are not interchangeable.
If only local network devices are unreachable, check the destination address, IP range rules, and relevant tunnel settings. Don’t assume a local network address can be reached through a remote proxy.
When sharing troubleshooting details, include the mode, failed domain, rule action, and error type. Hide subscription tokens, passwords, and other authentication details.

Return to everyday use with a clear default

After troubleshooting, restore temporary changes one by one: select the server you normally use, enable the configuration you checked, set Global Routing back to Config, and test with a new request. If you keep Proxy or Direct enabled, note why so you don’t mistake it for rule-based routing next time.

To route traffic by destination: Choose Config and check the rule order and FINAL.
To temporarily use a single proxy route: Choose Proxy, then return to your everyday mode when the test is done.
To test direct access on the current network: Choose Direct. Don’t use it as a substitute for turning off the VPN.
To connect automatically: Check Settings → On Demand separately. Routing modes do not replace connection conditions.

If you change configurations or update your own subscription, confirm which server is selected and which configuration is enabled. For more on basic features, see Features and Settings. For information on managing an existing subscription, see Subscribe: Updating a Subscription. Keeping connection details, routing configuration, and routing mode as three separate layers makes troubleshooting easier than changing settings at random.