Shadowrocket Global Routing: Config, Proxy, or Direct?

At a glance

Shadowrocket’s Global Routing setting determines whether connections follow rules, use the selected proxy, or connect directly. This guide is for users with their own subscription or configuration who aren’t sure which mode to choose. First, understand Config, Proxy, and Direct; then compare them using the same destination and restore your usual setting. Switching modes doesn’t change the protocol or replace a valid server configuration.

What Global Routing controls—and what it doesn’t

The mode selected under Home → Global Routing determines how connections handled by Shadowrocket choose an outbound route. Config applies the rules in the active configuration; Proxy sends those connections through the currently selected proxy; Direct uses a direct route. “Global” describes the routing decision—it doesn’t mean every kind of system communication on the device necessarily follows the same path.

Routing modes and server protocols are separate concerns. Whether your existing server uses Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard doesn’t change what Config, Proxy, and Direct mean. Switching to Proxy won’t fix an incorrect server address, port, or authentication setting, and switching back to Config won’t create rules tailored to your needs.

3 modes

Modes compared: Config / Proxy / Direct

4 types

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

2 layers

Mode selector: Home → Global Routing

How to choose between Config, Proxy, and Direct

Config is the usual choice for everyday use when you have an active configuration whose rules you understand. Rule-based routing lets different destinations use different policies instead of forcing everything through one route. Rules can specify DIRECT, a proxy policy, or another action. Connections that don’t match earlier rules are handled by FINAL, so it’s not accurate to say they all go direct.

Config

Recommended

Routes traffic according to the rules and policies in the active configuration. Check rule order, policy targets, and FINAL. If a connection fails only in Config, the cause may be a rule or a setting associated with the configuration.

Best for: Everyday rule-based routing with a configuration you understand.

Proxy

Sends connections handled by Shadowrocket through the currently selected proxy, rather than choosing a route for each connection using ordinary routing rules. If the selected server or policy isn’t working, Proxy may fail too.

Best for: Temporarily testing a proxy route or checking whether Config’s rules are matching as expected.

Direct

Uses a direct route for connections handled by Shadowrocket. This changes the routing behavior; it doesn’t turn off the connection or remove the system VPN configuration, and it can’t bypass restrictions imposed by the current network.

Best for: Checking whether direct access works on your current network or temporarily testing a local destination.

Proxy isn’t automatically faster than Config, and Direct doesn’t guarantee lower latency. Speed also depends on your network, the destination, the selected route, DNS results, and connection reuse. Unless you’re troubleshooting a specific issue, there’s no need to switch modes just because one is called “Global.” Choose the mode that matches how you want traffic routed.

Switch modes in a consistent order

Before you start, note the current mode, selected server or policy, and active configuration in Config. You’ll need your own service and subscription. If Home doesn’t show an available server yet, import your existing details using the setup guide before comparing modes. Change only Global Routing during the test; don’t combine it with a subscription refresh, server change, or rule edit.

Note your current settings

On Home, note the current server or policy, then open Config and confirm which configuration is active. Record the current Global Routing mode so you can restore it when the test is done.
Open Global Routing

Go back to Home → Global Routing and select Config first. After connecting, open a fixed destination you’re authorized to access. Note whether it loads and how the connection appears in the connection log.
Compare with Proxy

Select Proxy under Home → Global Routing without changing your server or network. Connect to the same destination again. Check whether it uses the proxy route and whether the issue persists.
Compare with Direct

Select Direct under Home → Global Routing and test the same destination. Record the direct connection result on your current network; don’t assume one success or failure applies to every destination.
Restore your original settings

Go to Home → Global Routing and restore the original mode, usually Config. Start a new connection to confirm the change. If you found a configuration issue, address and test it separately rather than leaving a temporary troubleshooting mode enabled.

Why Config uses the wrong route: check rule order

Config works by matching rules. Rules are generally checked in the order listed in the configuration; when a rule matches, its specified policy is applied. Put specific exceptions before broader rules that could override them. The snippets below illustrate rule syntax only. They aren’t complete configurations or ready-made replacements for your current file.

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

DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains. In this example, PROXY must point to a working proxy policy in your active configuration.
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve shows an IP range rule. 192.0.2.0/24 is a documentation-only example range. no-resolve means this IP rule won’t actively trigger a domain lookup for matching; it doesn’t mean the entire connection requires no DNS.
GEOIP,CN,DIRECT matches based on an IP geolocation database. It doesn’t use the page language, domain suffix, or your location, and results can vary depending on the resolved IP address and database contents.
FINAL,PROXY handles connections that didn’t match any earlier rule. Changing it to FINAL,DIRECT changes the default route for unmatched connections. FINAL should be the last rule in the list.

