Shadowrocket Rule Syntax Guide: What DOMAIN-SUFFIX, GEOIP, FINAL, and Other Keywords Match

1. Rules combine a match condition with a policy

Rules determine which outbound policy a connection uses; they do not create a working proxy connection. A common format is “rule keyword,match value,policy,” with fields separated by English commas. FINAL has no match value, so it uses only two fields: the keyword and the policy. These entries usually appear in the [Rule] section of a configuration file.

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

Here, DIRECT means connect directly, PROXY sends traffic through a proxy policy, and REJECT blocks the connection. A rule can also end with the name of a policy group that exists in the current configuration. Do not copy group names from another configuration, as the policy reference may be invalid. example.com in these examples is for demonstrating syntax only; it is not a service endpoint.

To apply these rules to standard routing, go to Home → Global Routing and select Config, then confirm the active configuration in Config. Proxy and Direct are different overall routing modes; neither can verify expectations for domain-based routing under the same rules. Check Scene separately against its conditions. Editing a file does not mean the current connection is using it.

2. DOMAIN rules match domains, not URL paths

Start by breaking down the URL: in https://api.example.com:443/account, the hostname is api.example.com, the port is 443, and the path is /account. For the three rule types below, enter a domain or part of a domain as the match value. Do not include https://, the port, or the path. These rules do not determine routing based on a page title or its contents.

DOMAIN: Add an exception for a single host

DOMAIN,api.example.com,PROXY will not match www.example.com or v2.api.example.com. An exact-domain match gives you tighter control when only a login endpoint, a particular API, or one standalone host needs a different policy. Use actual connection logs to identify the domain; the address bar alone may not reveal every host a page uses.

DOMAIN-SUFFIX: Match a domain and its subdomains

DOMAIN-SUFFIX,example.com,PROXY can match example.com, www.example.com, and a.b.example.com, but should not match notexample.com or example.com.other.test. It matches a suffix at a domain boundary, not any string that happens to end with the same characters. Usually, enter example.com without adding *.example.com.

DOMAIN-KEYWORD: Broader matching requires checking for false positives

DOMAIN-KEYWORD,example,PROXY may match both example.com and myexample.test. Use this rule when matching by substring is intentional. If you only need to cover a specific domain family, prefer DOMAIN-SUFFIX. Short keywords can affect more domains and make later troubleshooting harder.

3. GEOIP and IP-CIDR match destination IPs

Domain rules match names; IP rules match a connection’s destination address. The IP a domain resolves to can vary with DNS results, network conditions, and content delivery infrastructure. A domain’s association with an organization and a destination IP’s geographic classification in a database are different conditions and cannot replace one another.

GEOIP,CN,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT
IP-CIDR,203.0.113.7/32,PROXY

• GEOIP: CN is a region code. Matching is based on the IP’s classification in a geographic database, not page content, the user’s location, or domain registration details.
• IP-CIDR: 192.168.50.0/24 covers addresses from 192.168.50.0 to 192.168.50.255. Which devices are reachable still depends on the local network.
• Single IPv4 address: /32 covers one address. 203.0.113.7 is reserved for documentation examples; do not use it to test whether a proxy service works.
• IPv6: Check the corresponding IPv6 rule, such as IP-CIDR6. An IPv4 subnet does not cover every address family.

When a request starts with a domain name, evaluating IP rules may involve resolving that domain. Some IP rules support the no-resolve option, which prevents an additional DNS lookup for that rule. It does not disable DNS or guarantee that every domain request will match the IP rule. For a basic configuration, leave this option out until you understand the DNS and matching behavior.

4. The first matching rule wins; FINAL is the fallback

Rules are generally checked from top to bottom. The first rule whose condition matches determines the policy; evaluation does not continue to find a “more specific” rule. DOMAIN is not inherently prioritized over DOMAIN-SUFFIX. If a broad rule comes first, a more precise exception below it never gets a chance to apply.

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

FINAL,DIRECT sends all other connections out directly; FINAL,PROXY sends them through the proxy policy. Neither format is inherently better; they set different defaults. If you want only listed sites to use a proxy, the first is usually a better fit. If FINAL is the first rule, the rules below it never get a chance to match.

5. Edit and verify rules in Config

These steps assume you already have a working provider configuration. Rules select a policy; whether a proxy connection succeeds also depends on the service parameters and network conditions. Keep a copy of the original configuration before editing. If the configuration can be overwritten by a remote update, first check where local changes are saved and how later updates affect them.

1. Confirm the active configuration

   Open Config and check which configuration file is selected. Use that file’s edit option to view the [Rule] section. Do not edit a copy that is not currently active.

2. Add a precise rule

   Start with a rule such as DOMAIN,api.example.com,PROXY, then expand it to DOMAIN-SUFFIX if needed. Keep the English commas and confirm that the policy name is available.

3. Select Config

   Go to Home → Global Routing → Config and make sure the connection is enabled. Do not switch to Proxy or Direct during testing, or the conditions will change.

4. Start a new connection

   After saving, reconnect and reopen the test page or restart the test app to generate new requests. Existing long-lived connections may not switch routes immediately after a rule edit.

5. Check connection logs

   In the connection logs, check the destination domain, destination IP, and selected policy. If the current log also shows the matching rule, check that too. Compare each result with the expected first matching rule.

Change one condition at a time during testing. First confirm that an exact-domain rule matches, then try a suffix rule or add an IP range. A page loading is only one possible result; it does not prove that the expected policy was used. Cached content, local connections, and other domains used by the page can all affect the result.

6. Distinguish a rule mismatch from a connection failure

Troubleshoot in two steps: first identify which policy the connection selected, then check whether that policy’s outbound connection succeeded. The messages below are common in DNS or network diagnostics, but may not appear with the same wording in every view. Follow the corresponding checks only if the actual log contains the relevant information.

If there is no error but the log shows an unexpected policy, check these four things first: whether the actual hostname differs, whether a broad rule appears earlier, whether the correct configuration is selected, and whether Global Routing is set to Config. Do not add many broad rules at once just to eliminate a timeout; you will lose a clear basis for comparison.

7. Common questions about rules