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

The Core of Rule Priority: Stop at the First Match

Shadowrocket does not evaluate the entire rule list and then choose the “most specific” match. It checks rules one by one from top to bottom in the order written in the configuration. Once a rule matches the current request, later rules are skipped. Priority is therefore determined by position—not automatically by the rule name, character length, or strategy type.

For example, the same domain may match both an exact DOMAIN rule and a DOMAIN-SUFFIX rule covering the entire suffix. If DOMAIN-SUFFIX comes first, the more specific DOMAIN rule will never take effect. Put exceptions before broad rules, and place the broadest fallback at the end.

A typical decision can be broken into five steps: an app starts a connection; Shadowrocket obtains the destination domain or IP; checking begins at the first line of [Rule]; the process stops at the first matching rule; and the strategy at the end of that line is applied. If no specific rule matches, processing continues to FINAL.

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

When accessing api.example.com in this example, the first line matches and uses DIRECT. When accessing www.example.com, the first line does not match, so DOMAIN-SUFFIX matches next and uses PROXY. A destination in the private range 192.168.0.0/16 uses DIRECT; remaining requests go through GEOIP and any still unmatched are passed to FINAL.

How to Order DOMAIN, DOMAIN-SUFFIX, IP-CIDR, and GEOIP

Order rules from “narrow scope, clear intent” to “broad scope, wide coverage.” DOMAIN matches one complete domain and is useful for individual exceptions; DOMAIN-SUFFIX covers the specified domain and its subdomains; IP-CIDR matches an address range; and GEOIP classifies the destination IP using geographic data. FINAL does not inspect a specific destination—it receives every request not matched earlier.

Recommended Rule Order

1. Local and reserved addresses: Handle LAN addresses and destinations that clearly require DIRECT first, so requests to internal devices do not fall through to other strategies.
2. Exact domains: Use DOMAIN for special handling of a single host—for example, letting one API domain override a later suffix rule.
3. Domain suffixes: Use DOMAIN-SUFFIX for a root domain and all of its subdomains.
4. Address ranges: Use IP-CIDR to match a specific IPv4 network. A longer prefix generally covers a narrower range.
5. Geographic classification: Put GEOIP after specific domain and address rules, so broad classification does not capture exception requests first.
6. Final fallback: Put FINAL last to define how all remaining traffic is handled.

The value of DOMAIN-SUFFIX should contain only the domain name—never https://, a path, or query parameters. Rules match hostnames, not complete web addresses. To handle cdn.example.com, use DOMAIN,cdn.example.com,DIRECT; to cover example.com and all levels of its subdomains, use DOMAIN-SUFFIX,example.com,PROXY.

The prefix length in IP-CIDR must match the target network. For example, 192.168.0.0/16 covers addresses from 192.168.0.0 through 192.168.255.255. If it is mistakenly written as /24, the range narrows to one subnet, so other similar LAN addresses will not match.

What PROXY, DIRECT, and REJECT Change

The strategy at the end of a rule determines how a matched request is handled. PROXY passes it to the proxy strategy selected in the current configuration; DIRECT connects to the destination directly; REJECT refuses the request. These are handling actions, not rule keywords. DOMAIN-SUFFIX, GEOIP, IP-CIDR, and similar entries decide “what matches,” while the final strategy decides “how it is handled.”

PROXY does not guarantee that every request will succeed; it only passes the request to the currently selected proxy strategy. The final result still depends on the user’s existing configuration, protocol parameters, and network conditions. Shadowrocket configurations may include protocols such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard, but rule order is independent of the specific protocol: changing protocols does not alter the top-to-bottom matching behavior of [Rule].

DIRECT does not mean “bypass Shadowrocket.” The request still goes through rule evaluation first; DIRECT only determines that it should exit directly after a match. If a LAN device cannot be reached, check that the private-address rule appears before FINAL and that Global Routing is not left on Proxy.

REJECT should be limited to clearly defined targets. If DOMAIN-SUFFIX,example.com,REJECT appears first, the root domain and all subdomains will be rejected, even if DOMAIN,api.example.com,DIRECT appears later. Write the allowed exception first, followed by the broader rejection rule.

Why FINAL Must Be at the End of the Rule List

FINAL is the common exit for unmatched requests. It does not limit a domain, IP, or address range, so placing it in the middle catches every request not matched earlier and leaves later rules with no opportunity to run. Even if the configuration allows additional lines after FINAL, those lines cannot change the first match that has already been completed.

