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

At a Glance

This guide is for users who already have a provider and subscription and want to edit Shadowrocket rules. On Home, first check that Global Routing is set to Config, then confirm the active configuration in Config. Organize the Rule section as “specific exceptions, broader matches, FINAL,” and check the match log with a new request. The examples explain matching logic only and include no connection credentials.

Choose a configuration before routing with Config

On Shadowrocket’s Home screen, open Global Routing and select Config. Then go to Config and confirm that the configuration you want to edit is selected. Open its editor and find the Rule section. In a text configuration, the section marker is [Rule], with one rule per line. Save a restorable copy before making changes so you don’t overwrite a working configuration.

Proxy, Direct, Config, and Scene in Global Routing are different operating modes. Proxy and Direct select a global outbound route; they should not be used to test whether a custom rule is working. This guide uses Config so requests are routed according to the selected configuration. Scene applies settings based on the active scenario. Keep the operating conditions fixed during testing so a scene change doesn’t affect the results.

On Home → Global Routing, select Config and note the current proxy selection.
Open Config, confirm the active configuration’s name, and edit the Rule section in a copy.
Save the configuration, confirm it’s still selected, then start a new test connection.
Visit a known test destination and check its destination, matched rule, and outbound details in Data’s connection log. Available fields depend on the current interface.

The server list in a subscription and the routing rules in Config serve different purposes. Updating an existing subscription usually updates connection details; it does not confirm that the Rule section changed. Updating a remote configuration, however, may replace its contents. Before troubleshooting, note which resource was updated so you don’t mistake changed connection settings for a change in rule order.

Match order: the first matching rule determines the policy

Rules in the Rule section are checked from top to bottom. Once a rule matches and selects a policy, matching stops; Shadowrocket doesn’t continue looking for a “more specific” rule. A specific rule doesn’t automatically take precedence over a broader one. It must appear first to have a chance to match first.

New request Resolve destination Check rules in order Determine policy Route outbound

For example, to send api.example.com through PROXY while sending other subdomains of example.com through DIRECT, use the following order. These example domains illustrate the syntax only. To test connectivity, substitute a destination you’re authorized to use and know is reachable.

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

For a request to api.example.com, the first DOMAIN rule matches. For www.example.com, the first rule doesn’t match, so the DOMAIN-SUFFIX rule applies. DOMAIN-SUFFIX matches the domain itself and its subdomains; it doesn’t match any domain that merely contains the same string.

Rule of thumb: put exceptions before broader matches

If a destination matches both DOMAIN and DOMAIN-SUFFIX, change the order of the two rules and test with a new request. Adding a specific rule below a broader rule won’t override the earlier match.

Policies: PROXY, DIRECT, and REJECT determine how a match is handled

A rule typically consists of a rule type, a match value, and a policy, separated by English commas. In DOMAIN,api.example.com,PROXY, DOMAIN is the match type, the domain is the match value, and PROXY is the policy applied when the rule matches. Don’t put a full URL, path, or Chinese comma in a field that expects a domain.

The three basic policies: PROXY / DIRECT / REJECT

Domain examples: exact match with DOMAIN, suffix match with DOMAIN-SUFFIX

One FINAL fallback at the end

Policy	What happens on a match	What to check
`PROXY`	Use the proxy selection in the active configuration	The selected proxy is available, and its connection settings match the server
`DIRECT`	Connect directly to the destination without forwarding through a proxy server	The current network can reach the destination directly
`REJECT`	Reject the matching request	The destination should be blocked, with no required dependencies accidentally affected

A PROXY match doesn’t guarantee a successful remote connection. Even when the rule is correct, an incorrect proxy address, port, or authentication setting can cause the connection to fail. DIRECT doesn’t mean the request bypasses all system network settings; it only means traffic isn’t forwarded through a proxy server here. REJECT explicitly blocks the request, so a resulting access failure shouldn’t be mistaken for a connection timeout.

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

In this configuration, blocked.example.com is rejected by the first rule even though it also belongs to example.com. If you move the REJECT rule below DOMAIN-SUFFIX, it won’t block this destination. A website may also request separate domains for sign-in, images, or APIs. Check connection records for each request instead of judging only by whether the home page loads.

FINAL fallback: put it last and don’t add a domain

FINAL catches requests that don’t match any earlier rule; it has no domain or address condition. Use FINAL,PROXY or FINAL,DIRECT, not FINAL,example.com,PROXY. Keep one explicit FINAL rule at the end of the Rule section. If it appears in the middle, rules below it won’t get a chance to match.

