Shadowrocket Global vs Rule Mode: A Beginner's Guide

Global and Rule mode determine how Shadowrocket routes eligible network traffic. In the app, the rule-based option is labeled Config under Global Routing; it follows the rules in the active configuration. Proxy and Direct take a different approach by sending eligible traffic through the selected proxy or directly, rather than choosing a route separately for each destination. This guide explains the difference, how to change the setting, and how to use a brief mode switch as a troubleshooting test.

What Global Routing controls

Global Routing is the routing choice shown on Shadowrocket’s Home screen. It determines how the app handles eligible traffic while its connection is active. It does not change the rules saved in a configuration file; instead, it changes which routing behavior is currently being used. That distinction matters: a configuration can contain detailed rules even when the current routing choice is Proxy or Direct.

In everyday conversation, people may call Config “Rule mode” because it uses the active configuration’s rules. In the app, look for the actual label Config. If you are following instructions that say “switch to Rule mode,” they usually mean selecting Config under Global Routing, not opening the Config tab to edit a file.

The routing selection is only one part of the connection. You also need an active connection and a usable selected server for traffic that is meant to go through a proxy. In Config, the active configuration must contain rules and policies that make sense for your intended traffic. A successful mode change cannot repair an unavailable server, an incomplete configuration, or a problem outside the app’s routing decision.

How Config works as Rule mode

With Config selected, Shadowrocket consults the rules in the active configuration to decide how a request should be handled. A rule may match a domain, an IP range, or another supported condition and direct matching traffic to a policy such as PROXY or DIRECT. The configuration may also use a policy group, so a rule’s destination does not necessarily name one individual server.

Rules are evaluated according to their order and matching conditions. A request that matches an earlier rule can be handled there rather than reaching a later rule. Many configurations include a final fallback such as FINAL; that fallback applies when no earlier rule matches. Its policy is important: if the fallback is DIRECT, unmatched traffic is not automatically sent through a proxy. If it is PROXY, unmatched traffic is not automatically sent direct.

• Destination-specific routing: A domain rule can send one destination through a proxy while another follows a direct policy.
• Policy selection: A rule can refer to a policy or group. Check the policy’s actual selection instead of assuming the rule directly identifies a particular server.
• Fallback behavior: Check the last applicable rule, often FINAL, to understand what happens when no earlier rule matches.
• Configuration state: Confirm that the file you inspected is the active configuration. Editing a different file does not change the behavior of the one currently in use.

This is why Config is usually the practical starting point for normal use: it allows a configuration to make different routing decisions for different destinations. But “rule-based” does not mean “automatically correct.” A missing rule, unexpected policy, stale configuration, or broad fallback can produce results that differ from what you intended. Check the active configuration before treating the mode name as proof that a particular destination should use a particular route.

What Proxy and Direct do

Proxy applies a broad proxy-routing choice to eligible traffic rather than relying on each destination’s normal rule match. The selected proxy or policy still matters. If the chosen server is unavailable, a broad proxy setting will not make it reachable. Use this mode briefly when you want to check whether a route through your selected proxy behaves differently from the rule-based result.

Direct sends eligible traffic directly instead of routing it through the selected proxy. It can help you compare behavior when you suspect that a proxy route or a rule is involved. Direct is not a universal connectivity fix: the destination still has to be reachable from the current network, and other causes such as DNS, a website problem, or a local network restriction can still prevent a page from loading.

The words “all traffic” are best understood as a broad routing choice for traffic Shadowrocket handles, not a guarantee that every connection from every app will behave identically. The destination, active connection, selected policy, configuration, and system conditions can all affect the result. For a reliable comparison, test the same app and destination on the same network, change only the routing mode, and note what happened.

Switch modes in Shadowrocket

Use the routing selector on Home. The labels below are the English interface terms; placement can vary slightly by app layout. Before changing anything, note the current choice so you can restore it. If you are troubleshooting, also record the selected server, the active configuration, the network in use, and the specific destination you are testing.

1. Open Home

   Launch Shadowrocket and open Home. Confirm that you are looking at the main connection screen, not the configuration editor.

2. Record the current choice

   Find Global Routing and note whether it shows Config, Proxy, or Direct. Also note the selected server and whether the connection is active.

3. Open Global Routing

   Tap the current Global Routing selection to display the available routing choices. Do not edit the rules just to switch the current mode.

4. Select a mode

   Tap Config for rule-based routing, or choose Proxy or Direct for a temporary comparison. Check that the new choice is displayed on Home.

5. Test one destination

   With the same network, connection state, and destination, try the page or app again. Record whether it loads, fails, or changes only partly; avoid changing DNS, server, and routing mode at the same time.

6. Restore your setting

   When the comparison is complete, return to Global Routing and reselect your usual choice, commonly Config for rule-based daily use. Verify the selection on Home.

If the available choices differ from what you expected, check the current app screen and active configuration rather than assuming that an instruction for a different layout applies exactly. The key is to confirm the selected label on Home after each change. A route test is only useful if you know which mode was active when you ran it.

Use a mode switch as a troubleshooting test

Suppose one website fails while other destinations work. Begin in Config and note the exact domain, the time, and whether the failure affects the whole page or only some resources. Then check the active configuration for a rule that could match that domain, the policy attached to the rule, and the final fallback. If the page works in Proxy but not in Config, the difference points toward the rule-based route or policy as an area to inspect; it does not prove which rule is responsible.

If the same destination fails in Config and Proxy, check whether the selected proxy is available and whether the connection is active. If it works in Direct but not through the proxy, that comparison suggests investigating the selected proxy route or its policy. If it fails in all three choices, the cause may be unrelated to the mode, so also consider the network, DNS resolution, the destination service, and the specific error shown by the app or browser.

• Change one variable: Keep the network, destination, selected server, and connection state consistent while comparing modes.
• Use a specific test: Record one failing hostname and one repeatable action, such as opening the same page or refreshing the same resource.
• Interpret partial results carefully: A page can load its main document while images, sign-in requests, or other domains fail under separate rules.
• Stop after a useful comparison: Restore the normal mode rather than leaving a broad test setting active without a reason.

Choose a practical everyday default

For everyday browsing, use Config when you have reviewed the active configuration and want rules to choose routes by destination. It is the mode that makes destination-specific routing useful: one request may follow a proxy policy, another may go direct, and unmatched requests follow the configuration’s fallback. If you do not know what the active rules do, inspect them before relying on that behavior.

Use Proxy or Direct as deliberate, temporary choices when you have a reason to compare routes. Before switching, record the current mode; after testing, restore it and verify the displayed selection. This simple habit prevents a troubleshooting setting from being mistaken for your normal setup later.

The main distinction is straightforward: Config lets the active rules decide, Proxy applies a broad proxy route, and Direct avoids that proxy route for eligible traffic. When a result surprises you, confirm the mode first, then inspect the rule, policy, selected server, and fallback that could explain it. Test one change at a time and treat each comparison as evidence—not as an automatic diagnosis.