How to Write Shadowrocket Rules: DOMAIN, DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL Explained

1. Rule format: match type, match value, policy

Rules are commonly added to the [Rule] section of a Config file. Except for special forms such as FINAL, a rule usually has three fields: a keyword, a match value, and a policy, separated by commas. For domain rules, enter the hostname only—not a protocol prefix, URL path, or port.

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

Here, DIRECT means connect directly, PROXY sends the request through a proxy policy, and REJECT blocks matching requests. Rules determine how requests are handled; they do not create servers or supply authentication details. Before using PROXY, check that your own server is configured and available in Home. If you use a custom policy group, the name at the end of each rule must match its definition in the Config file.

2. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD: what each matches

All three rule types match domains, but their scopes differ. DOMAIN matches an exact hostname; DOMAIN-SUFFIX matches the specified domain and its subdomains; and DOMAIN-KEYWORD checks whether the domain contains a specified string. These are not URL filters: they cannot distinguish pages on the same host by paths such as /video/.

For example, to send only the login endpoint directly while proxying other requests on the same domain, put DOMAIN,account.example.com,DIRECT before DOMAIN-SUFFIX,example.com,PROXY. This works because of rule order—not because an exact hostname automatically has higher priority.

• Do not write DOMAIN,https://example.com,PROXY. The match value should be example.com.
• Do not use *.example.com instead of a suffix rule. To match the entire domain, use DOMAIN-SUFFIX,example.com,PROXY.
• A webpage may connect to the main site, image hosts, and API hosts. Matching the main site does not mean all its resources will use the same policy.

3. GEOIP and IP-CIDR: match destination IP locations and address ranges

GEOIP matches based on the destination IP's location in a geolocation database. For example, GEOIP,CN,DIRECT sends destination addresses that the database associates with CN to DIRECT. It does not check the webpage language, domain suffix, or server operator's location. Database records also do not necessarily reflect the current physical location.

IP-CIDR matches IPv4 address ranges. 192.168.1.0/24 covers 192.168.1.0 through 192.168.1.255, illustrating the rule's scope; which addresses can be assigned to devices on a local network also depends on its configuration. Use IP-CIDR6 for IPv6 ranges; do not put an IPv6 address in an IPv4 example.

[Rule]
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• /32 represents one IPv4 address, while /24 represents 256 addresses. The longer the prefix, the smaller the range.
• no-resolve is an optional parameter. When matching this IP rule, it prevents a domain lookup from being triggered; it does not disable DNS for the entire app.
• If a request has a domain but no available destination IP, an IP rule with no-resolve may not match. Requests with a destination IP can still be evaluated.
• For a local network DIRECT rule, use your actual subnet. Do not assume every home network is the same just because the example uses 192.168.1.0/24.

When combining domain and IP rules, put specific domain exceptions first, followed by broader IP location rules. This helps prevent a destination from matching an earlier policy based on its resolved IP. DNS may return different addresses for the same domain, so the GEOIP result can change with the destination address.

4. Rules run top to bottom and stop at the first match: why FINAL goes last

In a standard linear rule list, requests are checked in order. Once a rule matches, its policy is applied; evaluation does not continue looking for a “more specific” rule. FINAL has no domain or address condition. It catches requests that did not match earlier rules, so it must go at the end of the list.

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

1. Request to account.example.com: the first rule matches and uses DIRECT. The suffix rule below it is not evaluated.
2. Request to images.example.com: the first rule does not match, so the second rule matches and uses PROXY.
3. Request to destination 192.168.1.20: it matches the local network range and uses DIRECT.
4. Other requests: GEOIP is checked first. If no rule matches, the request uses the DIRECT policy specified by FINAL.

If you put the suffix rule before the exact-host exception, account.example.com will use PROXY first. If you put FINAL,DIRECT at the top, no later rule gets a chance to handle ordinary requests. To proxy only specified sites, list them with domain rules and end with FINAL,DIRECT. To send all other requests through a proxy, use FINAL,PROXY instead; these choices affect different sets of requests.

5. Edit rules in Config and apply them to new connections

Adding rules to a file does not mean that file is active. Check both the selected Config file and Global Routing in Home. To route by Config rules, select Config. Proxy and Direct do not test individual rules in the list described here, while Scene involves scene selection and is not suitable for isolating a basic rule test.

1. Keep a copy of the original Config

   Open Config and save a copy of the current file or its original text first. Make sure you are editing the file currently in use, not another Config with the same name.

2. Edit the rule section

   In Config, select the target file, open Edit Plain Text, and find [Rule]. Put specific exceptions first and keep any required FINAL fallback at the end. Leave the file's other required sections intact.

3. Save and select the file

   Save your changes, return to Config, and confirm that the file you edited is selected. A later remote Config update may overwrite local changes, so keep a copy of the rules you added before testing.

4. Check the routing mode

   Return to Home → Global Routing → Config, then check your own proxy server. A subscription update refreshes existing service details; it does not write or enable local rules for you.

5. Test a new connection

   After saving, establish a new connection and make the target request again. Check the connection log for the destination hostname, destination IP, and policy used. Do not judge whether a rule matched solely by whether the page opened.

Change one condition at a time when testing. For example, first route one exact hostname through DIRECT; after confirming the result, expand the rule to DOMAIN-SUFFIX. Browser cache, existing long-lived connections, and other domains used by the site can affect what you observe. The new request must actually create a network connection; a cached page does not prove that the new rule was used.

6. Troubleshoot rule behavior separately from network errors

“The webpage won't open” does not necessarily mean the rule syntax is wrong. First check which policy the request actually selected, then investigate DNS and the connection. The messages below are English error descriptions that may come from Apple's networking stack. The app or system may display localized text, so you may not see the exact same wording in Shadowrocket every time.