This guide is for users who have added a connection configuration to Shadowrocket but aren’t sure which Global Routing mode to choose. It explains rule-based routing with Config, routing all applicable traffic through a proxy with Proxy, and bypassing the proxy with Direct, then walks through a consistent way to check where new requests go. Config is usually the best starting point for everyday use. Proxy and Direct are useful for temporarily changing the route and narrowing down a problem, but they don’t replace checks of server settings or rules.
1. Understand the Connection Toggle, Global Routing, and Active Configuration
The connection toggle on Home controls whether Shadowrocket establishes a VPN connection. Global Routing determines how requests are routed after they’re handled by Shadowrocket, while the configuration selected in Config supplies rules and other settings. These are related, but none substitutes for the others. Changing Global Routing to Proxy does not turn the connection on, and seeing the system VPN indicator does not prove that every request is going through a proxy server.
Here, “route everything through a proxy” and “send everything direct” refer to traffic handled by Shadowrocket, not an absolute guarantee about all device communications. Routing exclusions, local network settings, DNS handling, and existing connections can affect what you observe. After switching modes, make a new request to check the route rather than relying on the status bar.
2. How Config, Proxy, and Direct Route Traffic
For everyday use that involves both direct and proxied traffic, start with Config—provided its rules match your needs. Config is not a fixed template that automatically sends some requests direct and others through a proxy. The rules and policies actually loaded determine how each domain is handled and what happens when no rule matches.
Config: Match Against the Active Configuration
RecommendedRequests are checked against rules in order. A matching rule selects DIRECT, PROXY, or another policy in the configuration. If no earlier rule matches, a fallback such as FINAL determines where the request goes. After choosing Config, make sure the expected file is active in Config.
Best for: Everyday use with established rules for consistently routing traffic by destination.
Proxy: Route All Applicable Traffic Through a Proxy
Ordinary requests handled by Shadowrocket use the proxy route instead of being individually assigned DIRECT or PROXY by the usual routing rules. A working proxy server is still required; changing modes won’t fix an incorrect address, port, or authentication details.
Best for: Briefly checking whether the proxy works or determining whether a problem is related to rule-based routing.
Direct: Route All Applicable Traffic Directly
Ordinary requests handled by Shadowrocket are sent without going through a proxy server. This changes the route used for requests; it does not disconnect Shadowrocket’s VPN connection or guarantee that DNS and other handling work exactly as they do when the connection is off.
Best for: Checking direct connectivity on the current network, testing local network resources, or temporarily ruling out the proxy route.
Proxy and Direct are most useful as comparison modes, not as rankings of speed or reliability. The proxy route depends on the server and network; direct access depends on connectivity from your current network to the destination. Different results for the same site in these modes are a troubleshooting clue, not a verdict on the entire configuration.
3. How Config Matches Rules: From Specific Rules to FINAL
In Config mode, regular rules are checked in order, and the first match determines the policy for that request. Put narrower exceptions before broader rules. The examples below demonstrate rule syntax and ordering only; they are not a complete connection configuration. Reserved addresses and example domains do not represent working services.
[Rule]
DOMAIN-SUFFIX,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY| Keyword | What it does in this example | What to check |
|---|---|---|
DOMAIN-SUFFIX | Matches the specified domain and its subdomains. | Put the exception for intranet.example.com before the broader example.com rule. |
IP-CIDR | Matches based on the network range containing the destination IP address. | no-resolve means this rule won’t trigger a DNS lookup just to make a match; an existing destination IP can still be matched. |
GEOIP | Matches using the geographic data associated with an IP address. | This depends on IP geolocation data; it does not identify a domain’s purpose or content. |
FINAL | Handles requests not matched by earlier rules. | The example uses PROXY, so unmatched traffic in Config should not be assumed to go direct. |
Domain rules need domain information to match. If only the destination IP is available, don’t expect every DOMAIN-SUFFIX rule to be evaluated successfully. When troubleshooting, check the destination, matched rule, and resulting policy in the connection record—not just whether a domain appears in the configuration file. If a rule refers to a policy group, also check which route that group currently selects.
4. How to Verify a Route After Switching Modes
Change only one variable at a time: keep the network, destination, and proxy server the same, then test Config, Proxy, and Direct in turn. An old browser tab may reuse an existing connection, and a page may load from cache. Refreshing once after a switch doesn’t prove that the route changed. End the old request, start a new one, and check the connection record for that request at the corresponding time.
- Note your starting point. On Home, check the selected server and connection status; in Config, check which file is active. Record a destination you’re authorized to access and the test time so results from different requests don’t get mixed up.
- Test Config first. Go to Home → Global Routing → Config and make a new request. In the connection record, check the destination, matched rule, and policy. If it shows DIRECT, first determine whether that matches the active rules instead of immediately switching servers.
- Then test Proxy. Go to Home → Global Routing → Proxy. Keep the server and destination unchanged, then make another request. If it succeeds now but failed in Config, focus on rule matching, policy group selection, and DNS differences.
- Test Direct last. Go to Home → Global Routing → Direct and request the same destination again. If Direct works but Proxy fails, check the proxy connection settings, server status, and name resolution along the proxy route.
- Restore your everyday settings. After comparing the results, switch back to Config and verify the rule outcome again. Record repeatable findings only; don’t draw a final conclusion from a single success or timeout.
Regular HTTPS web traffic commonly uses TCP port 443, while HTTP/3 may use UDP port 443. These are destination service ports—not a reason to change your proxy server port to 443. Browsers may fall back between transport methods, so a successful latency test doesn’t necessarily mean both routes work. Check the server port, protocol, and authentication fields against your existing configuration.
Two Comparisons: Check the Rules or the Proxy Route First?
Config fails, Proxy works
- Check whether the correct file is active in Config.
- Find the new connection record for the same destination and check the matched rule and resulting policy.
- Check whether a broader rule is matching first and whether FINAL is set as expected.
Proxy fails, Direct works
- Confirm that the server selected on Home is the same one used before the test.
- Check the address, port, authentication details, and protocol-specific fields.
- Retry on the same network and note the error type. Avoid changing DNS and rules at the same time.
These comparisons help narrow down the cause. If all three modes fail, continue by checking network connectivity, DNS, the destination service, and connection records.
5. What Global Routing Doesn’t Configure
Global Routing decides which route a request takes; it doesn’t generate connection settings or provide a connection service. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are protocol names, operating at a different layer from Config, Proxy, and Direct. Switching modes can’t fill in missing fields or fix an incorrect protocol configuration.
- Subscription import and updates: Get subscriptions from your service provider. An update retrieves connection details published by that provider; don’t assume it will also set your local routing rules or Global Routing mode to the values you want.
- On Demand: Check the automatic connection conditions under Settings → On Demand. These control when a connection starts; they don’t select Config or ensure that all requests use a proxy. When testing a manual disconnect, check whether an automatic connection condition starts it again.
- DNS: Domain name resolution is related to routing policy, but it’s a separate setting. If resolution still fails after changing modes, check DNS on its own instead of repeatedly switching Global Routing.
- App purchase: Buying the app is not the same as buying a network plan. Shadowrocket is a closed-source commercial app for Apple platforms, available exclusively on the App Store. Check the App Store listing for the current price, system requirements, and purchase eligibility.
The first time you connect, follow the system prompt to allow the VPN configuration to be added. This permission lets the system establish a connection; it doesn’t prove that the proxy is reachable or that the rules have been verified. Grant permission and confirm the connection first, then test each mode as described above to distinguish permission, configuration, and routing issues.
6. Four Common Questions About Switching Modes
Why does a site still connect directly in Config?
First, check which file is active in Config, then inspect the rule matched by a new request to that site. DOMAIN-SUFFIX, GEOIP, or FINAL may select DIRECT, or a policy group may choose a direct route. Seeing Config in Global Routing doesn’t by itself mean a site should use a proxy.
If a site opens in Proxy mode, does that prove the rules are wrong?
It shows that the route differs between the two modes, but it doesn’t prove that a particular rule has a syntax error. Keep the same server and network, then compare the rule matched in Config, the route selected by its policy group, and the DNS result. Identify the difference before changing a specific setting.
The VPN indicator is still there in Direct mode. Did the switch fail?
The VPN indicator means the system tunnel is still active; it doesn’t mean traffic is necessarily going through a proxy server. Direct is a routing mode. To disconnect, turn off the connection on Home. If it reconnects, check Settings → On Demand.
How can I check the route if an open webpage doesn’t change after switching?
Stop the old page’s requests, make a new request, and check the connection record at the same time. If needed, disconnect and reconnect to rule out a persistent connection. During the test, change only Global Routing; don’t also change the server, rules file, or DNS, so the results remain comparable.
For everyday use, follow this sequence: confirm the connection and configuration, then use Config. When something goes wrong, compare Proxy and Direct to narrow it down. Once you find the cause, return to Config and verify the specific rule with a new request. This keeps your routing setup intact and helps prevent a temporary troubleshooting mode from being left in place.