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

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

Shadowrocket checks rules in the order they appear in the configuration. When a connection matches a rule, Shadowrocket applies that rule’s policy and stops; it does not continue looking for a “more specific” match. Domain rules do not automatically take precedence over IP rules, and exact-domain rules are not automatically placed ahead of suffix rules. To handle an exception, put it earlier in the list.

For example, to send login.example.com DIRECT while routing example.com and its other subdomains through PROXY, order the rules as shown below. If you swap the first two lines, the login domain will match DOMAIN-SUFFIX first, and the later DOMAIN rule cannot change the decision already made.

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

2. PROXY, DIRECT, and REJECT: how connections are handled

The first part of a rule specifies what to match; its final field specifies how to handle the connection. PROXY sends it through the proxy route; the actual exit depends on the currently selected server or the policy setup in the configuration. DIRECT connects to the destination without using a proxy exit. REJECT blocks the matching connection. These are not protocol names like Shadowsocks, VMess, VLESS, or Trojan, nor are they ratings of connection quality.

DIRECT does not guarantee a successful connection. The destination may deny access, the local network may be unavailable, or DNS may return an incorrect address. Similarly, a PROXY match only means the rule selected the proxy route; it does not guarantee that the remote service is reachable. When troubleshooting, check “Was the intended route selected?” and “Does that route work?” separately.

3. Global Routing: test custom rules in Config mode

First check the current mode under Home → Global Routing, then assess whether the rule is working. Config routes traffic according to the rules in the active configuration. Proxy and Direct are useful for comparing routes, but they do not prove that a particular custom rule matched. Scene involves selecting a scene; avoid changing scenes during initial troubleshooting, or your test conditions may change.

After comparing routes, switch back to Config. Settings → On Demand manages when connections are made on demand; it does not reorder rules or make rules placed after FINAL reachable. Keep the network and connection state stable during testing. Avoid changing automatic connection behavior, switching networks, and editing rules at the same time.

4. Common rule syntax: domains, IP ranges, and FINAL

Common rules use commas between fields, not the full-width Chinese comma. For domain matches, enter only the domain—no https://, port, or URL path. For example, when visiting https://api.example.com:443/v1, the DOMAIN target is api.example.com, not the entire URL. Port 443 belongs to this example connection, not to the domain field.

no-resolve after IP-CIDR means the rule will not actively trigger a domain lookup just to test the match. It does not mean that every domain is resolved first and then checked against the IP range. When testing devices on a local network, check access by IP address and by device hostname separately, and note whether DNS returns a public or private address.

GEOIP relies on IP geolocation data. Its result is not based on a website’s language, domain suffix, or operator’s location. If a service must always use a specific route, an explicit domain rule placed before GEOIP is easier to verify than an indirect decision based on IP location.

• Check characters: Make sure keywords, commas, and policy fields are complete, and watch for full-width characters introduced when copying.
• Check scope: DOMAIN-SUFFIX,example.com does not match notexample.com and does not refer to a URL subdirectory.
• Check addresses: 192.168.0.0/16 is an example of a private IP range; it does not mean your local network uses that range.
• Check the fallback: Keep one valid FINAL rule and place it at the end of the active rule list.

5. Recommended order: specific exceptions first, FINAL last

Here is a rule example to illustrate the order: allow a specific login domain to connect directly, reject a specific domain, then handle the domain suffix as a whole; next, handle the private IP range and GEOIP, and finally send unmatched traffic to FINAL. This demonstrates ordering, not a one-size-fits-all configuration. Remove or adjust rules to suit your actual destinations.

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

This order puts “specific exceptions first,” but it does not mean domain rules must always come before IP ranges. If all local network destinations must connect directly, also check whether an earlier domain rule could route a destination resolved to a local IP through PROXY, and adjust for DNS behavior. Order rules to match your intent; do not treat one example as a fixed priority scheme.

1. Visit login.example.com: The first DOMAIN rule matches and selects DIRECT; later suffix rules are not checked.
2. Visit blocked.example.com: The second rule matches and selects REJECT. Moving it below the suffix rule would change the result.
3. Visit api.example.com: The first two rules do not match. DOMAIN-SUFFIX matches next and selects PROXY.
4. Connect directly to 192.168.1.1: If none of the earlier domain rules match, the corresponding private IP range rule matches and connects directly.
5. Visit another destination: GEOIP is checked next; if it still does not match, the connection reaches FINAL.

FINAL,PROXY and FINAL,DIRECT are both valid fallback choices. The difference is which route unknown destinations take by default. FINAL is not a retry mechanism for failed connections: if an earlier rule selects PROXY and the proxy connection fails, the connection does not skip that rule and fall through to FINAL. To change the route for a failing destination, edit the relevant rule or fix the selected connection.

6. Edit and test: change one condition at a time

The steps below refer to the iPhone / iPad interface. Rules belong to the configuration file active in Config; changes to the server list in Home do not mean the rule file has also been updated. Back up the original configuration before editing, and make sure you know whether you are changing a local file or one that may be overwritten by a remote update.

1. Check the mode

   Go to Home → Global Routing and select Config. Note the currently selected server, and do not change the exit route during testing.

2. Check the file

   Open Config and confirm which configuration file is active. Preserve the original contents before editing. Changes to a different, inactive file will not affect traffic routing for the current connection.

3. Reorder the rules

   Find [Rule] in the configuration and move specific exceptions above any rules that cover them. Confirm that FINAL is last. If you are copying rule lines only, do not insert another section header into an existing [Rule] section.

4. Save and reconnect

   Save the changes and confirm that the edited configuration is active. Reconnect if needed. Close the old test page or end the existing connection, then make a new request to avoid reusing a connection established before the edit.

5. Check the result

   Look for the destination domain, destination IP, and applied policy in the connection records or logs. Record the test destination, match result, and observed behavior before making further changes.

Build a minimal test set with three destinations: one expected to use DIRECT, one expected to use PROXY, and one without a specific rule that should reach FINAL. If you intentionally use REJECT, add one clearly identified blocking test. Do not judge rule correctness solely by whether a webpage opens: both DIRECT and PROXY can work, and pages may reuse cached content.

7. Rules not working: troubleshoot by symptom

Rule problems often come from changing test conditions, not from a lack of rules. Start with a destination you can test repeatedly, then work through the checks below. For broader network troubleshooting, see Troubleshooting.

Finally, confirm three things: Config is selected, the correct file is active, and exceptions appear before broader rules. Once all three are confirmed, check the final policy using a new connection. Rules select how traffic is handled; they cannot verify the availability of services you already use or automatically fix invalid connection settings.