Shadowrocket Custom Rule Priority: Top-to-Bottom Matching, FINAL Fallback, and PROXY/DIRECT/REJECT

At a glance

Shadowrocket rules are not automatically sorted by specificity. Instead, they are checked from top to bottom against the information available for each request, and the first matching rule determines the policy. This guide is for users with an existing configuration who want to add a domain exception or check routing results: first make sure Global Routing is set to Config, put specific exceptions before broader rules, leave FINAL at the end, then check the result with a new connection.

Check Config first, then verify that the rule is taking effect

The [Rule] section defines how requests are assigned a policy. When troubleshooting a custom rule that is not taking effect, do not start by adding more rules. First check which configuration the app is using and the current Global Routing mode. If Proxy or Direct is selected, the result does not verify how rules are matched in Config.

Open Home → Global Routing, make sure Config is selected, then return to Home.
Open Config and check which configuration is selected. If there is more than one, make sure you are editing the same configuration that is in use.
Open the configuration editor and check the [Rule] section. Save your changes and make sure the edited configuration is still selected.
Return to Home and reconnect if needed. Then send a new request to the target domain; simply refreshing a page that reuses an existing connection may not test the updated rule.

This guide covers rule order in Config, not Scene settings. Settings → On Demand controls conditional connection behavior; it does not set rule priority. An automatic connection only confirms that a connection was triggered, not that a domain rule matched.

Keep a restorable copy of your configuration

Save a copy of the original configuration before making changes. The examples here explain rule syntax and ordering; they are not complete connection settings or a replacement for your existing configuration. Manage any existing services and subscriptions yourself. This site does not provide, sell, or recommend nodes or subscriptions.

Rules are checked top to bottom: specific rules are not moved up automatically

A rule's matching condition and its policy are separate. In DOMAIN-SUFFIX,example.com,PROXY, DOMAIN-SUFFIX is the rule type, example.com is the match value, and PROXY is the policy applied when it matches. A domain suffix rule can match the domain itself and its subdomains, so a later exception for one subdomain may never be checked.

New requestCheck conditionsFirst matchApply policyStop checking

Here is an ordering that can be misleading. When you visit docs.example.com, the suffix rule above already matches, so the request uses PROXY. The exact-domain rule below does not override it just because it is more specific.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,docs.example.com,DIRECT
FINAL,PROXY

To route docs.example.com through DIRECT while using PROXY for other domains matching that suffix, move the exact exception above the broader rule. Priority comes from position, not the keyword name or when the rule was added.

[Rule]
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

Policies covered here: PROXY / DIRECT / REJECT

Conditions in the examples: DOMAIN / DOMAIN-SUFFIX / IP-CIDR / GEOIP

FINAL at the end: catches requests that did not match earlier rules

In short: look for an earlier rule that takes precedence

If a new exception has no effect, first look for rules matching the same domain or a parent suffix. Move the exception before the first rule that could match it. Re-adding the same rule will not raise its priority.

PROXY, DIRECT, and REJECT: three outcomes after a match

The policy determines what happens after a match, not which line is checked first. Changing PROXY to DIRECT does not give a rule higher priority. A REJECT rule placed after a broad allow rule cannot block a request already matched earlier.

Policy	What it does	What to check
`PROXY`	Routes the request through the outbound handling assigned to the proxy policy.	Check which proxy is selected and whether it is available. A rule match does not guarantee that the remote destination is reachable.
`DIRECT`	Connects directly to the destination without using a proxy server.	Check whether the current network can reach the destination directly. DIRECT does not mean “disconnect the entire VPN.”
`REJECT`	Rejects connections matching the rule.	Check whether the blocked domain provides resources the page needs, and avoid conditions that are too broad.

A rule can also refer to a policy group already defined in the configuration. Before copying a snippet, check what the referenced name means in your current configuration; arbitrary text does not automatically become an existing policy. This guide uses PROXY, DIRECT, and REJECT to explain basic behavior. It does not create additional policy groups or specify any service.

To route one domain directly: Add an exact DOMAIN,docs.example.com,DIRECT rule before any suffix rule that could match it.
To route a domain suffix through a proxy: Use DOMAIN-SUFFIX,example.com,PROXY and check whether a broader matching condition appears above it.
To block a specific domain: First test with a narrowly scoped rule such as DOMAIN,blocked.example.com,REJECT, then decide whether you need to broaden the match.

What FINAL does: provides a fallback, not an automatic retry

FINAL,PROXY applies PROXY when none of the preceding rules match. Since it has no domain or network condition, it belongs at the end of the rule section. If FINAL comes earlier, later rules cannot catch requests that have not matched yet.

Example rule order with a PROXY fallback

Exact exception: DOMAIN,docs.example.com,DIRECT
Suffix policy: DOMAIN-SUFFIX,example.com,PROXY
Final fallback: FINAL,PROXY

Requests unmatched by the first two rules go to PROXY; verify reachability separately.

