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

At a glance

If you already have a service provider and subscription and are choosing a routing mode in Shadowrocket, first confirm that your server is working, then select Global Routing. For everyday use, start with a verified Config. Use Proxy for temporary system-wide proxying or comparison tests, and Direct to check direct connectivity. This guide covers how the modes differ, how to switch between them, and how to check rules. It also distinguishes Scene and On Demand so you don’t confuse the connection toggle, routing mode, and automatic connection behavior.

The short answer: use Config as your everyday starting point

Global Routing determines how traffic handled by Shadowrocket is routed. It does not create a service or fix invalid server settings. If you need some connections to go direct and others through a proxy, choose Config for everyday use—provided the active configuration’s rules and final matching rule meet your needs. Config does not automatically select the fastest route, nor does it guarantee that every destination will be routed as expected.

Config

Recommended

Routes connections according to the active configuration’s rules and policies. A match can result in DIRECT, a proxy policy, or another defined action. If no earlier rule matches, the final rule determines where the request goes.

Best for: everyday rule-based routing when you need both direct and proxied connections.

Proxy

Routes traffic within Shadowrocket’s handling scope through the proxy, rather than selecting DIRECT or a proxy separately according to Config’s usual rules. DNS and system-level behavior still need to be checked separately.

Best for: temporarily routing everything through the proxy, or comparing with Config to narrow down a rule issue.

Direct

Routes traffic within Shadowrocket’s handling scope directly, without forwarding it through the selected proxy server. This is a routing mode; it does not turn off Shadowrocket’s connection toggle.

Best for: checking direct access over your current Wi-Fi or cellular network.

This comparison covers three basic modes, not every Global Routing option. If the interface also shows Scene, it lets you choose how traffic is handled based on scene conditions. When troubleshooting, check the active scene and its settings rather than treating Scene as another name for Config.

Switch modes from Home while keeping other variables constant

Home shows the current server and connection status; Config manages configuration files; Settings is where you adjust app settings. Selecting Config under Global Routing in Home is a different action from opening Config and selecting a file. Check both the routing mode and the active file to know which rules will handle a request.

Check the server

Open Home and confirm that the selected server is the one you intend to test from your existing service. Verify the address, port, authentication details, and protocol settings. Don’t change servers while switching modes.
Check the configuration

Open Config and confirm which configuration file is active. Preserve the existing contents before making changes. Importing or updating a server subscription does not mean a new routing configuration has been selected.
Choose a mode

Go back to Home → Global Routing, select Config, Proxy, or Direct, then return to Home and verify the displayed selection. Don’t rely on memory of what you used last time.
Send a new request

Check the connection toggle, then reopen the target page in your test app. If needed, close the existing connection or reconnect Shadowrocket to avoid mistaking an old session for the result of the mode change.
Record the results and restore your settings

Note the network type, mode, server, and page result. After comparing modes, return to Home → Global Routing → Config and confirm that your everyday configuration file is still active.

What matters in Config: rule order and FINAL

Config processes requests using the rules in the configuration file, typically checking them from top to bottom. A destination can match both domain and address conditions, so put specific rules before broader ones to prevent an early broad match from taking over. FINAL is the fallback rule; it does not recheck the results of earlier rules.

DOMAIN-SUFFIX

Match by domain suffix

IP-CIDR

Match by IPv4 address range

GEOIP

Match using an IP geolocation database

FINAL

Handle requests that didn’t match earlier rules

The snippets below illustrate rule order; they are not a complete configuration file. The example domain example.com is for syntax illustration. In an actual configuration, PROXY must refer to a policy that can be resolved. If you use a different policy name, replace it with one already defined in your configuration. Don’t assume a snippet will work if pasted as-is.

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

DOMAIN-SUFFIX,example.com,PROXY: Routes the domain and its subdomains to the PROXY policy. It does not automatically include other domains with similar names.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: Connects directly to the specified address range. no-resolve means this address rule won’t trigger an additional domain lookup.
GEOIP,CN,DIRECT: Uses an available IP geolocation database to identify the destination IP’s region, rather than matching by brand or domain suffix.
FINAL,PROXY: Routes requests that didn’t match earlier rules to PROXY. Changing it to FINAL,DIRECT changes the fallback behavior.

So the claim that “Config sends all remaining traffic direct” is not necessarily true. Check FINAL to see how unmatched traffic is handled. When troubleshooting a site, remember that a page may load resources from multiple domains: a rule matching the main page doesn’t mean the images, login endpoints, and other resources match the same rule.

Proxy vs. Direct: run a controlled comparison

Switching modes helps narrow down an issue; one successful test doesn’t prove the entire configuration is correct. Use the same device, network, server, and destination, changing only one setting per test. Don’t update a subscription, change DNS, and edit rules at the same time, or you won’t know which change affected the result.

