Shadowrocket rules depend on three things: what they match, their order, and the action they take. This guide is for users who already have a provider and configuration and want to adjust routing rules. Start by selecting Config for rule-based routing, then distinguish domain rules from IP rules, and use FINAL for connections that match no earlier rule. Examples illustrate syntax only and include no usable connection credentials.
First, check Config: the prerequisite for rules to take effect
To route traffic according to the rules in a configuration, go to Home → Global Routing, select Config, and make sure the configuration you want to edit is selected on the Config page. Saving a file without selecting it, or leaving Global Routing set to Proxy or Direct, won't verify whether that configuration routes traffic as expected.
- Open Config and confirm which configuration is active. Make a copy before editing to avoid overwriting existing settings.
- Open the configuration's editor and find
[Rule]. Add the examples in this guide to the rules section; don't paste them into the server address field on Home. - Go back to Home → Global Routing, select Config, and confirm that an existing proxy connection works.
- After saving your changes, retry the target request. Check the connection log for the target, matched rule, and resulting action; don't rely on the connection toggle on Home alone.
Proxy sends intercepted connections through a proxy, while Direct connects to the destination directly. With Scene, also check the settings used by the active scene. These steps use Config throughout to avoid mixing scene changes with rule edits. Settings → On Demand controls when a connection starts based on conditions; it doesn't determine which rule matches a domain.
How to read rule syntax: separate match conditions from actions
A typical rule consists of a rule type, a match value, and an action, separated by commas. The rule type says what to check; the action says what to do when it matches. The same domain condition can use different actions, so DOMAIN-SUFFIX does not automatically mean “use a proxy.”
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXYThese examples demonstrate six rule types; they aren't a complete configuration to enable as-is. For example, the first rule sends example.com directly via DIRECT instead of continuing to the later PROXY rule. FINAL takes no domain or network-range argument, so write it as FINAL,PROXY. Don't add an empty field just to make it look like a three-part rule.
| Action | What happens on a match | What to check |
|---|---|---|
PROXY | Handles the connection using a proxy. | Whether the selected proxy and its connection settings work. |
DIRECT | Connects directly to the destination. | Whether the destination is reachable from the current network. |
REJECT | Rejects the matching connection. | Whether the match is too broad or blocks resources the page needs. |
If a rule references a custom policy group, its name must match the definition in the configuration. Also check which option is selected within the group. PROXY is not a protocol: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are protocol choices at the connection-configuration level, not substitutes for rule match conditions.
DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD: where each applies
Use DOMAIN to match one exact domain, DOMAIN-SUFFIX to match a base domain and its subdomains, and DOMAIN-KEYWORD to search for a string in a domain when you really need to. A common mistake is entering a full URL in the domain field or assuming suffix matching only checks the final few characters.
| Rule | Matches | Doesn't match |
|---|---|---|
DOMAIN,example.com,DIRECT | example.com | www.example.com |
DOMAIN-SUFFIX,example.com,PROXY | example.com、img.example.com | notexample.com、example.com.test |
DOMAIN-KEYWORD,example,REJECT | example.com、myexample.com | sample.test |
DOMAIN-SUFFIX respects domain-label boundaries, so use example.com as the match value; there's no need to add *.. DOMAIN-KEYWORD doesn't require a label boundary, so example can also match domains belonging to unrelated sites. Be especially careful to narrow the scope when using it with REJECT.
- Don't include
https://, a page path, or query parameters in the domain field. - For
https://example.com/docsandhttps://example.com/account, all three domain rule types see the same domain. They can't route these two paths separately. - Standard domain rules don't change their matching scope based on whether the destination port is 80 or 443. A port isn't a third field in DOMAIN-SUFFIX.
- If a request provides only a destination IP and no usable domain information, a domain rule can't infer the website name.
GEOIP and IP-CIDR: match destination IPs, not website names
GEOIP checks a destination address against IP geolocation data; IP-CIDR matches an explicitly specified address range. Neither checks webpage text, site registration details, or domain suffixes. A Chinese-language website won't necessarily resolve to an address GEOIP identifies as CN, and the same domain may resolve to different addresses on different networks.
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR,198.51.100.8/32,REJECT
FINAL,PROXYHere, 192.0.2.0/24 and 198.51.100.8/32 are documentation examples, not usable server addresses. /24 means the first 24 bits are the network prefix; this example covers 192.0.2.0 through 192.0.2.255. An IPv4 /32 covers a single address. Use the corresponding IP-CIDR6 type for IPv6 ranges; don't reuse IPv4 examples.
Adding no-resolve to an IP rule prevents that rule from actively resolving a domain; it doesn't turn off all DNS. For a connection that has a domain but no usable destination IP, the rule may be skipped and matching may continue with the next rule. Leave this option out of your initial minimal test to avoid confusing the match conditions.
FINAL and rule order: first match wins; the most specific rule doesn't automatically take priority
For the standard rules covered here, evaluate them from top to bottom and apply the action for the first match. DOMAIN won't automatically jump ahead of an earlier rule just because it's more specific than DOMAIN-SUFFIX. FINAL is the fallback for connections that match none of the preceding conditions, so put it at the end of the rule list.
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTThis minimal example connects account.example.com directly, routes example.com and its other subdomains through PROXY, and sends all other unmatched destinations through DIRECT. If you swap the first two rules, account.example.com matches the suffix rule first, so the DOMAIN exception below it no longer determines how that connection is routed.
FINAL isn't a failover action that switches to a direct connection after a proxy fails. Once a connection matches PROXY above, a subsequent timeout doesn't send it back through the rule list to FINAL. To change the default action for unmatched traffic, change the action on FINAL. If a proxy is unavailable, check its connection settings or the selection in an existing policy group.
- Put an exception for a specific domain before the suffix rule that would otherwise match it.
- Check broad DOMAIN-KEYWORD and GEOIP rules for unintended matches that could override later, more specific needs.
- A REJECT rule can block connections wherever it matches. Don't use a broad keyword as if it were a precise block.
- Don't add ordinary rules after FINAL if you expect them to take effect. Find the fallback rule before adding anything.
How to verify changes: change one condition at a time
When testing, first ask whether a rule matched, then whether the resulting connection succeeded. A browser error doesn't prove the rule syntax is wrong, and a page that loads doesn't prove all its resources used the same action. A page may request its main content, images, and APIs from different domains, so check each separately.
- Save the minimal example in Config, make sure it's selected, then check Home → Global Routing and confirm Config is active.
- First, use your existing configuration to confirm that the proxy connects. If the basic connection fails, check the address, port, authentication, and protocol settings.
- End existing requests, then revisit the test destination so you're not judging the new rules using a reused connection.
- Check the app's connection log for the actual destination, matched rule, and action. Use a test domain you genuinely need to access; the domains in this guide are examples for explaining syntax only.
- If the main page loads but images don't, identify the domain used by the image requests. Then decide whether to add DOMAIN or DOMAIN-SUFFIX; don't start by broadening the match to an ambiguous keyword.
- Record the results before and after each change, editing one rule at a time. Once you've confirmed the behavior, gradually merge the changes back into the full configuration.
The following are connection-level errors, not syntax messages specific to any one rule. The exact wording may depend on the system or protocol context. Check the actual outbound action in the log first, then troubleshoot that connection; don't delete FINAL just because an error appears.
Error: Connection refused
Cause and fix: The destination port refused the connection, possibly because the service isn't listening or the port is incorrect. First check whether the log shows DIRECT or PROXY. With DIRECT, check the destination service's port; with PROXY, check the address and port of your existing proxy and whether its service is running.
Error: Connection timed out
Cause and fix: The connection didn't complete before the timeout. This may involve network reachability or the outbound connection. First test other destinations with the same configuration, then check the rule and action matched for this request. Don't change a domain rule to an IP rule based on a timeout alone.
FAQ: Why correct rules may not produce the expected result
I added DOMAIN-SUFFIX. Why is the connection still direct?
Go to Home → Global Routing and confirm Config is selected, then open Config and make sure you're editing the active configuration. Check whether a DOMAIN, DOMAIN-KEYWORD, or other matching rule appears before the suffix rule, then retry the connection and inspect its log.
How should I set FINAL to proxy only specific websites?
Add the domains you want to proxy as DOMAIN-SUFFIX,example.com,PROXY and use FINAL,DIRECT at the end. Replace the example domain with your actual destination and add any other domains the page depends on. This doesn't automatically create rules for every resource a page uses.
Can I put GEOIP,CN,DIRECT at the top?
The syntax allows it, but an early GEOIP match may override a destination you want to force through a proxy. If a domain must use PROXY, put its specific rule first, then GEOIP, and FINAL last. Check the result in the actual connection log.
Will updating an existing subscription on Home also change routing rules?
Distinguish a server subscription from a configuration file in Config. Updating a server subscription mainly refreshes connection entries; it doesn't mean the rules in the active configuration have also changed. After an update, check the selected connection on Home and the rule content in Config separately, and keep a copy of your own edits.
The page went blank after a REJECT rule. Is the proxy broken?
First check whether the failed resource matched REJECT. If a required API or script was blocked, add an exception for its domain before the broad blocking rule or narrow the match. REJECT explicitly blocks a connection, so a failed request doesn't show whether the proxy works.
What rules can and can't do: they choose an outbound route, not provide a service
Rules can choose DIRECT, PROXY, or REJECT for a connection, but they can't create a working proxy service or fix inconsistent protocol settings. A PROXY match still depends on an existing connection configuration; a DIRECT match still depends on the current network and the destination service. Verify rule matching and connection success separately.
- Matching: Check whether the domain or IP meets the condition and whether the rules are in the right order.
- Action: Check the action and policy group referenced by the rule, including the current selection.
- Connection: Check the address, port, authentication, and protocol settings required for the actual outbound connection.
- Maintenance: After updating a subscription or remote configuration, check what is selected again. Don't assume earlier test results still apply to a changed configuration.
Shadowrocket is primarily for iPhone and iPad. It's available through the App Store; see the App Store listing for system requirements. A one-time app purchase doesn't include a connection plan; this guide assumes you already have your own provider and configuration. For an overview of rule structure, see the Rules Manual. For your first setup, follow the tutorial step by step.