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

1. Before Rules Take Effect: Check Global Routing and Your Configuration

Rules go in the [Rule] section of a configuration file. Reordering this section matters only when requests are handled through configuration-based routing. First, check the current selection under Home → Global Routing. Don’t assume rules are active just because the connection toggle at the top is on.

Use Config to manage configuration files, and Home to check connection status and Global Routing. Settings → On Demand controls when connections start based on specified conditions; it does not change DOMAIN to another match type or replace rule ordering. When troubleshooting, track whether the connection started separately from which rule a request matched.

2. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD: What They Match

These three rule types match domain names—not webpage content or URL paths. Don’t include https:// or /login in the domain field, and don’t add a port to the hostname. For https://api.example.com:8443/login, the domain matched here is api.example.com.

Use DOMAIN to handle one exact hostname. DOMAIN-SUFFIX covers a domain and its subdomains by domain level: use example.com, not *.example.com. DOMAIN-KEYWORD checks for a keyword anywhere in the domain, so it has a broader reach than a single root domain and may also catch unrelated domains with similar names.

3. GEOIP and IP-CIDR: Match the Destination IP, Not the Domain Text

GEOIP matches based on the destination IP’s location in the geolocation database. For example, GEOIP,CN,DIRECT routes destination addresses classified as CN by the database through DIRECT. It does not check the website’s language, domain suffix, or your location. A database’s location classification also does not indicate where the website operator is based.

IP-CIDR matches IPv4 address ranges. 192.0.2.0/24 represents a network with the first 24 bits fixed, covering 192.0.2.0 through 192.0.2.255. 192.0.2.8/32 covers a single address. These addresses are reserved for documentation examples; don’t use them to test whether a real service is reachable.

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

• no-resolve means not to trigger a DNS lookup solely to match this IP rule. If a usable destination IP is already available, the address can still be matched.
• When a domain request reaches a rule that needs IP information, DNS resolution may affect what happens next. A failed lookup does not mean the rule keyword is misspelled.
• A website may return multiple IP addresses, and those addresses can change. A rule for one temporary DNS result does not cover the entire website.
• IP-CIDR is for IPv4. Don’t put an IPv6 address in this rule type and use an IPv4 mask.

In the example above, the single-address rule comes before the network range. A request to 192.0.2.8 therefore matches REJECT first and never reaches the later DIRECT rule. This is due to the written order, not an automatic priority assigned to /32.

4. Rules Are Checked Top to Bottom; Put FINAL Last

For the standard rules covered here, the key principle is simple: rules are checked from top to bottom. When a rule matches, its policy is applied, and later standard rules are not considered. An exact match does not automatically take precedence over a broader rule above it. To create an exception, move that rule higher.

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

1. For a request to login.example.com, the first rule matches, so DIRECT is used.
2. For a request to img.example.com, the first rule does not match, but the second does, so PROXY is used.
3. For a request to telemetry.example.com, the second rule matches first, so the third rule is never applied. To reject it, move the relevant reject rule above the second rule.
4. Requests that match none of the preceding rules fall through to FINAL,PROXY. FINAL has no domain or address field; its syntax consists only of the keyword and policy.

Putting FINAL near the top prevents later standard rules from being checked. Keep one clear fallback rule and place it at the end. Don’t try to fix ordering by repeatedly adding duplicate rules; first find the rule that is matching too early.

The configuration above illustrates rule order; it is not a universal routing list. Before applying it to an existing configuration, make sure each policy meets your needs and keep a copy of the original.

5. What PROXY, DIRECT, and REJECT Do

The last main field in a rule determines what happens when it matches. The keyword specifies what to match; the policy specifies what to do. They are not interchangeable. This guide assumes you already have your own provider and connection configuration. It does not provide, sell, or recommend nodes, subscriptions, or other connection services.

PROXY is not a protocol. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are protocols used in connection configurations; they cannot replace the basic policy syntax here. A request matching PROXY does not prove the destination is reachable. Check connection settings, DNS, and the remote service separately.

DIRECT does not bypass Shadowrocket’s rule evaluation; it selects a direct outbound connection after a match. If REJECT causes a page or resource to fail to load, that may be expected. If it accidentally blocks a login endpoint, the page loading does not mean the entire site is working correctly.

6. Edit Rules in Config, Then Test with a New Request

Change just one rule or its position at a time, test the result, then continue. Updating a subscription mainly affects your existing server list; it does not necessarily change the [Rule] section of the active configuration. A later remote configuration update may also overwrite local changes, so save a copy before testing.

1. Keep a Copy of the Original Configuration

   In Config, confirm which file is active and save a restorable copy before making changes. Note the original Global Routing selection so you can restore it after testing.

2. Edit the Rules Section

   In Config, open the target file for editing and find [Rule]. Place single-host exceptions before domain suffix rules, keep FINAL at the end, and separate fields with standard English commas.

3. Confirm the Edited File Is Active

   After saving, confirm in Config that the edited file is active. Go to Home → Global Routing, select Config, and check the connection status on Home.

4. Send a New Request

   Close the test page and reopen it. If needed, re-establish the connection to avoid reusing an existing long-lived connection. Check the connection log for available information about the destination domain, destination IP, matched rule, and policy.

5. Check Which Rule Matched

   If the policy differs from what you expected, check broader rules above the matched rule. If the right rule matched but access still fails, check DNS, your existing proxy settings, and the destination service instead of changing rule order blindly.

7. Troubleshooting: Separate Rule Matching from Connection Errors

First distinguish between “the expected rule did not match” and “the rule matched, but the connection failed.” For the first, check Global Routing, the active file, and rule order. For the second, check name resolution and the connection path. Results from Home → Connectivity Test alone cannot confirm that every webpage request to a domain will succeed.

These descriptions explain Apple networking error codes; they are not fixed messages that Shadowrocket displays in every interface. If your logs do not contain these exact strings, troubleshoot using the error actually shown. Don’t assume a spinning page always indicates the same error.