Shadowrocket Rules Guide: DOMAIN, DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL

1. Rule Structure and the Global Routing Prerequisite

Rules are neither connection settings nor a list that identifies traffic by app name. They use information available for each request, such as its domain or destination IP, to select a policy. To apply rules in a configuration file, select Config under Home → Global Routing on iPhone or iPad. Editing the Config file while Proxy or Direct is selected won’t verify rules as described here.

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

Most conditional rules have three parts: type, match value, and policy, separated by commas. FINAL has no match value, so it uses two parts. DIRECT means connect directly; PROXY sends the request through the proxy route. Neither field is where you enter the address or password for your existing server. If you reference a custom policy name in the configuration, it must match the defined name exactly.

• Config: Uses rules in the currently selected configuration to choose where requests go. This is the mode required for the steps in this guide.
• Proxy: Applies a global proxy mode; it does not verify whether a specific DIRECT rule works.
• Direct: Applies a global direct mode; it does not verify whether a specific PROXY rule matches.
• Scene: Switches modes based on configured scene conditions. When troubleshooting, also check which configuration and policy the active scene uses.

2. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD

These three domain rules differ in what they consider a match. DOMAIN requires an exact domain match. DOMAIN-SUFFIX matches the specified domain and its subdomains. DOMAIN-KEYWORD checks whether a domain contains a specified string. None of them matches URL paths, so adding /video/ won’t distinguish pages on the same domain.

For example, to proxy all of example.com while connecting its login host directly, put the exact-domain exception first, followed by the suffix rule. DOMAIN-SUFFIX doesn’t need to be written as *.example.com; the asterisk isn’t required to specify subdomains here.

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

In this configuration, login.example.com matches the first line and is not checked against the second. img.example.com doesn’t match the first line, but does match the second. If you swap the lines, the suffix rule takes the request first, leaving the exact-domain exception ineffective. “More specific rules first” is an order chosen by the editor, not automatic sorting by the system.

3. GEOIP and IP-CIDR: Matching by Destination Address

GEOIP matches the destination IP against the data in the configured geolocation database. GEOIP,CN,DIRECT sends destination IPs classified as CN by that database through DIRECT. It doesn’t use the device’s location or the domain suffix. A domain served from multiple locations may resolve to different IPs in different regions, which can change the rule outcome.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR matches an address range. 192.168.0.0/16 covers 192.168.0.0 through 192.168.255.255; 10.0.0.0/8 covers 10.0.0.0 through 10.255.255.255. These examples show only some private IPv4 ranges; they aren’t a complete set of local network rules.

no-resolve doesn’t “block all DNS queries” or mean “always connect directly.” If a request has only a domain and no available IP yet, an IP rule with this option won’t resolve the domain just to check for a match; the request may continue to later rules. For IPv6 address ranges, use the corresponding IP-CIDR6 rule. An IPv6 prefix can’t be matched against the IPv4 examples above.

• To connect a fixed private-network address directly, confirm the actual address first, then use an appropriate IP-CIDR range.
• If a domain must use a specific policy, prefer a domain rule rather than relying on the region of its current IP address.
• If an IP rule doesn’t match, check the destination address, address family, resolution timing, and whether an earlier rule already matched.

4. FINAL Placement and a Complete Rule Example

FINAL is an unconditional fallback and must be the last rule in the list. If it appears earlier, later conditions never get a chance to handle requests already caught by FINAL. Choosing DIRECT or PROXY for FINAL is a choice of default routing policy; there’s no one setting that suits every configuration.

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

This syntax example covers all six rule types discussed here. It doesn’t include server or policy group definitions and isn’t a complete, ready-to-connect configuration. The example domains are for illustration; when testing, use domains whose purpose and actual addresses you know. Whether PROXY can establish a connection still depends on the validity of your existing proxy configuration.

1. login.example.com: Matches the first rule and uses DIRECT.
2. static.example.com: Matches the second rule and uses PROXY; GEOIP isn’t checked afterward.
3. 192.168.1.20: If no earlier domain rule matches, it reaches the private-range rule and uses DIRECT.
4. Other requests: Later conditions are checked first; if none match, FINAL selects PROXY.

5. Edit and Verify Rules in Config

These steps refer to Home and Config on iPhone and iPad. Save a copy of the existing configuration before editing; don’t replace the entire file with a snippet containing only [Rule]. If the file already has that section, edit it in place rather than adding a duplicate. A remote configuration update may overwrite local changes, so first check whether you’re editing a local copy or an update source.

1. Save a backup

   Open Config, find the configuration currently in use, and save a copy of its original contents. Note the file name so you can confirm later that you enabled and edited the same file.

2. Edit the rules

   In Config, open the target configuration for editing and find [Rule]. Add a clearly scoped domain rule and confirm that FINAL is still the last rule in the list.

3. Enable the configuration

   After saving, confirm the edited configuration is selected in Config. Then go to Home → Global Routing → Config to make sure the app isn’t still in Proxy, Direct, or another scene mode.

4. Create a new request

   Disconnect and reconnect, close any existing connection from the test page, then visit the target domain. Check the connection log for the destination, matched rule, and selected policy; don’t rely only on whether the page loads.

5. Check each case

   Test an exact domain, a subdomain, and an unmatched domain separately. Change only one condition or rule order per test and note the difference. If something goes wrong, restore the backup and narrow the test scope.

Existing long-lived TCP connections or reused connections may keep using the route they were established with, even after rules are saved. A page may also be served from the browser cache. So a single refresh that appears unchanged doesn’t prove the rules failed to apply; check the log for a new connection.

• Check subscriptions and rules separately: Updating existing Subscribe content under Home usually refreshes server details. It doesn’t mean the rules in the current Config were updated too.
• Check automatic connection and routing separately: Settings → On Demand manages automatic connection conditions; it doesn’t select Config as the routing mode.
• Check protocols and matching separately: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are different connection protocols. Domain rules don’t automatically convert one protocol to another.

6. Troubleshooting Rule Mismatches and Connection Errors

First distinguish “the wrong rule was selected” from “the correct route was selected, but the connection failed.” A page may request content from several domains, including the main site, images, login, and APIs. A DOMAIN rule for the main site doesn’t guarantee that its resource domains use the same policy. If some content fails to load, start with the actual destination domain in the failed connection rather than broadening the rule to a keyword match.

Use these error messages to troubleshoot only when they appear in the actual connection log; they aren’t specific indicators of a rule mismatch. If the log shows FINAL, none of the earlier rules caught the request. Check whether the actual domain matches, whether the request uses an IP directly, whether IP matching depends on resolution timing, and whether the configuration is enabled.

To expand your setup, see the rule reference, but start with a short, understandable rule list. For every rule you add, identify what it matches, the expected policy, and why it belongs in that position. This makes troubleshooting easier than adding many rules whose sources are difficult to verify.