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

In this guide

This guide is for users who have already imported their own subscription into Shadowrocket and are ready to edit Config. First, confirm that Global Routing is set to Config, then distinguish rule conditions from actions. Use the examples to understand exact domains, domain suffixes, IP ranges, and where FINAL belongs. Finally, use one-variable-at-a-time testing to tell the difference between a rule that doesn’t match and one whose action fails.

Check Global Routing before editing Config

In Shadowrocket, Home is where you connect and choose an existing service, Config manages configuration files, and Settings contains app preferences. A subscription provides connection details; it is not the same as the rules in your current configuration. Updating a subscription does not enable rules you edited, and saving a configuration file does not mean Home is using it for routing.

Go to Home → Global Routing to check the routing mode. This guide covers rule evaluation in Config mode; Proxy and Direct are not rules. Global Routing also includes Scene for choosing a scenario. When troubleshooting static rules, switch to Config first to avoid introducing variables from a scene change.

Config

Recommended

Select a policy using the rules in the active configuration. The DOMAIN-SUFFIX, IP-CIDR, and FINAL examples in this guide assume this mode.

Best for: testing custom rules and the final fallback one by one

Proxy

Route traffic through the proxy rather than choosing DIRECT or REJECT according to the custom rules in this guide. Use this mode as a control when checking whether the proxy connection works.

Best for: temporarily isolating rule-based routing

Direct

Route traffic directly through the current network. While this mode is selected, access results cannot tell you whether a PROXY rule in Config works.

Best for: checking direct access over your local network

Rule syntax: condition first, policy last

Rules typically use commas to separate fields and go in the [Rule] section of the configuration. A domain rule usually follows the pattern “type, match, policy.” FINAL has no match field, so write “FINAL, policy.” Don’t use Chinese commas or add explanatory text to a rule line, and don’t create multiple [Rule] sections just to add a few rules to the same file.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
FINAL,PROXY

Here, example.com is a documentation example domain, and 192.168.50.0/24 is an example private network range; it may not be used by your network. This snippet illustrates field structure and order. It is not a general-purpose rule set to replace your existing configuration.

Keyword	Example condition	What to check
`DOMAIN`	`api.example.com`	Matches the exact domain only; other subdomains are not included.
`DOMAIN-SUFFIX`	`example.com`	Matches the domain and its subdomains. No wildcard asterisk is needed.
`IP-CIDR`	`192.168.50.0/24`	Matches the network containing the target IPv4 address, not text in a domain name.
`GEOIP`	`CN`	Matches based on the target IP’s geographic database entry, not the page content.
`FINAL`	No match field	Catches requests that didn’t match any earlier rule; it must be last in the rule list.

DOMAIN-SUFFIX matches domain boundaries, not arbitrary strings. For example, example.com can match www.example.com, but not notexample.com. Don’t include https://, a page path, or query parameters in the rule; they aren’t part of the domain field.

Rule order: put exceptions before broader matches

Rules aren’t “last rule wins,” and they aren’t automatically sorted with the longest or most specific match first. For each request evaluated by the rules, Shadowrocket checks from top to bottom and applies the policy of the first match. Put specific exceptions before broader rules that would also match them.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

api.example.com: The first domain rule matches, so PROXY is applied. The later suffix rule cannot change it to DIRECT.
www.example.com: The first rule doesn’t match, but the second does, so DIRECT is applied.
Other destinations: GEOIP is checked next. If it doesn’t match, the FINAL rule applies PROXY.

If DOMAIN-SUFFIX appears before DOMAIN, api.example.com matches the suffix rule first, leaving the exact-match exception unreachable. Likewise, a rule set with broad coverage can prevent local exceptions from taking effect if it comes first. Check all earlier rules when troubleshooting; confirming that a target rule “exists” isn’t enough.

1 rule

Each evaluation uses the first matching rule

3 policies

The three policies covered here: PROXY / DIRECT / REJECT

/32

The IPv4 CIDR prefix length for a single address

What PROXY, DIRECT, REJECT, and FINAL do

A rule type answers “what matches?” A policy answers “what happens after a match?” PROXY, DIRECT, and REJECT are the policies used here. FINAL is a fallback rule type with no additional match condition. Keeping these concepts separate prevents you from mistaking FINAL for a new transport protocol.

PROXY: Send matching requests through the proxy route. Check the current selection and how policies are configured to determine the actual connection target. Adding PROXY does not provide a working service or fix incorrect authentication details.
DIRECT: Access the destination through the current network instead of the proxy route. Direct access still depends on your local network, DNS, and destination availability; it does not bypass every network restriction.
REJECT: Reject matching requests. Use this to test blocking for a destination you know you don’t need. A rule that matches too broadly can also affect sign-ins, images, or app APIs, so keep a way to undo it.

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

