Shadowrocket Rule Priority: Rule Order and FINAL Fallback

Check Global Routing first: prerequisites for rules to take effect

In Shadowrocket, Home is where you connect and choose a routing mode, Config manages rule configuration files, and Settings manages app behavior. Adding rules to a file does not mean that file is in use. Confirm both the active configuration and the setting under Home → Global Routing. This guide assumes you already have your own provider and subscription, with working connection settings. It does not cover how to obtain a connection.

Under Global Routing, Config routes traffic according to the active configuration; Proxy and Direct change how traffic is routed overall; Scene selects behavior based on configured conditions. The interface option Proxy is not the same as the rule policy keyword PROXY: the former is a routing mode, while the latter is the action taken when a rule matches.

Priority follows rule order, not rule names or domain length

Rules are checked from top to bottom. The first matching rule determines the action, and later rules are not checked for a “more specific” match. A broad DOMAIN-SUFFIX rule can therefore take precedence over a more specific domain rule below it. REJECT does not automatically get top priority just because it blocks traffic.

For example, both lines below can match ads.example.com. The first line matches first, so the result is DIRECT. The second line is more specific, but it never gets evaluated. This is a rule-order issue, not a REJECT failure.

DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT

After moving the specific exception to the top, ads.example.com and its subdomains match REJECT first. Other domains under example.com can then match DIRECT. DOMAIN-SUFFIX matches the target domain and its subdomains; it does not search for an arbitrary string within a name.

DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT

“Top to bottom” refers to the actual rule sequence in use. If the configuration also references remote rule sets, check where they appear in that sequence. Don’t review only the two new lines while overlooking an earlier matching rule.

What DOMAIN-SUFFIX, IP-CIDR, and GEOIP match

Different rule types use different information. Domain rules check the hostname; IP-CIDR checks whether the destination IP falls within a specified range; GEOIP classifies the IP using a geolocation database. A domain resolving successfully does not guarantee a domain rule will match. Likewise, an IP’s geographic classification does not establish where a website operator is based or which region its domain belongs to.

no-resolve means Shadowrocket will not perform an extra domain lookup just to match this IP rule. It does not “disable DNS” or replace normal domain resolution. If a request has only a hostname and no destination IP is available, this rule may not match, and evaluation continues down the list.

• When you need to control where a specific domain goes, use a rule for that domain rather than relying only on its current resolved IP.
• When a domain uses a CDN, its resolved IP may change. GEOIP matches can also change when the destination IP changes.
• 192.168.0.0/16 is not the full range of private addresses. Add rules for other network ranges as needed, based on your local network.
• DOMAIN-SUFFIX does not match URL paths. Enter the domain only—don’t include https://, a port, or /path.

Writing a FINAL fallback: exceptions first, broader rules next, fallback last

FINAL has no match conditions and catches connections that none of the earlier rules matched. Keep only one active FINAL rule and place it at the end of the list. Rules added after it won’t get a chance to match, even if their syntax is valid. In a complete configuration file, place rule entries in the [Rule] section—not in fields for server addresses, subscription URLs, or protocol parameters.

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

This example rejects specified domains first, allows explicit domains and a private network range, routes CN addresses according to GEOIP, and sends everything else through PROXY. example.com is a placeholder domain used to demonstrate syntax, not a server address or working route. Before using these rules, replace the examples with your own targets and make sure they won’t override traffic your services require.

1. When you visit ads.example.com, the first domain rule matches and applies REJECT. The request does not continue to the later DIRECT rule.
2. When you visit www.example.com, the first rule does not match. The second rule matches and applies DIRECT.
3. When you connect directly to 192.168.1.10, neither of the first two domain rules matches, so the private network rule can match and apply DIRECT.
4. If GEOIP identifies another destination as CN, DIRECT applies. If no rule matches, FINAL applies PROXY.

FINAL,DIRECT is also a valid fallback. It means “only explicitly matched proxy rules use the proxy; everything else connects directly.” Neither it nor FINAL,PROXY is universally better—the right choice depends on what you need. PROXY sends traffic through the proxy route; it does not create a server. The selected proxy must be available, and any policy referenced in the configuration must exist.

Don’t replace every rule in an existing configuration. Keep the original file and policy group definitions, then edit the rules in a copy. If existing rules use custom policy group names, preserve their meaning instead of replacing everything with PROXY.

Edit in Config and verify with a new connection

The steps below follow the Home, Config, and Settings interface. The location of editing controls may differ by platform, but the file to edit is always the configuration currently enabled in Config. Updating a server subscription and editing a rule file are separate tasks: refreshing the server list does not save or select a rule configuration.

1. Confirm the routing mode

   Go to Home → Global Routing → Config. Note the currently selected server or policy group, and don’t switch proxy routes during testing.

2. Keep a backup copy

   Open Config, find the active configuration, and save a copy or export a backup before opening it for editing. Make sure you aren’t editing a different, inactive file.

3. Organize the rules

   Review the rule list. If editing the text directly, locate [Rule]. Move specific exceptions above broader rules, add new rules before FINAL, and keep the definitions for any referenced policies.

4. Save and enable

   After saving, return to Config and confirm the edited configuration is selected. Go back to Home and reconnect. Check for configuration parsing errors; if any appear, restore the backup first.

5. Start a new request

   Close any existing connection to the target page, then open it again. Compare the destination, matched rule, and policy in the connection log. Don’t rely on refreshing a page that may reuse an existing connection.

For verification, choose targets that should match an exception, a broader rule, and FINAL. Check which rule actually matched before checking whether the connection succeeded. A failure after PROXY matched may be due to the proxy connection or remote service. A failure after DIRECT matched may be due to the local network, DNS, or the destination service. A page that won’t load does not by itself prove that rule priority is wrong.

• Connectivity Test: Checks connectivity for the selected server. It cannot, by itself, show which rule matched a particular website.
• Settings → DNS: If the destination IP in the log differs from what you expect, or the domain won’t resolve, check the resolution settings. Change only one option at a time.
• Settings → On Demand: Triggers connections based on conditions; it does not change rule order. If the connection restores itself during testing, also check whether this feature is enabled and review its conditions.

FAQ: Why isn’t traffic going where my rules say it should?