Shadowrocket Rule Order: How to Use FINAL, PROXY/DIRECT/REJECT

1. Set Global Routing to Config before checking rules

Adding rules to a file does not guarantee that current requests use that file. Home manages connections and service entries, Config manages configuration files, and Settings contains app preferences. When troubleshooting, first confirm which configuration the connection uses, then check Home → Global Routing. The rule explanations here assume Config is selected; they do not apply when Proxy or Direct is temporarily overriding rule-based routing.

Scene in Global Routing involves selecting a scene, so check which settings the current scene uses. It is not a rule keyword to add inside [Rule]. For an initial rule test, switch explicitly to Config to reduce variables. Settings → On Demand controls when connections are triggered; it does not change rule order.

2. Rule syntax: condition first, action last

Rules go in the [Rule] section of a configuration file. Most common rules follow the format “type,match value,policy,” with fields separated by ASCII commas. The three lines below show an exact domain, a domain suffix, and a final policy. The example domains illustrate syntax and should not be copied as a real-world service list.

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

PROXY is neither a server address nor a protocol name. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are connection protocols. Rules determine which policy a request uses; service entries provide the actual connection parameters. Do not put a protocol name, subscription URL, or server port in a rule’s policy field. If you use a custom policy group, its name must exactly match the one defined in the configuration.

3. Rule order: once a rule matches, later rules are skipped

Rules are checked from top to bottom, and the policy for the first match is applied. Rules do not automatically prioritize more specific matches, and matching results are not combined. In the example above, api.example.com matches DOMAIN first and uses PROXY. img.example.com does not match the first line, so it matches DOMAIN-SUFFIX next and uses DIRECT.

1. Put specific exceptions first. Place exact-domain rules before broader suffix rules. For example, put DOMAIN,api.example.com,PROXY before DOMAIN-SUFFIX,example.com,DIRECT.
2. Then add broader rules. DOMAIN-SUFFIX matches both the specified domain and its subdomains. example.com matches example.com and a.example.com, but not any domain that merely contains that text.
3. Place reject rules carefully. If you put DOMAIN-SUFFIX,example.com,REJECT first, a later rule allowing api.example.com will never run.
4. Put FINAL last. The final policy applies only if none of the preceding conditions match. Rules after FINAL cannot serve as normal follow-up matches.

Swapping the first two lines changes the outcome. In the example below, api.example.com matches the first line and connects directly. The second line is more specific, but it cannot override a result that has already been determined.

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

4. How FINAL works with IP rules

FINAL takes no domain or network argument. Its correct format is FINAL,policy, for example FINAL,PROXY or FINAL,DIRECT. It is not a retry mechanism: if a PROXY rule matches but the connection fails, processing does not continue to FINAL and switch to DIRECT. FINAL applies when no matching condition is found, not when a connection fails.

no-resolve prevents an additional DNS lookup from being triggered just to match this IP rule. It does not disable DNS for the entire app or turn a domain into an IP address. If the request already includes a usable destination IP, the rule can still check that IP. If the request has only a domain and no usable IP yet, do not assume this rule will match.

GEOIP results depend on the destination IP and the local database. Different DNS results for the same domain can lead to different geographic matches. For a small number of domains that must use a fixed policy, add explicit DOMAIN or DOMAIN-SUFFIX exceptions before broader conditions such as GEOIP. Do not treat successful DNS resolution, a rule match, and a successful connection as the same thing.

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

The example shows one possible rule order, not a complete configuration or a list recommended for every network. Before using it, make sure the local network range, destination domains, and final policy suit your needs. If the destination uses IPv6, an IPv4 IP-CIDR rule alone will not cover its IPv6 address; check the relevant rules and network conditions separately.

5. How to verify rule matches after saving

Test a new connection, not a page that is already open. A browser may reuse an existing connection, and a page may show cached content. Whether the page still loads does not tell you whether the rule you just changed took effect. Save a copy of the original configuration first, and change only one condition or policy at a time during testing.

1. Confirm the configuration

   Open Config and confirm which file is selected. Edit and save the file’s [Rule] section; do not change only a different, inactive copy.

2. Fix the routing mode

   Go to Home → Global Routing → Config and confirm that Config is selected, not Proxy, Direct, or a Scene you have not checked.

3. Reconnect

   Apply the updated configuration and make the request again, disconnecting and reconnecting if needed. Close the test page’s existing connection to avoid mistaking connection reuse for a rule that failed to take effect.

4. Check the logs

   Check the request log for the actual destination domain or IP, the matched rule, and the policy used. If a page involves multiple domains, distinguish the main document, sign-in endpoints, and resource requests.

5. Revert test changes

   Record the original rule, your changes, and the results, then remove any temporary reject or exception rules. Do not leave a test REJECT rule on a domain that needs to remain accessible.

For example, after setting an authorized test domain to REJECT, a new request to that destination should be rejected. However, old text may still appear from cache, and images loaded from other domains may remain visible. This illustrates a test method; it is not a report of results measured by this site. Check the corresponding request log rather than expecting the entire page to go blank immediately.

6. Shadowrocket rule-routing FAQs

When organizing a configuration, start with a small set of rules that explains each test result, then expand their scope gradually. For every new rule, you should be able to answer three questions: What does it match? Is there an earlier rule that could match first? Which policy applies if it matches? Once those points are clear, FINAL is simply an explicit choice at the end—not a patch for mistakes in earlier rules.