Shadowrocket Custom Rules: Matching Order, FINAL Fallback, and PROXY/DIRECT/REJECT

1. Confirm Config Is Active Before Checking Rule Order

Saving rule text does not mean the current connection is using it. On Home, check Global Routing; to route traffic using the rules described here, select Config. Then open Config and confirm which configuration file is active. Editing a file that is not selected will not change the matching results for the active configuration.

Proxy, Direct, Config, and Scene in Global Routing are routing modes, not four rule keywords. Proxy and Direct route all traffic through a proxy or connect directly, respectively. Config applies the routing rules in the active configuration. Scene organizes routing behavior by context, so check the active scene when troubleshooting. Do not confuse routing modes with the policies at the end of rule lines.

1. In Config, keep a copy of the current file and note the name of the configuration in use.
2. Go to Home → Global Routing, select Config, and make sure you are not checking rules under a different routing mode.
3. Return to Config, edit the selected configuration, save it, and start a new test request.
4. Check the destination and policy in the in-app connection log. If an existing connection is still using the old route, end it and test again.

2. Rules Match Top to Bottom: No Search for a “More Specific” Match

Most rules are checked in list order. The first matching rule determines the policy, and later rules are not reordered for the same request. Shadowrocket will not automatically move a later rule to the top just because it contains a longer domain. The configuration author must place exceptions before broader rules.

For example, if DOMAIN-SUFFIX,example.com,PROXY comes before DOMAIN,api.example.com,DIRECT, the first rule matches api.example.com. To connect directly to this subdomain, move the DOMAIN rule above it. These domains are examples for explaining syntax only; they do not represent available services.

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

3. Rule Syntax: Separate Match Conditions from Policies

Most common rules use a comma-separated format: type, match value, policy. FINAL is a special fallback rule and does not need a match value. Use English commas, put one rule on each line, and do not paste an entire configuration into a single match-value field.

Do not include a protocol prefix, webpage path, or port in a domain rule. For example, if a destination URL includes HTTPS, a path, and port 443, the DOMAIN match value should still contain only the hostname. To route traffic by port, use the appropriate port rule instead of appending :443 to the domain.

4. Ordering DOMAIN-SUFFIX, IP-CIDR, and GEOIP Rules

There is no fixed rule-type order that works for every configuration. What matters is putting exceptions before rules that would cover them. A typical order starts with exact-domain exceptions, followed by domain suffixes, specific IP ranges, broader GEOIP rules, and finally FINAL. If a particular IP range needs priority, you can move it higher, but be aware of which requests it may cover.

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

This snippet illustrates rule order only; do not use it as a replacement for a complete configuration. api.example.com is a DIRECT exception placed before the suffix rule, and metrics.example.com is a REJECT exception placed first as well. Other example.com subdomains use PROXY. The 192.168.0.0/16 rule covers only the specified private range, not every local network address.

• Domain conditions: Use these to express clear intent for a website or subdomain. Do not change the policy for an entire suffix just to handle an exception for one subdomain.
• IP-CIDR conditions: Use these for known address ranges. Whether a domain request has an IP available at this step depends on the resolution flow and options such as no-resolve.
• GEOIP conditions: These usually cover a broad range, and the result depends on the destination IP and the database. If the same domain resolves to different addresses, the match may change.
• FINAL condition: Put this after all specific conditions. Only requests that have not matched a preceding rule use this policy.

no-resolve does not disable DNS resolution for the entire app, nor does it guarantee that this rule can never match a domain request. It limits actively triggering resolution for the IP rule. If the destination is already an IP, or an address is available from an earlier step, check the actual connection log to determine what happened.

5. Choose PROXY, DIRECT, or REJECT for FINAL

FINAL determines what happens to requests that have not been explicitly classified; it is not a retry switch for failed connections. If a preceding rule matches PROXY and the proxy connection fails, the request does not then fall through to FINAL. To use a backup outbound, check the behavior of the relevant policy group instead of relying on the final fallback to handle failed requests.

DIRECT may still be handled by a system-created VPN tunnel, but its outbound policy does not use a proxy server; it does not mean Shadowrocket is turned off. REJECT blocks requests at the rule level and does not automatically determine whether a request is “useful.” If a domain serves multiple functions, rejecting the entire domain may also disrupt normal features.

6. Verify Changes and Roll Back

Check the destination, matching rule, and outbound policy together; a page loading successfully does not by itself prove the configuration is correct. Browser cache, existing long-lived connections, and requests to multiple domains on the same page can all make the apparent result differ from the scope of the new rule.

1. Keep a baseline: Save the original configuration before editing, and note a destination that works along with the current routing mode.
2. Make small changes: Change one rule or its order at a time, save, and confirm that the file is still selected in Config.
3. Start a new connection: Close and reopen the test page. If needed, end the app’s existing connection before making another request.
4. Check the log: Find the actual hostname or IP in the in-app connection log and check the matching rule and final policy, not just the website’s main domain.
5. Restore the baseline: If something goes wrong, undo the last rule change or reselect the saved configuration, then test the same destination again.

If your configuration comes from a remote source, also check whether an update overwrote your local changes. Updating a server list and updating a Config rule file are separate operations; verify each update target. Keep custom rules you want to retain in a configuration you can manage and roll back.

7. Common Questions About Custom Rules