This guide is for users who have imported their own configuration into Shadowrocket and want to adjust their routing rules. First, make sure Global Routing is set to Config. Then distinguish domain-based conditions from IP-based ones, and order rules from specific exceptions to broader matches, with FINAL at the end. The examples explain syntax and contain no usable connection details; replace the test targets with ones you are authorized to access.
Check when rules take effect
Rules determine the policy used for a connection; they do not create servers or determine whether a server is available. Home is for selecting a server and managing connections, Config is for managing configuration files, and Settings is for app preferences. After editing a file, make sure it is the currently selected configuration. Saving a file that is not enabled will not change the rules in use.
In Home → Global Routing, select Config to apply the routing rules in the current configuration as described here. Proxy routes all traffic through the proxy, while Direct connects directly. For Scene, check the configured scene conditions; seeing Scene in the menu alone does not mean a particular ruleset is active. When troubleshooting, select Config first to eliminate variables caused by scene changes.
Takeaway: confirm the active configuration first
Before testing, note the current configuration name and Global Routing selection. If either is unclear, do not add rules yet; otherwise, you will not know whether a change came from switching files or from the match condition.
Rule syntax and policy names
In the [Rule] section of a configuration, a standard conditional rule usually has three fields separated by English commas: rule type, match value, and policy. Do not enter a full web address in a domain field: domain conditions do not include https://, paths, query parameters, or ports. The two lines below mean “connect directly to the specified domain” and “use a proxy for all other connections.”
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXY| Field or policy | Meaning | What to check |
|---|---|---|
DOMAIN | Rule type; matches a full domain name. | Not a protocol type or server name. |
example.com | The match value used by this rule. | Do not enter a URL with a path. |
DIRECT | Connect directly to the destination. | The connection still depends on the current network, DNS, and destination reachability. |
PROXY | Use the proxy policy. | Check which default server is selected in Home. |
REJECT | Reject matching connections. | If access fails after a match, that may be the rule's intended result. |
If your configuration uses a custom policy group name, the rule must refer to a name that actually exists in the configuration. For initial tests, use DIRECT and PROXY. Do not add a policy group, change DNS, and reorder rules all at once. The examples below are snippets. If your configuration already has a [Rule] section, edit that section instead of repeatedly adding another one with the same name.
How the three domain conditions differ
Use DOMAIN for an exception on a single host, DOMAIN-SUFFIX for a domain and its subdomains, and DOMAIN-KEYWORD to match a specified string anywhere in a domain name. These conditions match domain information, not page titles, page content, or URL paths.
| Example 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、example.com.test |
DOMAIN-KEYWORD,example,DIRECT | api.example.com、notexample.com | Domains other than example.org that do not contain this string, such as sample.test |
For DOMAIN-SUFFIX, enter example.com as is; there is no need to add *.. It matches suffixes at domain boundaries rather than performing a simple string-ending comparison. By contrast, DOMAIN-KEYWORD,example,DIRECT has a much broader scope and may match unrelated domains. If you only want to match one family of sites, prefer a specific suffix condition.
- These three conditions cannot distinguish the
/newsand/accountpaths on the same domain. - For a request to
example.com:443, enterexample.comin the domain field; do not append:443. - When connecting directly to an IP address, do not assume a domain rule will match. Check whether the request has domain information available for matching.
What GEOIP and IP-CIDR match
GEOIP checks the geographic classification of the destination IP in a geolocation database. For example, GEOIP,CN,DIRECT sends destination IPs classified as CN by the database to DIRECT. It does not check domain suffixes, page language, or a company's place of registration, and it cannot guarantee that all IP addresses returned for a domain belong to the same region.
IP-CIDR specifies an IPv4 address range directly. The number after the slash is the prefix length: /32 represents a single IPv4 address, while /24 covers 256 addresses. The examples below use address ranges reserved for documentation; they are not usable service addresses.
IP-CIDR,192.0.2.7/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY192.0.2.7/32covers only192.0.2.7, not192.0.2.8.- The address range for
198.51.100.0/24is198.51.100.0through198.51.100.255. - Use the corresponding
IP-CIDR6type for IPv6 ranges. Do not use an IPv6 address as though it were an IPv4IP-CIDRexample. - Whether a domain request must be resolved before an IP condition can be checked depends on the configuration's resolution behavior. A resolution failure and a rule not matching are two different issues.
Some IP conditions support no-resolve, for example IP-CIDR,192.0.2.0/24,DIRECT,no-resolve. This prevents DNS resolution from being triggered solely to evaluate that rule; it does not disable DNS globally. If no destination IP is available at the time, the rule cannot match by resolving the domain. When troubleshooting, keep the relevant options in the existing configuration unchanged; do not add or remove them in bulk.
Match rules in order; put FINAL last
For the standard rules covered here, checks run from top to bottom. The policy on the first matching line is used; a later, “more specific” condition does not override it. Rule type names do not establish priority: DOMAIN does not automatically take precedence over a DOMAIN-SUFFIX rule above it.
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- For a request to
api.example.com, the first line matches, so PROXY is used. - For a request to
www.example.com, the first line does not match, but the second does, so DIRECT is used. - If the destination IP is
192.0.2.8and no earlier domain rule matches, the example subnet rule can match. - Other connections continue to GEOIP; if that still does not match,
FINAL,PROXYhandles them.
If you swap the first two lines, api.example.com will match the suffix rule first, disabling the single-domain exception you wanted to preserve. Likewise, FINAL is an unconditional fallback and belongs at the end of the ruleset; ordinary rules after it cannot change a result that has already been decided. Do not try to fix an ordering mistake by adding a second FINAL rule.
Takeaway: put exceptions before broader rules
To apply a different policy to a subdomain, place its DOMAIN condition before the relevant DOMAIN-SUFFIX rule. After saving, test that subdomain and another ordinary subdomain separately to confirm they take different routes.
Edit and verify in five steps
The steps below assume you already have your own server or subscription and can establish a basic connection. Configuration files and the server list in Home serve different purposes: updating server information does not mean the rules file being edited has been selected. Likewise, changing routing rules cannot fix invalid connection credentials.
-
Back up the configuration
Open Config, make a copy of the current configuration, and note the name of the file in use. For a remote configuration, check whether a future update will overwrite local changes.
-
Confirm the routing mode
In Home → Global Routing, select Config and make sure the intended test file is selected in Config. Also check which default server is selected in Home.
-
Change one thing at a time
In Config, open the editing option for the target configuration, enter text editing, and locate
[Rule]. Add just one DOMAIN rule for a known target, or change a single rule's position, then save. -
Reconnect
After saving, reconnect the VPN and have the test app make a new request. Existing long-lived connections may continue using the previous route, so repeatedly refreshing the same page may not create a new connection.
-
Compare the results
Check the visible destination, policy, and error details in the connection log against the expected result. Connectivity Test can help verify basic connectivity, but it cannot by itself prove which rule matched a website.
If a rule matches but access fails
A rule match only means a route was selected; it does not guarantee that the route can reach the destination. First check whether the intended policy was selected, then whether that route is available. The system error messages below may appear during connection diagnostics; they are not fixed errors from the rule parser. Where they appear and their full wording may vary by connection type.
Error: Connection refused
Cause: The destination or an intermediate device actively refused the connection. The service may not be listening, or the port may be incorrect. This does not prove that the DOMAIN syntax is wrong.
Fix: First check the actual connection destination in the log. If the route uses PROXY, verify the address and port of your existing server. If it uses DIRECT, check whether the destination service allows access on that port.
Error: Operation timed out
Cause: The connection did not complete before the timeout. This can happen if the server is unreachable, the destination does not respond, or the network drops packets. A timeout alone cannot identify which rule caused the problem.
Fix: First check the final policy, then test basic connectivity on the same network. Keep the configuration unchanged and check one item at a time; avoid changing DNS, the server, and rule order simultaneously.
No error, but the policy is not what you expected
- All requests use the same route: Go to Home → Global Routing and make sure it is not set to Proxy or Direct. Also check which configuration is active.
- Single-domain exception does not work: Check whether a broader DOMAIN-SUFFIX, DOMAIN-KEYWORD, or FINAL rule appears earlier and matches first.
- IP rule does not match: Check whether the actual destination is IPv6, whether the resolved address has changed, and whether the rule uses
no-resolve. - One page uses multiple policies: A page may connect to several domains, such as the main site, images, and APIs. Check each request individually instead of treating the entire page as a single connection.
- Nothing changed after saving: Check that the edited file is selected, then establish a new test connection. Do not treat results from an existing connection as verification of the new rules.
After testing, remove the temporary rules or narrow them to the scope you actually need, then save a backup. A useful minimal test record includes the domain, actual destination IP, expected policy, actual policy, and exact error message. This information helps distinguish among matching boundaries, rule order, and network connectivity issues.