Shadowrocket Rule-Based Routing Setup: Configure Direct and Proxy Rules

1. Choose Config in Global Routing

Rules only determine a connection’s route when Shadowrocket is using the configuration that contains those rules. On Home, open Global Routing and select Config. If Proxy is selected, traffic is sent through the proxy without using the rule-by-rule result you are trying to check. If Direct is selected, traffic is sent directly, so a rule that should use a proxy cannot be verified in that mode.

After choosing Config, open Config and identify the configuration you intend to use. A device can contain more than one configuration, and editing an inactive file won’t change the route used by current connections. Check the active selection before changing anything. If your configuration is obtained from your own service provider, review how it is maintained: a later refresh may replace local changes, depending on how the configuration is managed.

Keep the server selection and routing mode distinct in your diagnosis. A valid server selection is needed for a rule that uses a proxy, but selecting a server does not activate rule-based routing by itself. Conversely, selecting Config does not prove that the active configuration contains the intended rule. Confirm both the routing mode and the configuration before drawing conclusions from a browser test.

2. Understand the match, value, and policy

A common domain rule has three comma-separated fields: the rule keyword, the value to match, and the policy to apply. Use ordinary English commas, with no extra comma at the end. For example, DOMAIN-SUFFIX,example.com,DIRECT matches the example.com domain and its subdomains, then routes matching traffic directly. The reserved example.com name is illustrative only; replace it with a domain you intend to route.

DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

In this example, the exact API domain is sent through PROXY. Other matching example.com domains use DIRECT. Traffic that matches neither domain rule reaches FINAL and uses the proxy policy. FINAL is a catch-all rule: it has no separate match value, so its format is FINAL,policy. A policy must be recognized by the active configuration. If it refers to a proxy group, that group must exist there; a policy label that is absent or misspelled cannot select the intended route.

Choose the rule type according to the traffic you want to match. DOMAIN is suitable for a single hostname; DOMAIN-SUFFIX covers that domain and its subdomains. A rule for example.com should not be assumed to cover an unrelated domain that merely contains the same characters. If a site uses several hostnames for its main page, API, images, or sign-in flow, routing only one hostname may produce a partial result. Add only the matches you need, and keep a note of each change so you can reverse it.

3. Add a direct or proxy domain rule

Make one change at a time and keep an untouched copy of the original configuration or its contents. In Config, select the file you have confirmed is active, then use the editing controls available for that configuration. The exact controls can vary with the file type and app interface. If the configuration is managed remotely or does not allow local editing, follow the configuration owner’s instructions rather than assuming a local change will persist after an update.

1. Confirm the target

   Write down the hostname you actually need to route, such as api.example.com. Decide whether you mean one hostname or an entire domain and its subdomains. Avoid adding a broad suffix rule when a single-domain match is enough.

2. Open the active file

   Go to Config and check the selected configuration name. Use its available edit option to review the rules. If you can’t determine whether this is the active file, stop and verify the selection before editing another configuration.

3. Add the rule

   For a single hostname routed through a proxy, add DOMAIN,api.example.com,PROXY. For an entire example.com domain routed directly, use DOMAIN-SUFFIX,example.com,DIRECT. Replace the illustrative hostname with your intended domain and use a policy that exists in the active configuration.

4. Set its position

   Place the more specific rule above any broader rule that could also match it. Keep the configuration’s fallback rule, commonly FINAL, after the rules that should take precedence. Don’t create a second catch-all rule without understanding how it affects the existing list.

5. Save and verify

   Save through the available editing control, return to the configuration view, and confirm that the line remains present with the intended commas and policy. Return to Home and check that Global Routing still shows Config before testing.

For example, if an exception must send api.example.com through a proxy while the rest of example.com should be direct, put the exact DOMAIN line above the broader DOMAIN-SUFFIX line. Reversing them makes the suffix rule match first, so the specific proxy exception does not get a chance to apply. A syntactically valid configuration can still produce an unwanted route when its order is wrong.

Do not treat a subscription entry on Home as a rule configuration. Home is where you select a server and manage the connection; Config is where routing configurations are selected and reviewed. A server list can be available while the desired domain rules are absent, and a configuration can contain rules while the server needed by a proxy policy is unavailable. Check those pieces separately.

4. Check priority and what a rule actually matches

Rule order is a practical part of the configuration, not just a formatting preference. The first matching rule wins, so specific exceptions generally belong above broader rules, with a catch-all at the end. Consider this order:

DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

A request for api.example.com matches the first line and uses PROXY. A request for another hostname such as www.example.com does not match that exact-domain line, but it does match the suffix rule and uses DIRECT. A destination that matches neither domain rule uses the policy on FINAL. If the suffix rule is moved above the exact-domain rule, the API exception is shadowed by the broader match.

Check punctuation as well as placement. Each line should use the expected keyword, match value, and policy in the correct order. A missing comma can make a line invalid or change how it is interpreted. A typo in a hostname can prevent a match, while a typo in a policy can leave the route unavailable. Keep the spelling and capitalization of rule keywords and policy names consistent with the active configuration.

• Hostname versus IP address: A domain rule matches a hostname, not necessarily a connection made directly to an IP address. If an app connects by IP, a domain-only rule may not describe that traffic.
• Related hostnames: A web service may use separate hostnames for its page, API, authentication, and static files. A rule for one host does not automatically prove that every related request follows the same route.
• Policy availability: DIRECT is a direct route. A proxy policy requires a valid proxy target or group in the active configuration and, where applicable, an available server selected on Home.
• Configuration updates: If a rule disappears after refreshing or replacing a configuration, check how that file is maintained before adding it again. Repeatedly editing a file that is regenerated may not preserve the change.

Use a small set of clear rules while validating. Adding several overlapping suffixes, IP ranges, and fallback policies at once makes it difficult to tell which line determined the result. Start with one target, test it, and only then add the next required exception. Keep a short record of the original line, the change, and the intended result; this makes rollback straightforward if the test has an unexpected outcome.

5. Test the route and troubleshoot mismatches

Test with a destination that actually uses the hostname in your rule. A successful page load alone does not prove whether the request went direct or through a proxy: both routes may reach the same page. Where available in the app interface, review the connection or request details for the destination and the policy selected. Compare the observed policy with the first matching rule in the active file. If connection details aren’t available for the request, use a controlled test and change only one routing condition at a time.

First verify the basics: the connection is active, the intended server is selected if the policy needs one, Global Routing is set to Config, and the correct configuration is active. Then check the hostname, rule position, and policy spelling. If a proxy rule is being tested, compare against a known working destination using the same selected server. If a direct rule is being tested, verify that the specific destination is matching the intended rule rather than a higher rule or the FINAL fallback.

If the route still differs from your expectation, temporarily simplify the test: use one known hostname, one matching rule, and a clear fallback. Confirm the active configuration and inspect the resulting policy before restoring other rules. Avoid changing the server parameters, routing mode, and rule list together, because that makes it harder to identify the cause. When sharing diagnostics with your service provider, remove subscription URLs, tokens, passwords, and account details.

Rule-based routing is working as intended only when the active configuration, matching rule, rule order, and policy all agree. Keep Config selected for normal rule-based use, place exceptions before broad matches, and test each meaningful change against its intended hostname. If you need more help with the app’s general setup, see the Shadowrocket usage tutorial.