Send all other requests through PROXY

DOMAIN: blocked.example.com,REJECT
DOMAIN-SUFFIX: example.com,DIRECT
FINAL: PROXY

Handle rejected exceptions and direct-connection ranges first; send all other requests through PROXY.

Use PROXY only for specified destinations

DOMAIN: blocked.example.com,REJECT
DOMAIN-SUFFIX: example.com,PROXY
FINAL: DIRECT

Handle rejected exceptions and proxy ranges first; send all other requests through DIRECT.

These examples represent two different routing setups. Don’t add both cards’ FINAL rules to the same Rule section. Choose a fallback based on destination reachability on your current network and your connection requirements. Without a matching domain rule, a request falls through to FINAL. A missing rule will therefore often show up first as an unexpected fallback policy.

Add IP-CIDR and GEOIP: handle specific address ranges first

Domain rules match domain conditions; IP-CIDR rules match IP address ranges. For local devices, you can place a known LAN subnet before broader geographic IP rules. The example 192.168.0.0/16 covers addresses from 192.168.0.0 through 192.168.255.255. Not every home network uses this range, so adjust it to match your router’s network plan.

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

IP-CIDR matches IPv4 address ranges. This example applies to a known LAN range; it doesn’t mean that every local resource is covered.
no-resolve means not to trigger a DNS lookup specifically to match this IP rule. It doesn’t mean DNS is never used during the request.
GEOIP,CN,DIRECT matches based on geographic data for the destination IP, not the website’s language, domain suffix, or your location.
A domain may resolve to different addresses, and IP geolocation data may not match expectations. For a domain that must always follow a specific route, use an explicit domain rule near the top of the list.

If a request has only a domain name and no destination IP available for address-based rules, a LAN rule with no-resolve won’t trigger a lookup on its own. IP-related matching may instead use an existing resolution result or involve the resolution process. If the same domain appears to take different routes, first check the actual destination IP and match log, then consider DNS or geolocation data. Don’t assume the rule order changed randomly.

Verify after saving: use three request types to separate rule issues from connection failures

Change one group of rules at a time, save, then create a new request. A browser or app may reuse an existing connection; saving the rule file doesn’t turn that connection into a fresh matching test. If needed, close the test app’s existing connections, or disconnect and reconnect Shadowrocket at an appropriate time, then revisit the destination.

Check the specific exception. Choose a destination that matches both a specific condition and a broader one. Confirm that the earlier DOMAIN rule matches instead of the later DOMAIN-SUFFIX rule.
Check the broader rule. Choose another destination under the same suffix that isn’t listed as an exception. Confirm that DOMAIN-SUFFIX handles it.
Check FINAL. Choose a known reachable destination that doesn’t match any earlier condition. Confirm that it uses the intended fallback policy.
Check REJECT. Temporarily use a controlled test destination to confirm that the reject rule works. Remove the temporary rule afterward so it doesn’t affect everyday access.

Test notes should include at least the destination domain, actual IP, Global Routing mode, matched rule, and result. “Doesn’t load” isn’t enough. If the expected rule matched but the connection failed, check the outbound connection. If a different rule matched, revisit the order and match conditions first; don’t change protocol settings at the same time.

Rule of thumb: confirm the match before checking outbound connectivity

If the wrong rule matched, check the selected configuration, match scope, or rule order. If the correct rule matched but access failed, check direct network reachability for DIRECT or connection settings for PROXY. Change one factor at a time and keep a restorable copy.

Maintain your rules: recheck exceptions and fallback after updates

After updating a remote configuration, review the exceptions at the top of the Rule section and FINAL at the end to make sure your custom content wasn’t replaced. After updating a subscription, check that the proxy selection you were using is still available. These are separate maintenance tasks. Record configuration contents separately from connection details to understand changes in behavior after an update.

Save a copy of the current working configuration and record the purpose and expected policy for each custom rule.
Before adding a DOMAIN-SUFFIX rule, check for an existing broader match. Put any specific exceptions you want to preserve above it.
Remove duplicate or unreachable rules, and make sure no rules you still need appear below FINAL.
For a full reference to configuration fields, see Configuration Field Reference. To review the initial connection steps, see the Setup Guide.

Rules determine how requests are routed; they don’t provide connectivity. A one-time app purchase is not a connection plan. This guide assumes you already have your own provider and subscription. Shadowrocket is a closed-source commercial app, primarily for iPhone and iPad. The App Store is the only place to get it; check the App Store listing for system requirements.