Shadowrocket Custom Rules: Match Order, FINAL Fallback, and PROXY/DIRECT/REJECT

At a glance

This guide is for users who have already configured a connection in Shadowrocket and are ready to edit Config. First check Global Routing, then organize rules with specific exceptions first, general rules next, and FINAL last. Use domain and IP examples to distinguish match conditions from actions, then verify the result with a new connection. Get subscriptions from your service provider; connection services and client purchases are handled separately.

Check Global Routing first

Whether custom rules are evaluated depends first on the current selection under Home → Global Routing. Config processes connections according to the active configuration; Proxy and Direct apply different global handling. Don’t test rule order in Proxy, and don’t treat access to a destination in Direct as proof that a particular DIRECT rule matched.

Config

Recommended

Use the active Config to determine connection handling. The result may be PROXY, DIRECT, or REJECT; unmatched connections are not automatically assumed to go direct.

Best for: writing, testing, and using custom rules day to day.

Proxy

Applies proxy handling globally rather than testing routing with the standard rule order described here. It can help determine whether a configured proxy connection is available.

Best for: briefly isolating proxy connection issues from rule issues.

Direct

Applies direct handling globally. If a destination opens, that only confirms the current direct path works; it does not prove that a rule in Config took effect.

Best for: comparing results over your local network connection.

Global Routing may also use Scene. Scene follows its configured conditions. When troubleshooting, note the original settings, then temporarily select Config explicitly so changes caused by switching scenes aren’t mistaken for rule changes. Settings → On Demand manages connection triggers; it doesn’t change the matching order in [Rule]. Keep the network and trigger conditions as consistent as possible while testing.

Takeaway: keep test conditions consistent

First confirm Global Routing is set to Config and the intended configuration is active, then change one rule. Otherwise, even correctly written configuration text won’t tell you whether this change took effect.

Rule syntax and first-match behavior

A typical rule uses “type,match,policy,” with fields separated by English commas. FINAL has no match field, so it usually contains only two fields. Keep rule keywords and policies in English, and don’t insert non-English punctuation into keywords. The examples below illustrate configuration text; they aren’t app screens or a complete configuration for every network.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

3 fields

Typical rule: type, match, policy

2 fields

FINAL: keyword and fallback policy

First match

Evaluated in text order; rules aren’t automatically sorted by specificity

Suppose the domain being checked is login.example.com. The first DOMAIN rule matches, so DIRECT is used; the next DOMAIN-SUFFIX rule doesn’t change it to PROXY. If you swap these two lines, the broader suffix rule matches first, and the same domain uses PROXY. A “more specific” rule is an exception only when it appears earlier; there’s no automatic priority that overrides a preceding rule.

DOMAIN,example.com,DIRECT: Matches this exact domain; its subdomains aren’t included automatically.
DOMAIN-SUFFIX,example.com,PROXY: Matches example.com and its subdomains, not every domain that happens to contain this text.
FINAL,PROXY: Uses PROXY when none of the preceding rules match. It isn’t a second check added to every rule.

PROXY, DIRECT, and REJECT

The match condition answers “which destination does this rule apply to?” The policy answers “what happens when it matches?” DOMAIN-SUFFIX doesn’t inherently mean proxy, and IP-CIDR doesn’t inherently mean direct; any match type can be paired with different policies. Check the condition and policy separately when editing a rule—don’t rely on the keyword at the start of the line alone.

Policy	Action	What to check
`PROXY`	Routes the connection through the proxy path.	Check the selected proxy, policy references, and connection availability.
`DIRECT`	Connects directly to the destination.	Check whether the local network can reach the destination.
`REJECT`	Rejects matching connections.	Check that the rejection scope doesn’t include required domains by mistake.

PROXY doesn’t create a connection service or restore an unavailable connection. If your configuration uses custom policy group names, check that each name has a corresponding definition and selection; don’t copy a group name from another configuration straight into a rule. The examples here use only the three basic policies to make rule order easier to observe; they don’t require replacing all existing policy groups.

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

In this example, blocked.example.com is rejected by the first rule, login.example.com uses DIRECT, and docs.example.com uses PROXY. Other unmatched destinations use the DIRECT fallback in FINAL. These domains are examples for explaining syntax; they aren’t intended for users to visit and don’t provide any connection service.

IP-CIDR and GEOIP: what they match

IP-CIDR checks whether an IPv4 address falls within a specified subnet; it doesn’t classify traffic by website name. 192.168.0.0/16 covers addresses from 192.168.0.0 through 192.168.255.255, but not 10.0.0.0/8. To route local devices directly, check their actual addresses and subnets rather than treating one range as the entire local network.

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