Example rule order with a DIRECT fallback

Exact block: DOMAIN,blocked.example.com,REJECT
Suffix policy: DOMAIN-SUFFIX,example.com,PROXY
Final fallback: FINAL,DIRECT

Requests unmatched by the first two rules connect directly; a failed direct connection does not send them back to an earlier rule.

FINAL does not mean “try another route if the earlier proxy connection fails.” Once a rule matches, a later connection timeout does not make the matching process continue down the list. If a request matched a PROXY rule, check the connection for that policy rather than adding a second FINAL at the end in the hope of falling back after a failure.

First decide whether unmatched traffic should go to PROXY or DIRECT.
Check whether the existing configuration already has a FINAL rule. Change its fallback policy rather than adding another one without checking.
Move the rules you want to keep above FINAL, then make sure no active rules are left below it.

Putting domains, IP ranges, and GEOIP together in one example

This example shows one readable order: explicit blocks, exact-domain exceptions, domain suffixes, a specified IP range, GEOIP, and FINAL last. It is an example layout, not a fixed priority order by rule type. If your requirements differ—for example, if a particular IP range must always connect directly—reassess its position and whether the request has the IP information needed for a match.

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

example.com and its subdomains illustrate domain relationships. 192.0.2.0/24 is a documentation-only example range, not a real service address. GEOIP,CN,DIRECT demonstrates matching by the destination IP's geographic database classification; it does not mean every user should use this policy.

Rule keyword	What it matches	Note for this example
`DOMAIN`	The full domain name.	Sets an exception for one specified domain; it does not automatically include all of its subdomains.
`DOMAIN-SUFFIX`	The domain itself and its subdomains.	If this rule comes first, a later exact-domain exception under the same suffix may not match.
`IP-CIDR`	The network containing the destination IPv4 address.	`no-resolve` means this rule will not actively trigger a DNS lookup for matching. It does not disable all DNS.
`GEOIP`	The destination IP's classification in a geographic database.	The match is not based on webpage language, the domain suffix, or the address of the website's owner.
`FINAL`	Requests that did not match earlier rules.	Keep it at the end as a fallback; it does not check whether the destination is reachable.

Domain rules rely on available domain information, while IP rules rely on the destination IP. One cannot replace the other just because they seem to refer to the same website. A page may also request resources from several domains. If the main page matches DIRECT, that does not mean its images, videos, or login API use DIRECT too. When troubleshooting, note the specific request destination, not just the address in the browser bar.

In short: change one matching condition at a time

Start by testing one specific domain to verify the rule position and policy, then introduce suffixes, IP ranges, or GEOIP gradually. If you change DNS, Global Routing, and several rules at once, it is hard to tell which change affected the result.

How to verify changes and troubleshoot common issues

When verifying a rule, check “whether it matched” separately from “whether the connection succeeded.” The first depends on the configuration, rule order, and available destination information. The second depends on network reachability for DIRECT or the connection assigned to PROXY. Judging by page load speed alone can lead you to mistake caching, connection reuse, or server response differences for rule behavior.

Record the baseline: Note the current configuration, Global Routing mode, target domain, and expected policy. Keep track of the original rule position before changing it.
Save and apply: Make sure the edited configuration is in use, and reconnect if necessary. Editing a configuration that is not selected is not enough.
Start a new connection: End the existing session before retrying so a long-lived connection does not keep using the handling applied when it was established.
Check the connection log: Use the app's available request or connection logs to check the destination, policy, and any available match details. If there is no record, first check whether the request went through the current connection.
Change one thing at a time: Verify the rule position first, then the policy. If the test fails, restore your saved copy and try again; do not keep stacking unverified exceptions.

I added the rule at the end. Why does the request still use the old policy?

First check whether the new rule is below FINAL, then look upward for a DOMAIN-SUFFIX or other rule that could match the target. Move the new rule before the first matching rule, save, and test with a new connection. Repeatedly adding the same rule will not change the result.

I set the policy to DIRECT. Why can't the destination load?

First check the request log to confirm that DIRECT was actually applied. If it was, check whether the current network can reach the destination directly and whether domain resolution is working. DIRECT specifies the outbound route; it does not guarantee that the destination is reachable on your current network.

The whole page is broken after I set REJECT. What should I do?

Temporarily remove the REJECT rule you just added and make the request again to see whether the problem goes away. If it does, narrow a broad DOMAIN-SUFFIX rule to the exact DOMAIN you need to block, then check which other resource domains the page depends on.

My manually added rules disappeared after updating the configuration. Why?

First determine whether you updated the server list for an existing subscription in Home or a remote configuration in Config. Fetching a remote configuration again may overwrite local edits. Save a copy before updating, compare the [Rule] section afterward, and check which configuration is currently selected.

To review the basics, see the user guide. For a check of the Global Routing mode, see the Global Routing section of the feature guide. After testing, keep the exceptions you need and remove duplicates so the full configuration remains easy to follow from top to bottom.