This guide is for users who have already configured a connection in Shadowrocket and want to adjust routing rules. Go to Home → Global Routing and select Config, then review the active [Rule] section: domain rules match names, IP rules check destination addresses, and FINAL handles remaining traffic. Learn to distinguish six rule types, order them, and verify the result with a single request. Proxy connection examples assume you already have a service and subscription.
1. When rules take effect: Config and the first match
The rule type describes the matching condition; the policy at the end of the line describes what happens when it matches. Keep the two separate: DOMAIN,example.com,DIRECT matches the exact domain example.com and routes it directly. It does not add the domain to a fixed proxy list.
This guide covers routing in Home → Global Routing → Config. Proxy and Direct set global proxy and direct routing, respectively, so they cannot be used to test rule order here. Scene is a separate routing mode for choosing routes by scenario and is outside the scope of this test. In Config, make sure the edited file is the one currently selected; saving an unselected file will not change active routing.
In the standard rule examples here, the policy is applied as soon as the first matching rule is found; Shadowrocket does not continue looking for a “more specific” match. An exact match does not automatically outrank a broader one—the order of the rules determines priority.
2. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD
All three rules match domain names, not webpage paths or query parameters. For https://example.com/docs?q=test, the domain is example.com. You cannot use /docs or ?q=test in a DOMAIN rule to filter a page.
| Rule syntax | Matches | Does not match |
|---|---|---|
DOMAIN,example.com,PROXY | example.com | www.example.com |
DOMAIN-SUFFIX,example.com,PROXY | example.com、api.example.com | notexample.com、example.com.test |
DOMAIN-KEYWORD,example,PROXY | example.com、myexample.test | sample.test |
DOMAIN: Match one exact hostname
Use DOMAIN when only api.example.com should go through the proxy and other subdomains should keep their existing policies. Enter only the domain—no scheme, port, or wildcard. The port commonly used for HTTPS, 443, is not part of the domain string, so DOMAIN,example.com:443,PROXY is not the syntax you need here.
DOMAIN-SUFFIX: Match a domain and its subdomains
Use DOMAIN-SUFFIX to cover an entire domain tree. It matches at domain-label boundaries, not by comparing arbitrary character strings at the end: example.com matches static.example.com, but not notexample.com. Usually, enter example.com directly; do not write *.example.com.
DOMAIN-KEYWORD: Match a string anywhere in the domain
DOMAIN-KEYWORD is harder to control than a suffix rule because a match can occur anywhere in the domain name. Use it only when you need to group domains by a name fragment and are willing to accept false matches. If the actual goal is one domain and its subdomains, DOMAIN-SUFFIX is easier to review.
3. GEOIP and IP-CIDR: Match destination IPs
Domain rules check names; GEOIP and IP-CIDR check addresses. GEOIP classifies an IP using a local geolocation database. For example, GEOIP,CN,DIRECT routes destination IPs classified as CN by that database directly. It does not check webpage language or domain registration location, and it cannot guarantee the server’s physical location.
[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIP-CIDR uses a network prefix to describe an IPv4 address range. 192.168.50.0/24 covers 192.168.50.0 through 192.168.50.255; to match just one device, use 192.168.50.10/32. The private-network addresses in this example are not remote service addresses—adjust them for your network.
- Connecting directly to an IP: If the destination is already an address, check whether it falls within the IP-CIDR range.
- Connecting to a domain: Checking an IP-based rule may require resolving the domain first. DNS results, caching, and connection reuse can all affect what you observe.
no-resolve: This means not to actively resolve a domain solely to evaluate this IP rule. It does not disable DNS across the app, nor does it guarantee that the rule will have an address to match.- IPv6: The IP-CIDR examples here cover IPv4 only. If the destination uses IPv6, check the rules for that address family; do not infer the result from an IPv4 range.
A domain can resolve to multiple IP addresses, and those addresses may change with the network. If you want a website to always use a particular policy, start with a domain rule. Use IP-based rules when you specifically need to classify traffic by destination range or IP location.
4. FINAL and rule order: exceptions first, general rules next, fallback last
FINAL does not take a domain or network range; it catches traffic that did not match any preceding rule. FINAL,DIRECT sends remaining requests directly, while FINAL,PROXY sends them through the proxy. Each suits a different goal; neither is universally correct regardless of the configuration’s purpose.
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECTThese rules route only the API domain through the proxy and send other domains on the same site directly. A request to api.example.com matches DOMAIN first. A request to www.example.com misses the first rule but matches DOMAIN-SUFFIX. A request to example.net falls through to FINAL.
| Rule order | Request to api.example.com | Why |
|---|---|---|
| DOMAIN first | PROXY | The exact-match exception takes effect first |
| DOMAIN-SUFFIX first | DIRECT | The broader rule matches the API hostname first |
| FINAL first | DIRECT | The fallback catches the request immediately, before later standard rules can match |
If you add DOMAIN-KEYWORD,example,PROXY, check whether it comes early enough to catch domains that should go direct. When reviewing rules, do not just search for the target domain; scan from the top for any condition that could match first.
5. Edit and test rules in Config
The snippet below demonstrates only the [Rule] section; it is not a complete replacement for your existing config. PROXY uses an existing proxy selection. If the config refers to a custom policy group, confirm that the group exists. A one-time app purchase is not a connection plan; purchasing the app does not provide proxy connection details.
- Keep a copy of the current config: Open Config and save a copy of the current file or export a backup. Note which config is selected.
- Edit the intended file: Open the config you want to change, find its existing
[Rule]section, and place a clear DOMAIN test rule before any rules that could match first. Do not add a duplicate section. - Save and select the file: Make sure the edited file is selected in Config, then go back to Home → Global Routing → Config.
- Prepare the connection: Make sure Home has a usable connection you already have selected. If the target policy is PROXY, you can run Connectivity Test first, but a successful test does not mean every resource on a website is reachable.
- Start a new request: Close the existing webpage and reopen it; if needed, reconnect when it is safe to interrupt the connection. Existing long-lived connections are not suitable for testing a rule change.
- Check the connection log: Find the record for the request and verify its destination domain, destination IP, matched rule, and actual policy. Change one thing at a time, then make a new request to compare.
This guide uses example.com to explain syntax boundaries. The table shows how the rules work, not real-world network speed tests. For actual testing, use a destination domain you are entitled to access and actually use. Do not judge routing solely by how quickly a page loads; latency does not prove which rule matched.
6. Connection failures: distinguish DNS, connectivity, and rules
A webpage error does not necessarily mean the rule syntax is wrong. First check whether the request matched the intended policy, then inspect the resolution and connection path for that policy. The two items below are standard DNS response codes, not fixed Shadowrocket alert text. Follow the relevant steps only if they appear in your actual diagnostic results.
DNS response: NXDOMAIN
Cause: The resolver reports that the queried domain does not exist. The name may be misspelled, or the domain itself may be unavailable.
Fix: Verify the request hostname and DNS records, then check the resolver’s response. Do not change DOMAIN to DOMAIN-SUFFIX as a first step; a broader match cannot create missing DNS records.
DNS response: SERVFAIL
Cause: The resolver could not complete the query, possibly because of an upstream resolution failure or a validation issue. This error alone does not mean the domain does not exist.
Fix: Check the current DNS settings and upstream reachability, then retry the same domain. Once it resolves to an address, verify GEOIP or IP-CIDR matching.
If the domain resolves to an IP but the connection times out, distinguish between the DIRECT and PROXY paths. For DIRECT, check whether the current network can reach the destination. For PROXY, first confirm the proxy connection works, then check its route to the destination. Switching FINAL back and forth can be a controlled comparison, but it is not a substitute for troubleshooting.
- Wrong rule matched: Check Global Routing, the active config, rule order, and the hostname of the actual request.
- Correct rule matched, but connection fails: Check DNS, the destination port, the availability of the existing connection, and the destination service.
- Some page resources fail: Check the domain of each failed resource, not just the main domain in the address bar.
7. Common questions about rule syntax
I added DOMAIN. Why aren’t subdomains using the same proxy?
DOMAIN matches only the exact hostname. To apply the same policy to a domain and all its subdomains, use DOMAIN-SUFFIX,example.com,PROXY, then check for earlier rules that might match first.
The rule says PROXY, but the log shows a direct connection. What should I check first?
First check that Home → Global Routing is set to Config, then verify which file is selected in Config. Next, scan from the top of [Rule] for an earlier DOMAIN-SUFFIX, IP-based rule, or FINAL that matches first.
Does GEOIP,CN,DIRECT guarantee direct routing for every Chinese-language website?
No. GEOIP classifies the destination IP using a database; it does not identify the language of a webpage. If a known domain should go direct, add a specific DOMAIN or DOMAIN-SUFFIX rule before GEOIP, then verify it with a new connection.
How should I use FINAL if only a few websites should go through the proxy?
Set the target domains to PROXY, put any exceptions first, and use FINAL,DIRECT at the end. During testing, check both a target domain and a non-target domain: the first should match its domain rule, while the second should fall through to the direct-routing fallback.
Does Settings → On Demand change which domains a rule matches?
On Demand manages when to establish a connection based on conditions; it does not turn DOMAIN into a suffix match. First confirm that the tunnel is connected, then check rules in Config mode. Do not confuse whether the connection is active with how traffic is routed after it connects.