This guide is for users who have configured a connection in Shadowrocket and want to adjust how traffic is routed. First, make sure Global Routing is set to Config. Then learn how first-match rule order works, and combine domain exceptions, IP ranges, and FINAL in a rule list you can verify. Examples use documentation-only addresses; no connection service is provided. Get subscription links from your service provider.
1. Custom Rule Priority: The First Matching Rule Wins
When routing traffic by configuration, Shadowrocket checks the rules in [Rule] from top to bottom. When a rule matches, the request uses that rule’s policy; Shadowrocket does not continue looking for a “more specific” rule or one farther down the list. Rule priority is therefore determined mainly by position—not by domain length or automatic sorting by rule type.
For example, DOMAIN-SUFFIX,example.com,PROXY can match example.com and its subdomains. To bypass the proxy for files.example.com, place DOMAIN,files.example.com,DIRECT before the suffix rule. If you put it after, the suffix rule has already matched that subdomain, so the exception never gets a chance to decide how the request is handled.
- Put narrow exceptions first: Place individual domains, specific destination IPs, and targets that must be blocked before broader rules that would also match them.
- Put broad categories later: Use domain suffixes, IP ranges, and geographic classifications to handle remaining requests. Their relative order still depends on their position in the list.
- Put FINAL last: It catches requests not matched by any preceding rule. Do not place ordinary rules that you expect to take effect after it.
2. Global Routing and the Difference Between PROXY, DIRECT, and REJECT
First, check the current routing mode in Home → Global Routing. Config is the mode to use when verifying the rules in the current configuration. Proxy and Direct are global routing choices and cannot tell you whether a particular custom rule matched. If you use Scene, also check the settings the scene actually applies; the rules shown in the configuration editor alone do not determine the current result.
| Policy | What happens when it matches | What to check |
|---|---|---|
PROXY | Send the request through a proxy. | Check which proxy is selected. If the configuration uses a policy group, also check which outbound is selected within that group. |
DIRECT | Connect directly to the destination over the current network. | A direct connection still depends on the local network, destination reachability, and DNS results; it does not guarantee success. |
REJECT | Reject the matching request. | Related features may fail to load. Check the matching scope before broadening the block. |
Check in this order: routing mode first, then rules
If a rule change has no effect, return to Home and make sure Global Routing is set to Config. Then open Config and confirm that the selected file is the one you edited. Do not start by repeatedly changing proxies to diagnose rule order.
PROXY is a policy identifier in a rule; Proxy is an option in the Global Routing interface. They operate at different levels. Rules determine which requests use a particular outbound connection, while protocols such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard determine how that connection is established. Reordering rules will not fix an incorrect port, key, or authentication setting in a protocol configuration.
3. Using DOMAIN-SUFFIX, GEOIP, IP-CIDR, and FINAL
A typical rule contains a rule type, a match value, and a policy. FINAL needs no match value, so it contains only a rule keyword and a policy. The table below explains the syntax; example.com and 192.0.2.0/24 are documentation examples, not real service addresses.
| Rule example | What it matches | Ordering note |
|---|---|---|
DOMAIN,files.example.com,DIRECT | Matches this exact domain. | Place it before any DOMAIN-SUFFIX rule that would also match it. |
DOMAIN-SUFFIX,example.com,PROXY | Matches the domain and its subdomains, not any string that happens to contain it. | Can handle the remaining subdomains after individual domain exceptions. |
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve | Matches the example IPv4 range. The no-resolve option avoids initiating a domain lookup just to evaluate this IP rule. | It does not disable DNS for the entire configuration or change matching conditions for destination IPs already known. |
GEOIP,CN,DIRECT | Matches according to the geographic classification of the destination IP in the GeoIP database. | It does not classify by domain suffix; the result depends on the destination IP and database. |
FINAL,PROXY | Send requests not matched earlier to PROXY. | Place it at the end of the rule list. |
Whether a domain rule can match also depends on whether the connection has usable destination-domain information. If you connect directly to an IP address, do not expect it to automatically match a DOMAIN-SUFFIX rule. A webpage may also request content from its main domain, image hosts, authentication endpoints, and content delivery domains. A direct match for the main domain does not mean every connection made by the page will use the same policy.
4. Rule Order Example: Subdomain Exceptions and a FINAL Fallback
Suppose you want files.example.com to connect directly, ads.example.com to be rejected, and all other example.com domains to use a proxy. The two configuration cards below contain the same rules in different orders. They show why writing an exception does not guarantee that it will take effect.
Before: Broad rule first
- Rule 1
DOMAIN-SUFFIX,example.com,PROXY- Rule 2
DOMAIN,files.example.com,DIRECT- Rule 3
DOMAIN,ads.example.com,REJECT- Rule 4
FINAL,PROXY
Both specific subdomains match rule 1 first, so the exceptions do not work as intended.
After: Put explicit exceptions first
- Rule 1
DOMAIN,files.example.com,DIRECT- Rule 2
DOMAIN,ads.example.com,REJECT- Rule 3
DOMAIN-SUFFIX,example.com,PROXY- Rule 4
FINAL,PROXY
Handle individual domain exceptions first, then the entire domain range, and finally any remaining requests.
If you also need to route traffic by IP range and region, you can organize the rules as shown below. GEOIP,CN,DIRECT is only an example of where to place a geographic rule; it is not a recommendation for all users. Choose a policy that fits your network and access needs.
[Rule]
DOMAIN,files.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIn this example, domain rules handle domains within the example.com scope first. They will not be routed through DIRECT just because GEOIP classifies their resolved IP as CN. The later IP rules can only apply to other requests that did not match those domain rules. This is why a rule’s position matters more than how “specific” it may seem.
Ordering principle: Add exceptions before category rules
Move specific targets that must connect directly or be rejected ahead of rules that would otherwise match them. Move one related group at a time and keep FINAL at the end. This makes each change in behavior easier to explain.
5. From Editing in Config to Testing a New Connection
When verifying rules, distinguish between three steps: finishing the edit, selecting the updated configuration, and having a new request use the updated settings. Browsers and apps may reuse existing connections, so simply refreshing a page may not establish a new outbound connection. Also distinguish a correct rule decision followed by a connection failure from a request that never matched the intended rule.
- Keep a copy of the original configuration. Before editing in Config, save a recoverable copy and note which file is currently selected. Do not replace unrelated parts of an existing configuration with the full example.
- Check [Rule]. Find the rules you want to change and look for an earlier rule for the same domain, a parent suffix, an IP range, or a FINAL that appears too soon. Keep one clearly defined fallback at the end.
- Save and select the file. After editing, confirm the changes are saved. Then check in Config that this is the file actually selected, not another file with a similar name.
- Check the routing mode. Go back to
Home → Global Routing → Config. Keep the current proxy selection unchanged during the test to avoid confusing outbound changes with rule changes. - Establish a new connection. When it will not interrupt important work, disconnect and reconnect, then make the target request again. If needed, quit and reopen the target app to reduce the chance of reusing an existing connection.
- Inspect the new request record. In the connection records or logs, check the destination domain, destination IP, and policy used. If the record shows which rule matched, check that too. Do not judge whether a rule worked solely by whether the webpage opens.
The example domains in this guide do not provide real test services. For verification, use an address you are authorized to access and where you can confirm the request destination. Record the test conditions. For example, if text appears but images keep loading, check the actual domain requested for the images instead of immediately changing the policy for the entire main site.
6. FINAL and Custom Rule FAQs
Why do the rules below FINAL have no effect when FINAL is on the first line?
FINAL catches every unmatched request that reaches it. Move it to the end of [Rule], then check the specific rules above it. Do not add domain exceptions you expect to work after FINAL, and do not try to override the first FINAL by adding a second one.
Why can’t I open a website even though I added a DIRECT rule?
First, check whether the new request record shows DIRECT as the policy used. If so, the rule has made the direct-routing decision. Next, check whether the current network can reach the destination, whether DNS returns a usable address, and whether the destination service responds. DIRECT specifies the route; it does not fix network or server problems.
Will changing the rule to FINAL,DIRECT affect all existing rules?
It will not change rules that already matched, but it will change the default outbound policy for every remaining request. Before changing it, check which requests rely on the current fallback. If you only want one domain to connect directly, add a DOMAIN or DOMAIN-SUFFIX exception earlier in the list instead of widening the fallback’s impact.
Will a subscription update overwrite custom rules?
First, distinguish a connection subscription updated in Home from a remote configuration updated in Config. They are different items; updating a remote configuration may replace its contents. Keep a copy before updating, then check the selected file and [Rule]. Do not assume local edits will necessarily be preserved. Get subscription links from your service provider.
How should I troubleshoot buttons that stop working after a REJECT rule?
Check the new requests generated when you tap the button and see whether a domain for authentication, an API, or a resource was rejected. Temporarily disable the suspected rule and test again. Once you confirm the dependency, narrow the REJECT scope or add a specific exception before it rather than allowing all requests.