Shadowrocket Custom Rule Priority: Rule Order and FINAL Fallback

1. Rule priority: first match wins—not the most specific rule

With rule-based routing, Shadowrocket checks the [Rule] section from top to bottom. Once a rule matches, its policy applies and later rules are not checked—even if one of them is more specific. Rule types therefore have no universal priority that overrides their order in the list. Placing DOMAIN below DOMAIN-SUFFIX does not give it higher priority.

For example, to connect directly to api.example.com while proxying other subdomains of example.com, put the exception for the specific hostname first. These domains illustrate the syntax only; they are not service addresses or a promise of availability.

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

• Request to api.example.com: the first rule matches, so DIRECT applies.
• Request to www.example.com: the first rule does not match, so the second rule applies PROXY.
• Requests not covered by earlier rules are handled by FINAL,DIRECT.

If you swap the first two rules, api.example.com also matches the broader domain suffix rule and is caught by PROXY first. If traffic goes through a proxy despite a DIRECT rule, first check whether an earlier rule already covers the destination instead of appending duplicate entries at the end.

2. Check Global Routing before editing Config

Having rules in a configuration file does not guarantee that the current connection uses them. In Home → Global Routing, check the active routing mode, then open Config to confirm which file is in use. This guide compares only the three modes relevant to the tests below. Scene is for scene-based configurations; select Config while troubleshooting these rules to reduce variables caused by switching scenes.

1. Back up the configuration

   In Config, save a copy of the current file or export a backup first so you can restore the original rules. Do not back up only the new lines you add.

2. Open the editor

   In Config, open the editor for the target configuration and find the [Rule] section. Make sure you are editing the configuration itself, not the server connection settings in Home.

3. Arrange the rules

   Place specific hostname exceptions before the broader rules they override. Then check IP ranges and GEOIP entries, leave FINAL at the end, and confirm that the edited file is selected after saving.

4. Check the routing mode

   Go back to Home → Global Routing → Config, confirm the correct existing server is selected, then connect. If the system asks for permission to configure a VPN, follow its prompts.

5. Send a new request

   Close the target page and visit it again. If needed, reconnect so you do not judge the new rules using an old connection. Record the target domain, time, and matching result before making another change.

3. Ordering DOMAIN-SUFFIX, IP-CIDR, and GEOIP rules

What a rule matches and where it appears in the list are separate concerns. Domain rules check hostnames, IP rules check destination addresses, and GEOIP uses an IP database for classification. A domain can resolve to multiple addresses, and its resolved addresses can vary across network conditions. Do not treat a single IP match as a permanent attribute of that domain.

After DOMAIN-SUFFIX, use example.com—not a full URL with https:// or a path such as example.com/path. A path is a separate part of the URL; pasting one into a domain field does not mean “proxy only this page.” A rule also does not automatically match a port just because the site commonly uses HTTPS port 443.

no-resolve means not to trigger an additional domain lookup just to match this IP rule. It does not disable DNS for the entire configuration or mean that the range can never match. If the request already has a destination IP that can be checked, it can still be matched against the range. If only the domain is known and you do not want this rule to trigger a lookup, note that skipping resolution may let the request continue to later rules.

• List the exact exceptions required for your use case first, followed by the corresponding domain suffix rules. This prevents a broad rule from taking precedence over an exception.
• Add IP ranges only when you need to route by destination address. /32 is a single IPv4 address; /24 covers 256 addresses.
• Broader GEOIP rules usually go after specific exceptions. This is a maintainable ordering convention, not a client-enforced priority for rule types.
• If a connection uses an IP address directly and has no available hostname, DOMAIN-SUFFIX alone cannot match it.

4. Complete examples for PROXY, DIRECT, REJECT, and FINAL

The policy at the end of a rule determines what happens when it matches: PROXY routes the request through the proxy, DIRECT connects to the destination directly, and REJECT denies the request. These actions are separate from server protocols. Switching an existing server from Shadowsocks to Trojan does not change the basic top-to-bottom rule matching order.

The [Rule] section below is for illustration only; it is not a complete configuration that can replace all existing settings. It assumes you already have a working server. The example domains do not provide any service. Before merging the rules, check the policy names, other rules, and required network ranges in your existing file.

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

• Although api.example.com is part of example.com, it matches the first exception, so it connects directly.
• blocked.example.com matches REJECT before the suffix rule; failure to access it is the expected result of that policy.
• 192.168.0.0/16 covers only this private address range, not every local network. Check other ranges separately if needed.
• GEOIP,CN,DIRECT relies on how the destination IP is classified in the database. It does not guarantee coverage of every Chinese-language website or consistent classification for a domain on every request.
• FINAL,PROXY handles only requests that did not match earlier rules; it does not change requests already matched by DIRECT to use the proxy.

Putting FINAL in the middle of the rules catches unmatched requests before later entries can take effect. Keep one clearly defined fallback at the end, and remove any duplicate FINAL entries left over from an older configuration to avoid confusion.

5. Find why a rule is not taking effect with one-variable tests

Check in this order: “active file → active mode → target request → actual match → connection result.” A page loading proves only that one request succeeded; it does not show which route it took. A page failing to load could be caused by REJECT, an unavailable destination service, or a proxy connection issue. Track rule matching separately from connection success or failure.

1. Establish a baseline: Keep the same network, existing server, and target. Record the result before changing anything, and avoid changing the server and rules at the same time.
2. Change one line only: For example, swap the order of DOMAIN and DOMAIN-SUFFIX, save, confirm the configuration is active, and send the request again.
3. Check request details: In the app’s connection records or logs, look for the target hostname, destination IP, and any visible policy information. If only an IP appears, first check whether hostname information is available.
4. Check all resources: Page content, images, and sign-in endpoints may use different domains. A rule for the main site alone may not cover every dependency.
5. Restore the baseline: Undo the change and visit the target again. If the result does not reliably change with the edit, check the cache, existing connections, and destination service status.

Handle subscription updates separately from configuration edits. Updating an existing server subscription in Home mainly refreshes server entries; updating a remote configuration in Config may replace the configuration contents. Neither should be treated simply as “refreshing rules.” Save a local copy before changing a remote configuration, then check that exceptions and FINAL are still present after the update.

6. Rule order and FINAL: frequently asked questions