no-resolve: On the relevant IP rule, this avoids triggering a DNS lookup solely to match that rule; it doesn’t disable DNS for the entire configuration. The rule can still evaluate an address when a usable destination IP is already available.
GEOIP: Checks geographic data associated with the destination IP, not the webpage language, domain suffix, or user’s location. CDN address changes, DNS results, and the geographic data itself can all affect the outcome.
IPv6: IPv4 subnet rules don’t automatically cover IPv6 addresses. For IPv6 traffic, review address rules and network settings separately; the three examples above don’t guarantee complete coverage.

If a domain must always use a specific policy, use an explicit DOMAIN or DOMAIN-SUFFIX rule and place it before any general rule that might match first. Don’t delete all GEOIP rules just to fix routing for one domain. Find out which rule actually matched, then decide how much to change.

FINAL fallback and safe editing steps

FINAL usually goes at the end of [Rule]. Only connections that haven’t matched any preceding rule reach it, so adding ordinary rules after FINAL usually won’t have the intended effect. Choose FINAL,PROXY or FINAL,DIRECT based on how you want unmatched connections handled; neither is a universal answer for every user.

Keep a backup

Open Config, confirm which file is active, and save a recoverable copy first. Note the existing FINAL, policy group names, and rule order to avoid losing custom content when a remote configuration is replaced.
Set the mode

Select Config under Home → Global Routing. Return to Config and confirm that the file you’re about to edit is the same one that’s active, not another copy with a similar name.
Add the exception

In the file’s [Rule] section, put the exact DOMAIN exception before the relevant DOMAIN-SUFFIX rule. Add the new line before FINAL, keep the English commas, and preserve the existing section boundaries.
Check the fallback

Check that FINAL at the end of [Rule] behaves as intended. Don’t add multiple FINAL rules for the same purpose or write FINAL as a three-field rule with a domain.
Test a new connection

Save and confirm the configuration is active, then have the target app establish a new connection. Check the destination domain or IP, matched rule, and applied policy in the connection log. If the result is unexpected, restore the backup before making changes one at a time.

Rule edits mainly affect how new connections are evaluated; existing long-lived connections may continue using their previous route. End the old session before testing. If needed, reconnect when it’s safe to interrupt the task, then open the same destination again. Don’t repeatedly switch modes during a file transfer or call—you could mistake a dropped connection for a rule syntax error.

Common reasons rules don’t take effect

Start by checking whether the intended configuration is in use, then identify which rule matched the destination, and finally check whether the resulting policy can connect. A page failing to load doesn’t prove REJECT matched; a page loading doesn’t mean every related domain used the same policy. Login, images, and video may use different domains, so check each connection separately.

Why does traffic still use PROXY when I set DIRECT?

First check whether Home → Global Routing is set to Config, then see if a rule such as DOMAIN-SUFFIX appears before the DIRECT line and matches the same destination. Move the exact exception above the broader rule, save, and establish a new connection. Don’t just keep switching the proxy selection in the list.

Why didn’t adding a rule at the end change anything?

Open [Rule] in the active Config and find FINAL. If the new rule is after FINAL, move it above FINAL. If a broader matching rule appears earlier, adjust its position too. Move one rule at a time so you can identify which change affects the result.

Why didn’t the domain match when I added no-resolve to IP-CIDR?

Check whether a usable destination IP was available for that evaluation. no-resolve doesn’t perform a DNS lookup to obtain an address for this rule. If you want to set a policy for a specific domain, use an explicit DOMAIN or DOMAIN-SUFFIX rule and put it before general IP rules.

A REJECT rule broke the whole page. How can I fix it?

Restore the changed rule from your backup, or remove only the REJECT line you just added, then establish a new connection and test again. Check whether the rejected domain also serves login, scripts, or other resources. To limit the scope, use an exact DOMAIN match instead of an overly broad suffix rule.

Why did my rules revert after an update? What should I check?

In Config, check the active file, its remote source, and the [Rule] contents to see whether an update replaced your local edits. Restore the saved copy first, then decide how to maintain your custom rules. Repeatedly updating a connection subscription won’t restore configuration rules.

After troubleshooting, keep the smallest set of rules that explains the result. Every exception should have a clear target and purpose; FINAL should handle only unmatched connections. For help with interface terms, see the glossary. If the connection path still doesn’t work, use the troubleshooting guide to check your network and proxy connection instead of adding more rules.