If Proxy works but Config fails, first check which rule matched the new connection, then verify the policy it points to. A webpage may request resources from several domains. Routing the homepage through a proxy doesn’t mean its images, login endpoints, and other resources use the same route. Check the relevant domains in the connection log instead of adding just one page URL and assuming routing is complete.

Refreshing a subscription and updating a configuration aren’t the same thing. Refreshing an existing subscription mainly updates the server list and its parameters; it doesn’t necessarily change the rules in Config. Check that the intended configuration is active and that the policies referenced by its rules still have an available server. For more on rules, see Rules feature guide.

Use comparisons to narrow down the issue, not jump to conclusions

The patterns below explain how to interpret test results; they aren’t measurements from a specific network. Compare using the same destination, network, and selected proxy, and check a new connection. If you switch from Wi-Fi to cellular or change servers during the test, the results no longer isolate the routing mode.

Result	Check first	Next step
Proxy works; Config fails	Rule match, policy target, active configuration, and DNS settings associated with the configuration	Check how the failed connection was handled, correct the relevant configuration, and test again.
Direct works; Proxy fails	Proxy route connectivity, server details, authentication, and selected policy	Check your existing service details and test that server without changing networks.
Proxy works; Direct fails	Direct route to the destination on your current network and DNS results	Check whether the issue affects only certain destinations. Don’t assume the entire internet requires Proxy.
All three modes fail	Basic network connectivity, destination service status, DNS, connection permission, and test method	First check whether other destinations work, then troubleshoot one factor at a time instead of repeatedly switching modes.

A server latency test isn’t a substitute for a real request. A latency reading only shows that the test method received a response; it doesn’t confirm that DNS, authentication, data transfer, or every resource on a destination webpage is working. Likewise, one timed-out test doesn’t necessarily mean all app traffic will fail. Check the actual connection log too.

Check On Demand separately from the routing mode

Settings → On Demand controls when connections start based on configured conditions. Global Routing determines how connections are routed after they’re established. They aren’t interchangeable: enabling On Demand doesn’t send every destination through a proxy, and choosing Direct doesn’t disable On Demand. If you’re troubleshooting why the connection keeps turning on, check the trigger conditions instead of repeatedly changing the routing mode.

Separate connection triggers from route selection

Whether a connection starts

Go to Settings → On Demand.
Check which trigger conditions are enabled and whether the current network meets them.
Before manually comparing modes, note the original On Demand settings so automatic reconnections don’t affect the results.

Which route a connection uses

Go to Home → Global Routing.
Compare route behavior in Config, Proxy, and Direct.
In Config, also check rules and policies. If you use Scene, check its conditions separately.

First find out why the connection started, then check which route a new connection uses. Restore both the routing mode and On Demand settings when testing is complete.

To check network behavior without traffic going through Shadowrocket, disconnect and confirm the system connection status. If On Demand is enabled, also make sure it hasn’t started a new connection. This differs from testing Direct: the former checks the network while disconnected; the latter checks direct routing while Shadowrocket remains connected.

Everyday use and post-test checks

After troubleshooting, keep a configuration whose behavior you understand. For most everyday use cases that need rule-based routing, Config with maintained rules is easier to troubleshoot than leaving Proxy or Direct selected after a comparison test. If your needs call for routing everything through a proxy or directly, you can choose the corresponding mode; just make sure you understand how it changes the route.

Confirm Home → Global Routing is back in your intended mode, not left on a temporary test option.
In Config, confirm the intended configuration is active and that FINAL and policy references match your needs.
Check that the selected server or policy works. After refreshing an existing subscription, verify which server the policy selects.
Restore the original Settings → On Demand settings, then test your usual destinations again.
Keep notes on the test conditions and matched rules. Don’t include subscription URLs, authentication details, or other credentials.

Shadowrocket is a closed-source commercial app available on the App Store, primarily for iPhone and iPad. To verify the genuine app, check the developer, Shadow Launch Technology Limited, and app ID 932747118. The app is a one-time purchase, not a service plan; users must provide their own subscription or configuration for connections. Refer to the App Store listing for system requirements and general purchase availability.