Shadowrocket rules do not automatically prioritize the most specific match. Rules are checked in order in the active configuration, and the first match determines the policy. For users who already have their own service provider and subscription and want to adjust routing, this guide covers Global Routing, rule order, the three policies, and FINAL, with configuration examples and steps to verify the results.
First, set Global Routing to Config
For custom rules to control routing, go to Home → Global Routing → Config and select configuration-based routing. Editing rules in Config while Global Routing is set to Proxy or Direct will not verify whether those rules match. Rules determine which route is used; your existing service details determine whether that route can connect. Check these separately.
Config
RecommendedThe active configuration's rules determine the policy. Whether traffic goes direct, through a proxy, or is rejected depends on the matching rule—not a fixed distinction by region.
Best for: everyday rule-based routing and testing custom rules.
Proxy
Routes connections handled by Shadowrocket through the currently selected proxy, without applying the policies in Config's routing rules.
Best for: temporarily checking whether the existing proxy route can reach a destination.
Direct
Sends connections handled by Shadowrocket directly to their destinations, bypassing the proxy routing decisions in the configuration.
Best for: comparing how a destination behaves over a direct connection on the current network.
Scene in Global Routing applies behavior based on a selected scenario; it is not interchangeable with Config. To reduce variables while troubleshooting, this guide uses Config throughout. Settings → On Demand controls when connections are triggered on demand, not which rule takes priority. When checking rule order, keep the connection state and current network unchanged.
Rules are checked from top to bottom: put specific exceptions before broad rules
In a standard rule list, each request is checked starting with the first rule. The policy for the first match applies, and later rules are not checked for a “more specific” match. So a precise DOMAIN rule placed after a DOMAIN-SUFFIX rule that already covers it may never take effect. Rules are evaluated by order, not by string length.
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYThis is a syntax example. example.com and its subdomains are used only to illustrate matching; they are not service endpoints or connectivity test addresses. The first rule applies only to metrics.example.com. The second sets a direct-connection exception for login.example.com. The third covers example.com itself and its subdomains. Requests not matched by the earlier rules are checked against GEOIP, then handled by FINAL.
| Request domain | First match | Policy |
|---|---|---|
metrics.example.com | Rule 1: DOMAIN | REJECT |
login.example.com | Rule 2: DOMAIN | DIRECT |
docs.example.com | Rule 3: DOMAIN-SUFFIX | PROXY |
If DOMAIN-SUFFIX,example.com,PROXY is moved to the top, all three domains in the table will match it first, overriding the reject and direct-connection exceptions below. Put specific destinations you need to block or allow near the top, broader suffix, address-range, and geographic rules below them, and the fallback last.
PROXY, DIRECT, REJECT, and rule keywords: what each one means
A rule typically contains both a match condition and a policy. For example, in DOMAIN-SUFFIX,example.com,PROXY, DOMAIN-SUFFIX is the rule type, example.com is the match value, and PROXY is the action taken on a match. Protocols and policies are different concepts: using Shadowsocks or VLESS for an existing connection does not change the order in which DOMAIN-SUFFIX rules are checked.
How to troubleshoot: check the match and the route separately
First confirm that the request matches the intended rule, then check whether the route selected by that policy is available. A successful proxy connection does not prove that the correct rule matched.
| Policy | What it does | What to check |
|---|---|---|
PROXY | Uses the proxy route. | Check the currently selected proxy; if you use a policy group, check its selected option as well. |
DIRECT | Connects directly to the destination. | Can the destination be reached directly over the current network? |
REJECT | Rejects matching connections. | Should this destination be blocked, and could the rule block a request you need? |
If your configuration defines custom-named policy groups, check the group names and selections against the actual configuration. Do not assume an unfamiliar name is a built-in policy. REJECT is not an automatic retry policy for failed connections: after a match, the request will not try a later PROXY rule just because the connection fails.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIP-CIDR matches the address range containing the destination IP; 192.0.2.0/24 is a documentation example range. no-resolve prevents an additional domain lookup solely for this IP rule; it does not disable all DNS. Existing destination IP information may still be used for matching. GEOIP,CN,DIRECT uses an IP geolocation database—not a site's domain suffix or operator location—so it cannot guarantee direct routing for every site you want to reach directly.
FINAL fallback: handles only requests not matched by earlier rules
FINAL does not take a domain or address parameter. Common forms are FINAL,PROXY and FINAL,DIRECT. Because it is an unconditional fallback, place it at the end of the standard rules. If placed earlier, it leaves no opportunity for later rules to handle the remaining requests. Adding two FINAL rules does not create a failover chain where the second is tried if the first fails.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY- Choose FINAL,PROXY: Requests not handled by an earlier rule use the proxy route. Make sure the existing proxy is available and that you want this traffic to use that route.
- Choose FINAL,DIRECT: Unmatched requests connect directly. This suits configurations where you have listed the destinations that need a proxy and want all other requests to connect directly.
- Include a policy: FINAL on its own is not a complete rule in the format used here. Check the commas and policy name before saving.
- Use English punctuation: Configuration examples use English commas. Do not paste explanatory text into the rule parameters.
FINAL handles requests that do not match any earlier rule; it does not handle connection failures after an earlier match. If a request matches a DIRECT rule, a timeout will not cause the final FINAL,PROXY rule to take over. Check whether the earlier match condition is too broad, then decide whether to change the rule order or the policy.
Edit and verify: change one rule at a time
Before you start, save a copy of the current configuration and note its name. Subscriptions in Home maintain your existing service details; rules in Config control routing. Refreshing Subscribe does not change the rules. Remote configuration updates may also replace your edits, so distinguish between updating an existing subscription and updating the rule configuration, then confirm which file is active afterward.
-
Confirm the routing mode
Go to Home → Global Routing → Config. Keep the existing connection available and note the selected proxy or policy group option. Avoid changing the route during testing.
-
Back up the current configuration
Open Config, confirm which configuration is active, save a copy, then open its editor. If editing as text, locate the [Rule] section.
-
Add a specific rule
Place the DOMAIN or DOMAIN-SUFFIX rule you want to test above any broader rule that would cover it. Keep one FINAL at the end, save, and confirm that the edited configuration is active.
-
Create a fresh test request
Stop existing requests from the target app, then start a new one. If needed, reconnect Shadowrocket after saving the configuration so an existing long-lived connection is not mistaken for a test of the new rules.
-
Check which rule matched
Use the request log's visible destination domain, destination IP, and policy information. Change one item at a time and record the results before and after. If the expected rule does not match, check the order first; do not switch protocols right away.
A webpage often requests multiple domains for the main page, login, images, and API calls. The main page matching PROXY does not mean every resource matches the same rule. If the homepage loads but login fails, check the actual domain of the failed request instead of adding an exception only for the domain in the browser's address bar.
To confirm that a rule is working, check the match and policy for a new request. A latency test only reports the response on a particular test route; it does not prove that a webpage request matched a specific rule.
Common issues: troubleshoot by symptom when rules do not work
Why is traffic still using the proxy when I specified DIRECT?
First, go to Home → Global Routing and confirm that Config is selected. Then check whether a DOMAIN-SUFFIX rule or another broad rule above DIRECT covers the same domain. Move the specific exception above the covering rule, save, and make a new request.
Why is the destination still unreachable after changing FINAL?
First check whether the request actually reaches FINAL. If it matched an earlier REJECT or DIRECT rule, changing FINAL will have no effect. If it does match FINAL,PROXY, check the proxy route in use, the destination service, and the DNS resolution results.
Why doesn't a domain rule match when I connect by IP address?
DOMAIN and DOMAIN-SUFFIX depend on domain information being available. Connecting directly by IP is not the same as connecting to the corresponding domain. To match by address, add an appropriately sized IP-CIDR rule. Do not add an overly broad address range just to cover a single destination.
Why did my new rule disappear after an update?
In Config, check the active file and its contents, and confirm whether the configuration was switched or a remote configuration was updated. Compare the [Rule] section with your backup, restore any necessary exceptions, and check the position of FINAL. Do not treat a refresh of an existing subscription in Home as proof that your rules were saved.
Keep a minimal rule list that is easy to understand: specific exceptions first, broader ranges in the middle, and FINAL at the end. If something goes wrong, first confirm Global Routing and the active configuration, then trace the specific request. This separates rule-order problems from unreachable routes and DNS issues, instead of making troubleshooting harder by repeatedly adding duplicate rules.