Comparison method: keep the destination fixed and change only Global Routing

Test with Proxy

Keep the same server and switch to Home → Global Routing → Proxy.
Retry the page that failed and note whether it loads and what error appears.
If Proxy works but Config doesn’t, first check the matched rule, selected policy, and DNS differences.

Test with Direct

On the same network, switch to Home → Global Routing → Direct.
Choose a destination that should be directly accessible on your current network, then retry the request.
If Direct works but Proxy doesn’t, first check the server connection and whether the destination is accessible through the proxy.

Comparison results point to possible causes; they don’t prove one. When you’re done, restore Config and verify everyday routing with a new request.

Observed result	What to check next
Proxy works; Config doesn’t	Check the rule matching the destination, the policy referenced by that rule, and FINAL. Don’t assume the server is at fault.
Direct works; Proxy doesn’t	Check the server address, port, authentication, and required transport settings. Then check whether the destination blocks access from that proxy’s exit address.
None of the three modes works	First check the underlying network and destination status, then check DNS resolution. If needed, turn off the connection toggle for an additional comparison.
The page looks unchanged after switching modes	Send a new request to rule out caching and an old session. Don’t switch modes rapidly and judge the result by content left on the page.

The table describes troubleshooting logic, not test data collected by this site. Direct can still be affected by in-app DNS settings, so a failed Direct test alone doesn’t prove that Wi-Fi or cellular service is disconnected. A test with the connection toggle off uses different conditions and should be recorded separately.

Understand DNS, Scene, and On Demand

Global Routing determines how a request is routed; DNS determines how a domain name is resolved; On Demand determines when a connection is triggered based on conditions. They’re related, but they aren’t interchangeable. For example, switching to Proxy won’t fix incorrect DNS settings, and leaving Config selected doesn’t mean the system will automatically establish a connection.

DNS: First check whether the domain resolves, then investigate the route taken by the connection. Whether an address-based rule matches can depend on the address used by the request and on how resolution is handled; the rule text alone isn’t enough.
Scene: If you use Home → Global Routing → Scene, check the selected scene and its conditions. For a clear comparison, temporarily select Config, Proxy, or Direct explicitly, then restore the original scene settings when you’re done.
On Demand: Check the saved conditions under Settings → On Demand. On Demand affects when a connection is triggered; it does not replace DOMAIN-SUFFIX, IP-CIDR, or FINAL rules in the Config file.

Recheck routing after updating a subscription

This guide assumes you already have a service provider and subscription. Updating a server subscription mainly affects server entries; it shouldn’t be treated as a fix for rules, policy references, or FINAL in Config. If an update changes server names or which servers are available, check whether your existing policy selections still apply.

Protocols are not substitutes for Global Routing modes. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe connection protocols or tunneling methods. Choosing a protocol does not select Proxy or Config. Use the details provided by your existing service for protocol settings; don’t guess the port or authentication method from the protocol name.

In Home, confirm that the updated server entry still works and that the selected server matches the conditions for your test.
In Config, confirm which file is active. Check that the policy names referenced by rules exist and that the selected policies are what you expect.
In Home → Global Routing, confirm the selected mode so you don’t leave troubleshooting set to Proxy or Direct.
Test one destination that should connect directly and another that should use a proxy. If the results differ from expectations, check the rules one by one instead of repeatedly updating the subscription.

Everyday settings and a final check

Config is the recommended everyday setting only if the configuration file has been checked and meets your needs; this is not a guarantee for any imported file. If you have only server entries and haven’t reviewed the rules, check the configuration and its fallback behavior before relying on Config long term. Proxy and Direct have specific uses, but don’t leave a temporary test mode enabled without realizing it.

Does Proxy mean every connection on the device goes through a proxy?

Not necessarily. Proxy describes how Shadowrocket handles traffic within its scope. System routing boundaries, DNS settings, and connection types can still affect the actual route. To check a specific request, review its diagnostic information rather than relying on the mode name alone.

If Config is slower than Proxy, should I always use Proxy?

First check whether both modes use the same policy and server for the same destination. If Config selects a different exit or DIRECT, you’re not comparing the same route. Check the rules, DNS resolution, and connection reuse before deciding whether to change the configuration.

What should I restore after troubleshooting?

Restore Home → Global Routing → Config and confirm which file is active in Config. Restore the DNS and Settings → On Demand settings you noted before testing, then send a new request. If you normally use Scene, restore the original Scene and check its conditions rather than switching to Config by default.

This is the official Shadowrocket website and this article is part of the official manual. Shadowrocket is a closed-source commercial app available exclusively on the App Store. Compatibility, system requirements, and purchase availability for iPhone, iPad, and other Apple devices are subject to the App Store listing.