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

1. Check Global Routing: When Rules Are Applied

Adding rules does not mean they are being used to process connections. In Shadowrocket, Home manages connections and global routing, Config manages configuration files, and Settings controls app preferences. To test the custom rules in this guide, first select Config under Home → Global Routing, then confirm that Config has the file you just edited selected.

Scene in Global Routing selects a routing mode for a particular scenario; it is not the same as the policy field on an individual rule. For troubleshooting, keep the mode set to Config to reduce variables caused by switching scenes. Settings → On Demand controls when connections are initiated based on conditions; it does not decide whether a domain uses PROXY or DIRECT. Starting a connection automatically and routing traffic after it connects are separate functions.

2. Match from Top to Bottom: Put Specific Exceptions Before Broad Rules

A rule list is not a collection where the most specific match automatically takes priority; it is an ordered sequence of checks. Shadowrocket scans from the top, and the first matching rule determines the policy. Later rules do not add to or override the result for that request. Adding a more specific rule farther down cannot undo a match that has already occurred above it.

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

In this example, account.example.com matches DOMAIN first and uses DIRECT. media.example.com does not match the first line, so it reaches DOMAIN-SUFFIX and uses PROXY. If you swap the first two rules, the broader suffix rule will match account before its exception can. Here, example.com is used only to illustrate the syntax; it does not represent an available proxy service.

When organizing rules, you can check them in this order: specific targets to block, specific exceptions to preserve, broader domain ranges, address ranges, and a fallback. This is a useful checklist, not a fixed template. If a domain must use a direct connection, put that exception before any rule that would otherwise match it. What matters is how rules overlap—not simply the order of their keyword names.

3. Writing DOMAIN-SUFFIX, IP-CIDR, and GEOIP Rules

Domain rules match the request’s hostname; address rules match the destination IP. Both can describe the same service, but they use different matching criteria. Don’t put a domain in an IP-CIDR rule, or include a full URL—with its scheme, path, and query parameters—in a DOMAIN-SUFFIX rule.

192.168.0.0/16 covers addresses from 192.168.0.0 through 192.168.255.255; it does not refer to a single device. To match one IPv4 device, use a /32 rule for its address. A DIRECT rule for a local network can keep matching local destinations from being sent through a proxy, but reachability still depends on the current network, system permissions, and the destination service.

GEOIP results depend on the actual destination address and the contents of the database. A domain ending in .com can resolve to addresses in different regions, and the same domain may use different content delivery addresses on different networks. If you need a fixed policy for a particular domain, use an explicit domain rule rather than guessing how GEOIP will classify it.

4. How PROXY, DIRECT, REJECT, and FINAL Work Together

The keyword defines what to match; the policy field defines what to do after a match. For example, in DOMAIN-SUFFIX,example.com,PROXY, the first two fields specify the match, while the last field specifies how to handle it. FINAL is a special fallback matching rule, not a fourth connection policy.

• PROXY: Send traffic through the proxy route. This requires valid connection details you already have and an available proxy selection; the rule itself does not provide a service.
• DIRECT: Connect directly to the destination. This does not mean “try a direct connection first, then switch to a proxy if it fails.” A failed connection does not continue to the next rule.
• REJECT: Block the matching request. Use it for targets you explicitly want to block; applying it to a login, verification, or resource domain may prevent a page from working properly.
• FINAL: Set a policy for requests that match no other rules, for example FINAL,DIRECT or FINAL,PROXY.

Put FINAL at the end of the rule list. Since it has no domain or address condition, it catches the remaining requests that reach it. Putting it at the top leaves later specific rules with no chance to match. A standard rule list needs one clearly defined FINAL; stacking multiple FINAL rules does not provide failover.

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

The example above illustrates a set of routing decisions: reject a specified host, preserve a login exception, send other example.com requests through a proxy, then handle local-network and GEOIP conditions, and finally send remaining requests through PROXY. It is not a one-size-fits-all configuration. To connect directly to targets that aren’t listed, change the last line to FINAL,DIRECT and note that unlisted targets will then connect directly.

5. Edit the Active Config: Back Up, Save, and Retest

Before you start, you should already have your own service provider and connection details, and have confirmed that the selected connection works. A one-time client purchase is not a service plan; this site does not provide, sell, or recommend nodes or subscriptions. Editing rules changes how existing connections are selected; it does not fix expired credentials or an unreachable server.

1. Back up the current configuration

   Go to Config, confirm which configuration file is selected, and save a copy or export a backup first. Note the existing [Rule] contents and FINAL policy so you don’t have to reconstruct the rules if an edit goes wrong.

2. Keep the routing mode fixed

   Go to Home → Global Routing → Config. Note the current proxy selection. During testing, avoid changing Settings → On Demand or switching networks at the same time.

3. Edit the rules

   Return to Config, open the editor for the active configuration, and locate [Rule]. Place specific exceptions before any broader rules that would match them. Edit the existing section rather than adding a second [Rule] section.

4. Save and select the file

   Save your changes and confirm that this file is still selected in Config. If you edited a copy, switch to that copy before returning to Home to check the connection status. This helps avoid testing a file that isn’t active.

5. Start a new request

   Reconnect and test a specific exception, a broader rule, and a fallback target separately. If needed, save your work, then disconnect and reconnect to reduce the chance that a reused connection affects the result.

Importing a subscription and managing Config are different actions. Updating an existing server subscription mainly affects connection entries; updating a remote configuration may replace rule contents. If local changes disappear afterward, check which type of item was updated. For custom rules you need to maintain, keep them in a local configuration copy you control, and check for changes after each remote configuration update.

6. Verify Matches: Check the Rules Before the Webpage

Whether a webpage opens tells you the outcome of one visit, but it doesn’t prove that a rule is correct. A page usually connects to multiple domains: the main page might use DIRECT while images, verification endpoints, or media use other policies. When troubleshooting, look in the connection log for the specific destination host, matched rule, and final policy—not just the page title or loading speed.

The domains in the table are for illustrating rule evaluation, not real test services. For actual testing, replace the examples with targets you’re authorized to access and use the same matching logic to set expectations. Change one variable at a time: adjust the order, then test. Don’t change DNS, proxy protocols, FINAL, and the network environment all at once, or it will be hard to tell what caused the result.

7. Common Issues: Rules That Don’t Work as Expected

Keep a rule list that’s easy to understand: every specific exception should have a clear purpose, every broad rule should have clear boundaries, and FINAL should state where remaining traffic goes. More rules don’t necessarily mean more accurate routing. Being able to trace a request line by line to its matching rule makes future maintenance and troubleshooting easier. For details on protocol settings, see the technical reference. For connection and settings issues, see troubleshooting.