Shadowrocket Rule Syntax: DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL Matching Explained

Rule format: type, match value, and policy

Rules are commonly written as comma-separated fields, such as DOMAIN-SUFFIX,example.com,DIRECT. The first field specifies what to check, the second sets the match condition, and the third determines how to handle the connection when the rule matches. Rules are not URL filters: do not include https://, paths, query parameters, or ports in the domain field.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,tracker,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

This is a syntax example, not a complete configuration for every network. [Rule] is the rules section. When editing an existing configuration, change its existing section rather than adding a duplicate. example.com and 192.0.2.0/24 are documentation examples and cannot be used to verify whether a real service is reachable.

• DIRECT: Connects directly to the destination, subject to current network conditions.
• PROXY: Routes the connection through a proxy policy. Before using it, check the policy reference in the current configuration and the available options in Home.
• REJECT: Rejects the matching connection; it does not remove an element from a webpage.
• Custom policy names must match the definitions in the configuration. A misspelled name and an incorrect match condition are separate issues.

FINAL has no match value, so write it as FINAL,PROXY. Do not add a match value to make it fit the three-field format, as in FINAL,example.com,PROXY. In the example, no-resolve is an extra parameter for IP rules, not a fourth policy.

DOMAIN rules: exact match, suffix, and keyword

Domain rules determine which policy to use for a given name. The three rule types differ in their matching boundaries, not their priority. The examples below use the same domain. “Matches” means the condition is met; whether a rule is actually reached depends on whether an earlier rule has already matched.

DOMAIN-SUFFIX checks domain-label boundaries; a matching ending alone is not enough. Usually, enter example.com directly—there is no need to add *.. If you only want to handle api.example.com without affecting other subdomains, DOMAIN makes the scope easier to verify.

An app may connect to several domains for its main site, sign-in, images, and APIs. Adding a rule for the main site does not mean the other requests will match it. Check each one in the connection logs instead of continually broadening the keyword.

GEOIP and IP-CIDR: geographic location and address ranges

GEOIP,CN,DIRECT checks the region associated with the destination IP in the geographic database being used. It does not check the webpage language, domain suffix, user's location, or the service provider's place of registration. Domains can resolve to addresses in different regions, so “Chinese-language sites must match CN” is not a reliable troubleshooting assumption.

IP-CIDR matches IPv4 addresses by address and prefix length. For example, 192.0.2.0/24 covers 192.0.2.0 through 192.0.2.255, while 192.0.2.8/32 matches one address. Use the corresponding IP-CIDR6 rule for IPv6 ranges; do not put an IPv6 address in an IPv4 example.

IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

The example places a single-address exception before a larger range. For a destination of 192.0.2.8, the first line matches, so the second line does not change the result. Swap the lines, and the broader /24 range takes precedence.

• no-resolve means this IP rule will not actively trigger domain resolution; it does not “turn off all DNS.”
• A request may still match a rule with no-resolve if its destination is already an IP address or a usable destination IP is available when the rule is checked.
• If only the domain is available and there is no usable IP, do not expect this rule to trigger an extra lookup for matching. The request may continue to the following rules.
• The addresses used by a service can change. Do not treat an IP from a single lookup as a permanent basis for your configuration.

Rule order: specific exceptions first, FINAL last

Rules are checked in order, and the first matching rule determines the policy for that connection. A more “specific-looking” rule below it will not override the result. DOMAIN does not automatically come before DOMAIN-SUFFIX, and IP-CIDR does not get priority just because its range is smaller.

DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

With this order, login.example.com uses DIRECT, img.example.com uses PROXY, and destinations that match neither of the first two rules fall through to FINAL. If the suffix rule comes first, the login domain will match it before the exact-domain exception can take effect.

A practical order is to put a few clear exceptions first, followed by broader domain or address ranges, and finish with one explainable FINAL rule. This makes a configuration easier to maintain; it does not mean every configuration must be grouped mechanically by rule type.

Edit and test rules in Config

Before testing, keep a copy of the original configuration and confirm that the active configuration is the same file you are editing. Updating server entries in a subscription is separate from editing rules in Config. Refreshing an existing subscription in Home does not verify which rules are currently active.

1. Keep a copy of the original configuration

   Open Config, save a recoverable copy of the configuration, then open the editing option for the configuration you want to change. Find [Rule] and confirm that you are editing the rules section.

2. Add one rule

   Start with one narrowly scoped DOMAIN rule, placing it above any suffix or keyword rules that could match first. Change one condition at a time, then save.

3. Activate the rules configuration

   In Config, make sure the configuration you just saved is selected. Then go to Home → Global Routing → Config. Proxy and Direct are global modes and cannot verify per-rule routing here.

4. Start a new connection

   Reopen the destination page or make the app send the request again, then check the destination, matching rule, and policy in the connection logs. Existing long-lived connections may be reused, so a page opened before the change is not enough to verify it.

5. Check which rule matched

   If the log shows a different rule, check its position first. If the expected rule matched but the connection failed, check the outbound connection. Add other conditions one at a time, after verifying the first rule.

In Global Routing, check Scene against the scene configuration to confirm which policy is actually in use. For an initial test, switch explicitly to Config to reduce variables. Settings → On Demand controls when VPN connections are established based on conditions; it does not change the matching range of DOMAIN-SUFFIX or replace selecting the active configuration.

Base your test on the logs for a new connection, not just whether the page loads. Cached content may make a failed request look successful, while a failed background API request can leave the main page visible but prevent sign-in from completing.

Troubleshoot rule matching separately from connection failures

“Which rule matched?” and “Did the connection succeed after matching?” are two different questions. The messages below are examples of network connection errors, not rule syntax errors. First confirm the matching rule and policy, then investigate these connection errors.

Review everything in this order: active Config, Global Routing mode, request destination, first matching rule, final policy, and actual connection result. For rule keywords, see Rule Keyword Glossary. For resolution behavior, see DNS Settings Guide to avoid confusing DNS issues with rule scope.