Shadowrocket Rule Priority: How Rule Order Works and Where to Place FINAL

Start with Config: the prerequisite for rule order

Before editing rules, check the current mode under Home → Global Routing. This guide covers how rules in the current configuration’s [Rule] list are evaluated when Config is selected. Editing the file while Global Routing is set to Proxy or Direct won’t verify whether these rules work as intended.

The Global Routing mode and the policy names in rule lines are separate settings. For example, Proxy is a routing mode, while PROXY is a rule’s target policy. The names look similar, but selecting Proxy does not mean that only PROXY rules take effect.

Rules are checked top to bottom: specificity doesn’t set priority

In a standard rule list, Shadowrocket checks rules from top to bottom. Once a rule matches and determines how to handle the request, Shadowrocket stops; it won’t look for a “more specific” match below. Priority comes mainly from a rule’s position—not the length of its domain, or whether its policy is DIRECT, PROXY, or REJECT.

The reserved example domains below illustrate rule conflicts; they are not live test services. Suppose all of example.com should use PROXY, except api.example.com, which should use DIRECT. Put the exception before the broader rule.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

• api.example.com: The first line matches, so the request uses DIRECT. Shadowrocket doesn’t check the next DOMAIN-SUFFIX rule.
• www.example.com: The first line doesn’t match; the second does, so the request uses PROXY.
• Other requests not covered by the first two lines continue to FINAL and use DIRECT.

If you move the second line above the first, api.example.com will match DOMAIN-SUFFIX first, and the DIRECT exception will never run. The same applies to a REJECT rule placed below a broader rule: it won’t automatically get higher priority.

DOMAIN-SUFFIX,example.com,PROXY doesn’t search arbitrary text in a URL. It won’t match just because example.com appears in the URL path. Enter a domain as the rule parameter—not https://, a page path, or query parameters. To target a single hostname, use DOMAIN for the exception.

How to use FINAL: set a route for unmatched requests

FINAL is a catch-all rule without a domain or IP condition. Common forms include FINAL,DIRECT and FINAL,PROXY. It doesn’t match only “unrecognized websites”; it handles every request that reaches this line without matching an earlier rule.

So place FINAL at the end of the [Rule] list, not at the end of the entire configuration file. The file may contain other sections; don’t move FINAL into another section. If FINAL appears earlier, ordinary rules below it won’t get a chance to match.

This minimal, standalone example shows where domain rules, IP rules, and the fallback go. It is not a complete everyday configuration: it lists only one private address range and doesn’t cover every local network scenario. Add the lines you need to a copy of your existing configuration. Don’t add a second [Rule] section.

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

IP-CIDR checks an address range; GEOIP classifies an IP using a geolocation database—it doesn’t identify a website’s language or operator. In this example, no-resolve means not to actively resolve a domain just for this IP rule. It doesn’t disable DNS queries across the entire configuration. Whether an IP rule matches also depends on the destination address information available for that request.

PROXY, DIRECT, and REJECT: separate match conditions from actions

The first part of a rule says what to match; the policy at the end says what to do when it matches. The same DOMAIN-SUFFIX rule can use different policies. A policy doesn’t change the match scope or increase the rule’s priority.

PROXY

Send the request through the proxy route. The connection used depends on the current selection and the policies in your configuration. A PROXY match doesn’t guarantee that the server connection, authentication, or access to the destination will succeed.

DIRECT

Connect directly to the destination over your local network. Use this for domains or address ranges confirmed to require direct access. DIRECT won’t fix DNS errors, local network blocks, or destination service outages.

REJECT

Reject matching requests. Use this for a specific domain or address that should be blocked. Check the match scope first to avoid also blocking sign-ins, verification, or page resources.

For example, DOMAIN,metrics.example.com,REJECT applies only to this example hostname. If regular content and requests you want to block share a domain, DOMAIN and DOMAIN-SUFFIX can’t separate them by page path. Setting REJECT for the whole domain may also break images, buttons, or page loading.

• For a direct-access exception: place a specific DOMAIN rule with DIRECT before the broader PROXY rule.
• To block a specific domain: confirm its hostname in the request log, then add REJECT. Don’t guess the domain from text on the page.
• For IP-based classification: confirm the destination address, mask, and database classification. GEOIP does not guarantee a domain’s geographic region.

Rules determine the route; protocols determine how the proxy connection is established. Changing the protocol used by a PROXY connection won’t change the match scope of DOMAIN-SUFFIX. Troubleshoot in this order: first confirm that the request takes the correct route, then check whether the connection on that route succeeds.

Edit and verify: save a copy and check each match

These steps assume you already have a working connection and an existing configuration. A subscription and a configuration file are separate things: updating a subscription in Home does not automatically reorder the rules in your current Config. Before editing, confirm that you’re working on the file currently in use and keep a recoverable copy.

1. Save a copy

   In Config, confirm which file is currently selected, then keep a copy of the original or export a backup. If the file is updated remotely, make changes in a separate local copy to prevent a later update from overwriting them.

2. Keep the mode fixed

   Go to Home → Global Routing → Config and leave the selected connection unchanged. Don’t change the routing mode, connection, and rule file all in the same test.

3. Edit the rules

   Go to Config → ⓘ next to the current file → Edit Plain Text and find the [Rule] section. Put specific exceptions before broader rules. Make sure FINAL appears just once, at the end of the list, then save.

4. Create a new request

   Confirm that the edited configuration is selected, reconnect, and reopen the page you want to test. Long-lived connections may continue using an existing session, so don’t draw conclusions from refreshing a page that still reuses an old connection.

5. Check the log

   Review the connection log for this request. Check the destination domain or IP, the matched rule, and the policy applied. If the route is wrong, adjust the order. If the route is correct but access fails, check the connection and destination service.

Test at least three cases: a domain that should match a specific exception, one that should match a broader rule, and a destination that should reach FINAL. Use targets you’re authorized to access and know the expected route for. The example.com names in this guide illustrate syntax only; they aren’t connectivity test results.

Common questions: where to look when rules don’t work

If the destination in the log doesn’t match the expected domain, check page redirects, resource domains, and the address used by the actual connection. A page usually makes multiple requests. Adding DIRECT for the entry domain doesn’t mean every resource referenced by the page will match the same rule. Checking requests individually in the log is easier to control than repeatedly broadening a DOMAIN-SUFFIX rule.

• Before saving: check rule syntax, section placement, exception order, and that FINAL appears only once.
• Before testing: confirm the selected file, Config mode, and selected connection. Avoid changing multiple conditions at once.
• After verification: keep a working copy before adding more rules. If something goes wrong, restore the last verified configuration.