This example first rejects blocked.example.com, then sends other domains under the same suffix DIRECT, and routes remaining requests through PROXY. If FINAL is moved to the first line, every request that reaches this section is caught there, and the domain rules below can’t be evaluated.

IP-CIDR, GEOIP, and DNS: where addresses come from

Domain and IP conditions use different information. DOMAIN-SUFFIX checks the domain, while IP-CIDR and GEOIP check the destination address. If a request has a domain but no available destination IP yet, IP-based rules may involve DNS resolution. Don’t assume a domain rule failed because the network range is wrong.

IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

The two IP-CIDR entries above illustrate the difference between a network range and a single address. The first already covers 192.168.50.10, so there is usually no reason to keep the second if both use the same policy. To apply a different policy to that address, move the /32 exception before the /24 rule instead of adding it after.

no-resolve means the IP rule won’t trigger an additional domain lookup just for itself. It does not disable DNS for the entire app, nor does it mean the request has no destination IP.
If the request already has an available destination IP, that address can still be checked against the network range. If no address is available and the rule doesn’t trigger resolution, the rule can’t match an IP based on the domain alone.
GEOIP,CN,DIRECT uses an IP geolocation database. CDN routing, DNS responses, and database records can all affect the result; a Chinese-language page is not a match condition.
Keep IPv6 in mind when accessing domains. An IPv4 IP-CIDR rule does not automatically cover IPv6 addresses. If the destination uses IPv6, check whether you need a separate IPv6 rule.

Rules can only use information available for the request. If an app connects directly to an IP address with no associated domain information, domain rules may not match. When troubleshooting, record the actual destination domain or address instead of adding more broad DOMAIN-SUFFIX rules.

Edit and test: change one condition at a time

Keep the current working configuration before making small changes. Distinguish remote configurations from local copies: an update to remote content may overwrite local edits. Updating an existing subscription usually refreshes connection entries, so a successful update does not prove that custom rules are active. Before testing, also confirm that the existing proxy connection works.

Keep a copy of the original

Open Config, confirm which configuration is in use, and keep a recoverable copy. If you need to edit content from a remote source, first make an editable local copy so the next update won’t overwrite your test rules.
Edit the rule section

In Config, open the file you want to test and find [Rule]. Move any exact-domain exception above the corresponding suffix rule, make sure FINAL is still last, save, and select that configuration.
Confirm the routing mode

Go to Home → Global Routing → Config. Check the current proxy selection, and make sure Proxy, Direct, or Scene behavior isn’t affecting this rule test.
Start a fresh request

Close and reopen the destination page, and reconnect if needed to reduce interference from existing persistent connections. Change only one rule’s order or policy per test. Don’t change DNS and proxy settings at the same time.
Record results and restore

Record the destination, matching rule, applied policy, and observed result. Check available request logs. If the result isn’t what you expected, restore the original configuration and test the same destination again.

Separate observed results from expected behavior in your test notes. For example, if you temporarily set a domain you control to REJECT, the expected result is that related requests are blocked. If the page still shows content, first rule out cached content, other domains, and existing connections rather than concluding that the entire rule system is broken. These examples do not represent test results on your network.

Troubleshooting: trace the match to find the cause

I added a DOMAIN rule, but traffic still uses DIRECT. What’s wrong?

First, go to Home → Global Routing and confirm Config is selected. Then open Config and check which file is active. Next, look above your rule for an earlier DOMAIN-SUFFIX rule, IP rule, or rule set that may match first. Move the exact exception above any rule that covers it, save, and send a new request.

FINAL is set to PROXY. Why do some requests still go DIRECT?

FINAL only catches requests that didn’t match earlier rules. Check whether the destination already matches a DIRECT rule, such as DOMAIN-SUFFIX or GEOIP. Don’t move FINAL to the top. Change the rule that actually matches, or add a narrower exception before it.

A PROXY rule matches, but the site won’t load. Should I change the order?

If the match result is already PROXY, first check the selected proxy, authentication details, destination port, and DNS. For comparison, temporarily select Home → Global Routing → Proxy, then restore Config when the test is complete. A failed policy action and a rule that didn’t match require different troubleshooting steps.

A REJECT rule broke the app. How do I undo it?

In Config, remove the rule you just added or restore a backup, then reconnect. Use the actual request domain to narrow the match, and start by testing a single destination with DOMAIN. Don’t block a shared suffix or broad network range outright.

Use the same order of checks every time: Is the correct configuration active? Is Global Routing set to Config? Which rule matched first? Can that policy be carried out? Complete these four checks before broadening the rules. This gives you a clear rollback point and avoids using duplicate rules to mask configuration selection or connection issues.