Shadowrocket Rules Guide: How DOMAIN-SUFFIX, GEOIP, FINAL, and Other Rules Work

First, make sure rules are being used for routing

Rules determine which policy a connection uses; they do not create a working proxy service. Even with a rule such as DOMAIN-SUFFIX,example.com,PROXY, you still need a working proxy configuration. This guide assumes you already have a provider and subscription, and focuses on checking the [Rule] section of your configuration.

In Home → Global Routing, Proxy, Direct, Config, and Scene are different routing modes. Proxy and Direct are useful for quick comparison tests. To check the rules in your current configuration, select Config. Scene switches routing behavior based on a scenario; seeing Scene selected does not, by itself, confirm that a particular set of rules is active.

1. Back up your configuration

   Open Config, confirm which configuration file is currently in use, and save a copy before making changes. Note the current Global Routing selection so you can restore it after testing.

2. Select rule-based routing

   Go to Home → Global Routing → Config. Then check that the enabled file in Config is the one you intend to edit.

3. Change one rule at a time

   In Config, open the file’s editing options and find [Rule]. Add or change one rule at a time, and leave the other configuration sections intact.

4. Save and verify

   Save the configuration, start a new test connection, and check the connection log for the destination, matched rule, and applied policy. If an existing connection is being reused, close the relevant page and visit it again.

Domain rules: exact, suffix, and keyword matches

Common rules use the format “type, match value, policy,” with fields separated by English commas. For domain rules, enter only the hostname—no https://, path, query parameters, or port. For https://api.example.com:443/v1, the domain rule matches api.example.com, not the full URL.

DOMAIN-SUFFIX usually needs neither a leading dot nor the form *.example.com. A suffix match already includes the domain itself and its subdomains. Adding an asterisk to a regular suffix field does not create a wildcard expression.

Use DOMAIN-KEYWORD when you specifically need a substring match; it is not shorthand for an exact domain rule. For example, the keyword example may also match example-news.test. To cover one site and its subdomains, prefer DOMAIN-SUFFIX. For a single host, use DOMAIN.

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

In the example above, api.example.com uses PROXY, www.example.com uses DIRECT, and only example-news.test proceeds to the keyword rule. These reserved example domains are used only to explain the syntax; the corresponding websites are not guaranteed to be accessible.

IP-CIDR and GEOIP: match addresses, not URLs

IP-CIDR matches IPv4 address ranges. 192.168.0.0/16 covers addresses from 192.168.0.0 through 192.168.255.255. Use /32 for a single IPv4 address. The prefix length specifies the network range, not a port number.

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,203.0.113.8/32,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

The 203.0.113.8 address in this snippet is reserved for documentation examples; it is not a working service address. no-resolve means not to perform a DNS lookup solely to match this IP rule. It does not disable DNS across the app or mean that every request using this rule needs no DNS lookup. If the destination address is already available, it can still be matched.

The result of GEOIP depends on the IP geolocation database. A domain may resolve to different addresses because of its CDN, DNS responses, or network conditions, so its GEOIP result can change. If a destination must always use a specific policy, add an explicit domain rule before GEOIP instead of relying only on the IP’s location.

Rules are checked from top to bottom; put FINAL last

For the standard rules covered here, a connection is checked against rules in order. The first match determines the policy; processing does not continue to a later rule that “looks more specific.” Rule types have no automatic priority. If a broad DOMAIN-SUFFIX rule comes before a more specific DOMAIN rule, the latter may never take effect.

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

• Put exceptions first: api.example.com needs a separate policy from the rest of example.com, so place it before the suffix rule.
• Then define the broader match: Use DIRECT for the rest of example.com and its subdomains. These connections will not proceed to the IP rules below.
• Put the fallback last: FINAL,PROXY catches connections that have not matched an earlier rule. If it is moved to the first line, the regular rules below it will never get a chance to match.

DIRECT means connecting to the destination directly; it does not mean bypassing every system network condition. PROXY sends the connection through the proxy route; it does not guarantee that the connection will succeed. If the policy field names a custom policy group, that name must exactly match a group defined in the configuration. This guide uses only DIRECT and PROXY to avoid undefined group names.

If a rule does not work, check matching and connectivity separately

A page failing to load does not, by itself, mean the rule is wrong. First check whether the request matched the expected rule, then check whether the selected policy can establish a connection. If the match log shows PROXY but the request still fails, check your existing proxy service and its connection settings. Adding more rules for similar domains usually will not fix a transport problem.

1. Confirm that Home → Global Routing → Config is selected, and that the file you edited is the one currently enabled in Config.
2. Make a new request to the same full URL and note the actual hostname. Redirects, images, and API calls may use different domains, so check each one separately.
3. Check whether an earlier DOMAIN-SUFFIX, DOMAIN-KEYWORD, or FINAL rule is matching first.
4. If the expected rule matches, compare access using Proxy and Direct as a temporary test, then restore Config. Change one condition at a time.

The error identifiers below come from Apple’s networking error system. Refer to them only when the diagnostic information shows the exact error text. They identify types of network request failures; they are not syntax errors from the Shadowrocket rule parser, and the error code alone cannot identify which part of the connection failed.

Other common text-entry mistakes include using Chinese commas, writing FINAL,PROXY as if it had three fields, putting https://example.com in a DOMAIN-SUFFIX field, and using a policy group name that does not exist. Check each field line by line before saving; do not replace the entire configuration at once. If a remote source manages the configuration, also check whether future updates will overwrite local changes and keep a copy you can restore.

FAQ: How to verify a rule change

For a complete check, confirm three things: the request’s actual hostname is correct, the matched rule is correct, and the applied policy is what you expect. Then verify that the page and its API requests complete successfully. This separates a rule-selection problem from an unavailable route, rather than relying on repeated switching and guesswork.