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

01 Confirm Config mode before editing rules

Shadowrocket rules do not operate independently of the current routing mode. Check Global Routing on Home: to test rules in a configuration file, select Config. Proxy and Direct apply proxy or direct routing globally; their results cannot tell you whether custom rules are working as intended. If you are using Scene, check its actual routing setup before testing rules.

Use Home to check the connection and selected server, Config to manage configuration files, and Settings to review app preferences. In Config, confirm which file is active before opening it for editing. Do not edit a copy with the same name while continuing to use a different configuration.

1. Save a copy of the current configuration and note the existing Global Routing mode and server selection.
2. In Config, open the configuration you want to edit and find the [Rule] section.
3. Start by adding one easy-to-identify test rule; do not replace the entire rule set at once.
4. Save the changes and confirm the edited configuration is active. Return to Home and set Global Routing to Config.
5. Keep the connection on and make a new request. An existing connection is not suitable for testing a routing change.

02 Rules run from top to bottom; put exceptions first

A rule usually consists of a match type, a match value, and a policy, separated by English commas. For example, DOMAIN-SUFFIX,example.com,PROXY sends matching domains to PROXY. Rules are checked in the order they appear in the configuration. The first match determines the policy; later, more specific rules are not checked.

So “more specific first” is an ordering recommendation, not automatic sorting. To connect status.example.com directly while routing other requests under the same domain through a proxy, place the exact DOMAIN rule before DOMAIN-SUFFIX.

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

• status.example.com matches the first rule and uses DIRECT.
• www.example.com does not match the first rule; it matches the second and uses PROXY.
• example.com itself also matches the second rule.
• Requests that do not match either of the first two rules are handled by FINAL.

If you swap the first two rules, status.example.com matches DOMAIN-SUFFIX first, so the later DOMAIN rule never gets a chance to run. The example domains illustrate syntax only; whether they serve a webpage does not indicate whether a proxy service is working.

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

Domain and IP rules match different kinds of targets. DOMAIN-SUFFIX matches domain suffixes, not arbitrary strings: example.com and img.example.com match, but notexample.com does not. Use DOMAIN when you want to match one exact hostname.

192.0.2.0/24 is a documentation-only example range covering 192.0.2.0 through 192.0.2.255, not a usable server address. no-resolve means this IP rule will not initiate a DNS lookup for matching purposes; it can still match when a usable destination IP is already available. It does not disable all DNS, nor can it force a match when only a domain is available and no IP can be used.

GEOIP relies on the destination IP and geolocation data. It cannot guarantee that sites in a particular language or domains with a particular regional suffix will use the same policy. Sites on shared infrastructure may resolve to different addresses. To route a specific domain consistently, use an explicit domain rule instead of relying on its current geolocation.

04 What PROXY, DIRECT, REJECT, and FINAL do

PROXY, DIRECT, and REJECT are policies applied when a rule matches; FINAL is a rule type. They are not the same kind of setting. FINAL,PROXY means “use PROXY when no earlier rule matches”; FINAL does not provide proxy functionality by itself.

• PROXY: Sends the request through the proxy policy. In a basic setup, check which server is selected on Home. If the configuration uses a policy group, also check the active selection in that group. Writing PROXY alone does not create a server.
• DIRECT: Connects to the destination without forwarding through a proxy server. The connection may still be handled by the app's tunnel and rules; DIRECT does not turn off the connection switch.
• REJECT: Blocks matching requests. Use it for destinations you explicitly want to block, not as a general fix for connection failures.

These examples show two different routing outcomes; do not combine and copy both rule sets. Before choosing a policy for FINAL, decide how requests not covered by other rules should be handled. If FINAL appears near the start of the rule section, later exceptions cannot match as intended. Keeping one clearly defined fallback rule at the end makes the configuration easier to inspect.

05 Full example: from exact domains to the final fallback

This configuration snippet is for practicing rule order and shows only the [Rule] section. It does not define servers and should not replace other sections in an existing configuration. The example domains and addresses are for documentation only; use match targets you have verified for your own setup.

[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

1. First, check for status.example.com and connect directly if it matches.
2. Next, check whether the request is for blocked.example.com or one of its subdomains; reject it if it matches.
3. Then route other requests for the example.com domain through a proxy.
4. For requests not yet matched that have a usable destination IP, check the example address range.
5. Route all remaining requests through the final PROXY fallback.

The second rule must come before the third because blocked.example.com matches both suffix rules. Even when an IP-CIDR rule covers a different range, it cannot override a domain policy that already matched. Read rules as “specific exceptions first, broader groups next” rather than simply grouping all rules of the same type together.

06 Test rules: record matches and connection results separately

Whether a webpage opens is not the only way to tell if a rule matched. A request routed through PROXY may still fail if the server is unreachable; DIRECT may be affected by network restrictions; and a failed request under REJECT may be the expected result. During troubleshooting, record both the policy used and what happened when it was applied.

1. Choose a target: Pick a real, fully qualified domain you can verify. Record how it behaves before making changes; do not use example addresses to test connectivity.
2. Keep conditions consistent: Use the same network, server, and Config, and confirm that Global Routing is set to Config.
3. Make a new request: After saving the rules, close the old page or connection and try again to avoid the effects of connection reuse.
4. Check the records: Review the app's request log for visible details such as the actual domain, destination IP, matched rule, and policy. Log labels and displayed information depend on the current app interface.
5. Change one thing at a time: If the wrong rule matches, adjust the rule order. If the right rule matches but the request fails, check DNS, the proxy server, or the direct connection path.

A webpage may request resources from multiple domains: the main document, images, APIs, and media may each match different rules. Adding a rule for the main domain does not guarantee that all related resources use the same policy. Start with the actual hostname of the failed request; do not broaden the rule based only on the domain in the browser's address bar.

07 Common questions about custom rules