Shadowrocket Custom Rules: Rule Order, FINAL, PROXY, DIRECT & REJECT

1. Before Rules Take Effect: Check Config and Global Routing

Custom rules go in the [Rule] section of a configuration file. Before editing, check the Config page at the bottom to confirm which configuration is active. Opening another file to view its contents does not switch to that configuration. Keep a copy of the original, then edit a duplicate so you can recover if parsing errors or unintended blocking occur.

Go back to Home and check Global Routing. Select Config to test the rules in this guide. Proxy and Direct are global routing choices; results in either mode cannot tell you whether a particular custom rule is working. If Scene is active, check its actual routing choice. During troubleshooting, you can temporarily select Config to reduce variables.

1. Open Config, note the name of the active configuration, and save a copy of its original contents.
2. Edit the configuration’s [Rule] section, keeping the other section headers and required settings intact.
3. After saving, confirm that the edited configuration is still selected.
4. Go to Home → Global Routing, select Config, and then make a new test request.

2. Top-to-Bottom Matching: Order Comes Before Specificity

Rules in a configuration are checked in order. The first rule that matches a request determines its policy; later, “more specific” rules are not considered. Put exact-domain rules before broader suffix rules, exceptions before general rules, and FINAL last.

Here’s an example with the wrong order. When requesting api.example.com, the first DOMAIN-SUFFIX rule already matches, so the request uses PROXY. The later DOMAIN rule does not take priority just because it matches a narrower scope.

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

To route this subdomain directly, swap the first two lines. example.com is a reserved example domain. Write rules for your actual targets; do not treat the example as a connectivity test service.

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

3. What DOMAIN-SUFFIX, IP-CIDR, and GEOIP Match

Domain rules and IP rules check different things. DOMAIN matches a full domain name; DOMAIN-SUFFIX matches a domain suffix; IP-CIDR checks whether the destination IPv4 address falls within a specified range; and GEOIP uses an IP geolocation database to determine the destination’s region. GEOIP,CN refers to the region associated with the destination IP—not the device’s location or the selected server’s location.

no-resolve means not to trigger a DNS lookup solely to try to match this IP rule. It does not disable global DNS or prevent the normal resolution needed when an app accesses a domain. The rule may still match when the request already has a usable destination IP; this does not mean that all domain requests will skip or match the rule.

In IP-CIDR, /16 is a prefix length, not a port. This example covers 192.168.0.0 through 192.168.255.255; it does not cover all private addresses. To route other local subnets directly, configure each range as needed. Domain rules also do not distinguish HTTPS on port 443 from HTTP on port 80.

4. How PROXY, DIRECT, REJECT, and FINAL Work Together

PROXY, DIRECT, and REJECT are policies applied when a rule matches. PROXY hands the request to the currently selected proxy; if your configuration uses a custom policy group, check its selection as well. DIRECT uses a direct route; it does not turn off the system VPN. REJECT blocks the request and is intended for targets you explicitly want to block—not as a fix for resolution failures.

FINAL is a rule type, not a fourth outbound route. It has no domain or network condition and uses the syntax FINAL,policy, rather than the three fields used by ordinary rules. If FINAL appears too early, ordinary rules after it will never get a chance to match.

To proxy listed domains and send everything else direct, set those domain rules to PROXY and finish with FINAL,DIRECT. To send explicitly allowed targets direct and proxy everything else, arrange the rules the other way around. In either case, handle necessary local-access exceptions first. The number of rules alone does not determine which setup is better.

5. A Rule Example You Can Trace Line by Line

This example combines an exact-domain exception, a blocked target, a domain suffix, a private IP range, a regional match, and a fallback. It demonstrates ordering only; it is not a complete configuration. Keep existing content such as [General]. Adjust the rules for your actual targets, and do not replace the entire configuration file with this snippet.

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

• api.example.com: The first line matches. Use DIRECT and stop checking the suffix rule.
• telemetry.example.com: The second line matches. Use REJECT. This is an arbitrary choice to demonstrate syntax, not a judgment about the domain’s purpose.
• www.example.com: The first two lines do not match, so the third line matches. Use PROXY.
• Destination IP 192.168.1.20: If no domain rule matched first, the fourth line can match this private address.
• Other targets: If GEOIP identifies the destination address as CN, use DIRECT. Otherwise, continue to FINAL and use PROXY.

Because the domain suffix rule comes before GEOIP, regular subdomains of example.com use PROXY first; the destination IP’s region does not determine their route. That is the intent expressed by this ordering: domain policies take precedence over the broader regional rule that follows. To express a different intent, reorder the rules and check for any impact on existing exceptions.

6. Verify with a New Request and Match Logs, Not Just Whether a Page Loads

A page loading successfully shows only that the request completed; it does not prove that the expected policy was used. A page may also request several domains: its main document could match DIRECT while static assets match PROXY or REJECT. Check the specific destination in the request log and confirm the matching rule and final policy. Don’t rely only on the connection toggle on Home.

1. Keep the setup consistent: Note the active Config, Global Routing, and selected proxy. Don’t change the network and policy at the same time during testing.
2. Make a new connection: After saving the configuration, create a new test request. An existing long-lived connection may continue using its original route, so it is not a reliable way to test new rules.
3. Check the destination: Match against the full domain in the actual request, not just the main site name in the address bar.
4. Find the first match: If the result is unexpected, start at the top of the list and find the first matching rule. Pay particular attention to broad suffix rules and any FINAL placed too early.
5. Separate routing from connectivity: If a request fails after matching PROXY, check the selected service and resolution. If it fails after matching DIRECT, check whether the local network can reach the target.
6. Change one thing at a time: Move one rule or change one policy, save, and test again. Record the result once it works.

If a remotely maintained configuration provides the rules, check after an update that your custom lines are still there. Updating a server subscription and updating configuration rules are separate operations; a refreshed server list does not mean the active rules were replaced. Keep the before-and-after content and test targets so you can repeat the same checks after the next update.

7. Common Edge Cases: Rules Still Don’t Behave as Expected