# Recommended order
DOMAIN,internal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

# Incorrect order
FINAL,PROXY
DOMAIN,internal.example.com,DIRECT

The first sequence checks the exact domain, suffix, and GEOIP rules before using PROXY for the remaining requests. In the second sequence, FINAL matches every request on the first line, so the second line never gets a chance to work. If a newly added rule appears to have no effect, first check whether it was placed after FINAL.

The strategy used by FINAL should reflect the configuration’s goal, rather than being fixed mechanically. If the structure is “list direct exceptions and proxy everything else,” use FINAL,PROXY. If it is “list only destinations that need a proxy and connect directly to everything else,” use FINAL,DIRECT. Both structures are valid, but the preceding rules must align with the fallback direction.

Verify Changes with a Consistent Checklist

1. In Config, open the configuration currently in use and confirm that the edit was made there—not in another configuration with the same name or in a backup copy.
2. Check whether [Rule] contains only one FINAL serving as the fallback, and confirm that it is the last rule in the list.
3. Return to Home and set Global Routing to Config. If it is set to Proxy or Direct, the expected custom-routing result cannot be tested in Config mode.
4. Test one destination that should match DIRECT and another that should match PROXY. Do not use a single website to judge the entire rule set.
5. If the result differs from expectations, start at the top of the rule list and look for the first DOMAIN, DOMAIN-SUFFIX, IP-CIDR, or GEOIP rule that could match, rather than checking only the line you just added.

Configuration Updates, On Demand, and Common Reasons Rules Do Not Take Effect

When users have their own provider and subscription, a configuration update may write the provider’s remote rule content again. If custom rules were edited directly in a configuration that is overwritten by updates, refreshing may restore the remote content. Before editing, determine whether the current configuration is maintained manually or updated through a subscription, then recheck the [Rule] order and FINAL position after each update.

On Demand and rule priority operate at different stages. The entry point is Settings → On Demand; it uses the configured network conditions to decide when to establish a connection. Once connected, request routing still depends on Global Routing and the current configuration rules. If On Demand has not established a connection, changing [Rule] cannot replace checking the connection conditions.

Another common cause is that the rule contains a URL. DOMAIN and DOMAIN-SUFFIX accept only the domain portion; including the scheme, port, or path makes the match incorrect. For example, to match the host in https://api.example.com:443/v1/status, the DOMAIN value should be api.example.com; port 443 and path /v1/status are not values for that domain rule.

Rule names and strategy names should also use their English originals, with fields separated by English commas. Full-width commas, missing fields, and extra spaces can create invisible differences that prevent a line from parsing as expected. After copying a rule, keep the three-field structure first, then verify the keyword, match value, and strategy one by one.

Rule Checklist Before Saving

A maintainable configuration usually has clear layers: LAN addresses and exact exceptions first, domain suffixes and address ranges in the middle, GEOIP later, and FINAL at the end. The same destination should not appear repeatedly with conflicting strategies. When an exception is necessary, express it as “specific rule first, general rule later” rather than expecting a later rule to override an earlier one.

• The edit was made in the active Config, not in another configuration that is not enabled.
• Home → Global Routing is set to Config; testing was not performed in Proxy or Direct mode.
• DOMAIN and DOMAIN-SUFFIX values contain no scheme, port, path, or query parameters.
• Rule fields use English commas, and keywords and strategies retain their English originals.
• The exact DOMAIN appears before any DOMAIN-SUFFIX that could cover it.
• The IP-CIDR prefix length is explicit; do not confuse the coverage of /16 with /24.
• GEOIP appears after domain and address rules that need priority.
• FINAL serves only as a fallback and appears last in [Rule].
• After a subscription update, recheck that custom content is still present.
• Settings → On Demand controls only connection timing; it does not replace Global Routing or rule checks.

After checking, validate with at least two samples in opposite directions: one expected to use DIRECT and one expected to use PROXY. If the configuration includes REJECT, add one clearly rejected destination. Tracing each sample from the top of the rule list to its first match is more useful for finding problems than watching only the connection switch or a single page-load time.

Shadowrocket is a closed-source commercial app for Apple platforms, primarily used on iPhone and iPad. Compatibility and system requirements for Mac, Apple TV, and Apple Vision are as listed on the App Store page. The App Store is the only official source; the developer is listed as Shadow Launch Technology Limited, the app ID is 932747118, and it is sold as a one-time purchase. The app purchase and connectivity services are separate matters; users prepare and manage their own configurations and subscriptions.