How do Shadowrocket rules determine where a connection goes? First, check that Home → Global Routing is set to Config. Then learn the three basics: match conditions, policies, and rule order. This guide is for users with their own provider and subscription who want to adjust a configuration. You’ll learn to distinguish domain rules from IP rules, create narrowly scoped exceptions, and check request logs to see whether a change took effect.
When do rules apply? Check Global Routing first
Will a correctly written rule always be used? Not necessarily. First, check Home → Global Routing. This guide covers Config mode, where connections are matched against the selected configuration’s rules. In Proxy or Direct mode, the step-by-step matching described here may not explain every connection. In Scene mode, check the settings for the selected scene.
| Mode | What it does | What to check before testing |
|---|---|---|
| Config | Routes connections according to the rules in the current configuration. | Check that the file selected in Config is the one you just edited. |
| Proxy | Handles connections using a proxy. | Check that the selected server and connection settings are valid. |
| Direct | Handles connections using a direct connection. | Check whether your current network can reach the destination directly. |
| Scene | Handles connections according to the scene settings. | Check which scene is active and how it is configured. |
Can rules provide missing server details? No. Rules select a connection policy; they do not create a connection service or fix provider settings. This guide assumes you already have a working connection. It does not provide, sell, or recommend nodes, subscriptions, or provider services. Keep a copy of your original configuration before making changes, so you can distinguish connectivity issues from routing issues.
How to read a rule: separate the match condition from the policy
What goes before and after the commas? A standard rule generally follows this structure: rule keyword, match value, policy. The first line below uses DIRECT when the destination domain exactly matches example.com. The second line, FINAL, has no match value and specifies the fallback policy.
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXYAre DIRECT and PROXY domain names? No. Here, they are policies. DIRECT means connect directly; PROXY means use the proxy policy, though the actual outbound connection depends on the currently selected server. If you use a policy group from your own configuration, its name must exactly match a group defined there. Adding an undefined name at the end of a rule will not create one.
Can these rule snippets replace an existing configuration? No. Rule snippets are not complete configurations. [Rule] marks the rules section. When editing an existing file, change entries within its existing rules section and keep the other configuration sections intact. The example.com domain and documentation-only IP addresses in this guide illustrate syntax; they are not working server addresses.
DOMAIN vs. DOMAIN-SUFFIX: understand the matching boundaries
Need a policy for one specific host? Use DOMAIN. To cover a base domain and its subdomains, use DOMAIN-SUFFIX. Suffix matching respects domain label boundaries; it does not match every domain that happens to contain the same characters.
| Rule | Matches | Does not match |
|---|---|---|
DOMAIN,example.com,DIRECT | example.com | api.example.com |
DOMAIN-SUFFIX,example.com,DIRECT | example.com、api.example.com | notexample.com |
DOMAIN-KEYWORD,example,DIRECT | example.com、notexample.com | sample.test |
Why not use DOMAIN-KEYWORD instead? It matches a keyword anywhere in a domain, so its scope is broader than a domain suffix and may catch unrelated destinations with similar names. When you know the full domain, prefer DOMAIN or DOMAIN-SUFFIX. Use a keyword rule only when matching a character sequence is specifically what you need.
What do GEOIP and IP-CIDR match? Distinguish GeoIP data from IP ranges
Can GEOIP,CN,DIRECT identify a region from a website’s language? No. It matches based on the destination IP’s location in GeoIP data, not the page’s text, domain suffix, or your device’s location. GeoIP data may not reflect where a service is actually hosted, so check the destination IP used by the request and the rule match shown in the app.
IP-CIDR,198.51.100.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIs /24 a port number? No. It is an IPv4 prefix length. 198.51.100.0/24 covers addresses from 198.51.100.0 through 198.51.100.255, while 198.51.100.23/32 matches a single IPv4 address. These are documentation-only example ranges. In an actual configuration, enter the destination network range you intend to match.
- For a known, fixed network range: Use
IP-CIDRto specify the address range. Do not put a domain in its second field. - To route by region: Use
GEOIP, keeping in mind that IP location data and changes to destination addresses can affect the result. - For an IPv6 destination: Check the corresponding rule, such as
IP-CIDR6. An IPv4 network rule does not match IPv6 addresses. - Using no-resolve: This option prevents the IP rule from triggering a DNS lookup for the domain. It does not disable all DNS functionality in the app.
Why might a domain request miss after adding no-resolve? If no destination IP is available during matching and the rule does not trigger a lookup, evaluation may continue to later rules. For consistent routing by domain, prefer a domain rule. Do not change all your DNS settings just to make an IP rule match.
What happens when multiple rules match? The first matching rule wins
Do more specific rules automatically take priority? No. For the standard rules covered here, matching proceeds from top to bottom: the first matching rule determines the policy. Put exceptions for individual hosts before broader rules to get the intended result.
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYapi.example.commatches the first rule and usesPROXY. The second rule does not change it toDIRECT.www.example.comdoes not match the first rule, but it matches the second and usesDIRECT.- If the destination is
198.51.100.23and no earlier domain rule matches, it can match the example network-range rule. - If none of the earlier rules match, evaluation continues to
GEOIP. Connections that still do not match are handled byFINAL.
Can FINAL go on the first line? Although its syntax is simple, putting it first makes it a catch-all before the other standard rules can match. It usually belongs at the end of the rules section. It is not a retry setting that tries another rule after a connection fails: once a rule matches, a failed connection does not automatically fall through to the next policy.
How to check whether a change worked: test one destination at a time
Does a page loading after you save prove the rule is correct? No. Both direct and proxy connections may succeed. Check the active configuration, Global Routing mode, request destination, and resulting policy—not just whether the page loads. Test the same known destination again to avoid interference from multiple changes.
-
Keep a copy of the original configuration
Open Config, note which file is selected, and keep a recoverable copy. If the file comes from a remote configuration, check whether an update could overwrite your local changes.
-
Edit the rules section
In Config, open the configuration you want to edit and find
[Rule]. Start by adding one specificDOMAINrule, placing it before broader rules andFINAL. -
Check the mode
Save, make sure this configuration is selected, then go to Home → Global Routing → Config. Confirm that the selected server is still a working connection you already have.
-
Create a new request
Open the test page again and look in the app’s request log for the destination at the same time. If needed, reconnect when doing so will not interrupt important activity, so the test does not reuse an existing long-lived connection.
-
Check which rule matched
Check the destination domain or IP, the matching rule, and the policy actually used in the log. The fields shown may vary by app version. If the result is unexpected, first check for a matching rule above yours, then confirm that the correct file is selected.
Will changing a rule affect every existing connection? Do not assume so. Browser connection reuse, cached pages, and long-lived app connections may keep using an existing connection. Check records for newly created connections. When testing is done, restore any settings you need; do not leave a troubleshooting mode enabled indefinitely.
The correct rule matched, but the connection still fails? Separate matching issues from connection errors
The request log shows the expected policy. Should you keep changing rules? Pause and check the outbound connection first. The English snippets below are common network errors; their full prefixes and where they appear may vary. They indicate a problem during the connection stage and do not, by themselves, prove that a domain rule is wrong.
Error: Connection refused
Cause and what to check: The destination refused the connection. Common causes include an incorrect address or port, or a service that is not listening. First use the request log to determine whether the refused connection was to the proxy server or the destination. Then check the server address, Port in Home, and the settings provided by your service provider. Do not change the server port to 443 just because it is commonly used for websites.
Error: Operation timed out
Cause and what to check: A connection or related operation did not complete within the allotted time. First use Connectivity Test in Home to check the server you already have. Then check your current network, DNS, and the policy used by the request. Adjust a rule only if the log shows that the wrong rule matched.
How can you avoid widening the scope of a problem while troubleshooting? Check in this order: server availability, current mode, destination resolution, and rule matching. Change one variable at a time. Do not change DNS, reorder the entire rules section, and switch servers all at once. Even if access is restored, you will not know which change made the difference.
FAQ: handling rule updates, DNS, and FINAL
Will my manually added rules change when I update a subscription?
First, distinguish the server subscription in Home from the remote configuration in Config. Updating a server subscription mainly updates connection entries; updating a remote configuration may replace configuration contents. Before editing, check the file source in Config. After an update, recheck [Rule] and which configuration is selected. Do not assume both updates work the same way.
Why does the same website use several domains?
A page may make separate requests to the main site, login endpoints, and asset domains. A DOMAIN rule covers only the specified host. Check the request log to find the destination that actually failed, then add only the rules you need. Do not add a broad DOMAIN-KEYWORD rule just because an image is missing.
Does FINAL,PROXY send every request through a proxy?
No. It handles only connections that reach that line without matching an earlier rule. For example, if DOMAIN-SUFFIX,example.com,DIRECT appears above it, matching domains use DIRECT first. To determine where a connection goes, check the rules section from the top down.
IP-CIDR is not matching. Should I delete the domain rules?
First check whether an earlier domain rule matched. Then confirm whether the destination uses IPv4 or IPv6 and whether no-resolve prevents that rule from triggering a lookup. Change the order only if the network-range rule genuinely needs to take priority. Do not delete all domain rules for a single test.