In Shadowrocket, custom rules depend first on Global Routing, then on the active configuration file, and finally on rule order. This guide is for users with their own services and connection settings. It uses reserved domain names and documentation-only IP ranges to explain rule syntax, fallback behavior, and how to verify results. The examples illustrate syntax only; they are not complete configurations for everyday use.
Check Global Routing before editing rules
Before changing rules, check the current selection under Home → Global Routing. To apply the rules in the active configuration file, select Config. If Proxy or Direct is selected, changing rule order usually will not fix unexpected routing, because those modes do not use the current file's rules to choose an outbound path one by one.
Config
RecommendedUse the rules in the active configuration to choose a policy. Whether traffic goes direct, through a proxy, or is rejected depends on the matching rule; no match does not automatically mean a direct connection.
Use for: Writing, testing, and using custom rules
Proxy
Route connections handled by the app through the global proxy mode. This can help you check whether the proxy path works, but results in this mode do not prove that a particular rule matched.
Use for: Temporarily comparing the proxy path with rule-based routing
Direct
Connect directly for connections handled by the app. Direct does not mean the system VPN configuration is disabled, nor does it remove the active configuration file.
Use for: Comparing direct connections to a destination on the current network
Global Routing may also offer Scene, which selects a scene. When troubleshooting the examples in this guide, switch explicitly to Config so scene changes are not confused with rule changes. Also note that Config appears in two places: Config under Global Routing is a routing mode, while Config in the bottom navigation is where configuration files are managed. A file appearing in the list does not mean it is the active file.
Rule syntax: conditions first, policy last
Rules in a configuration file go in the [Rule] section. A typical conditional rule consists of a type, a match value, and a policy, separated by English commas. Chinese commas, extra spaces in policy names, or placing rules in another section can cause parsing or matching to behave unexpectedly. Know the difference between these four keywords:
| Keyword | Example | What to check |
|---|---|---|
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,PROXY | Matches example.com and its subdomains. Do not include a URL path. |
IP-CIDR | IP-CIDR,192.0.2.0/24,DIRECT | Matches an IPv4 network; /24 means the first 24 bits are the network prefix. |
GEOIP | GEOIP,CN,DIRECT | Checks the geographic database entry for the destination IP, not the text of the domain name. |
FINAL | FINAL,PROXY | Has no match-value field; use it as a fallback when none of the preceding conditions match. |
DOMAIN-SUFFIX,example.com,PROXY can match api.example.com, but it will not match another domain just because its text happens to end with “example.com”; domain boundaries matter. Do not enter https://example.com/path or append :443 to the match value. This rule matches domains, not webpage paths or ports.
IP-CIDR and GEOIP rely on the destination IP being available. Whether a domain connection is resolved, and when its IP is checked, also depends on the DNS and rule options in the configuration. A GEOIP result does not identify where a website operator is based, and a domain may resolve to different IP ranges over time.
Top-to-bottom matching: put specific exceptions first
Rules are evaluated in order. The policy on the first matching rule is applied, and evaluation stops; Shadowrocket does not keep looking for a “better” match. It does not automatically move longer domain suffixes or smaller network ranges to the top. Put specific exceptions first, broader conditions after them, and the fallback last.
[Rule]
DOMAIN-SUFFIX,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYIn this example, api.example.com and its subdomains match the first rule and connect directly, while www.example.com matches the second. If you swap the first two rules, api.example.com meets the broader example.com condition first and uses PROXY. The DIRECT exception below it will not be considered for that connection.
IP ranges follow the same ordering
[Rule]
IP-CIDR,192.0.2.128/25,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY192.0.2.128/25 is contained within 192.0.2.0/24. For connections whose destination IP is known, 192.0.2.130 matches REJECT first, while 192.0.2.20 continues down to DIRECT. If you swap these rules, the broader /24 matches the entire range first, and the rejection exception no longer takes effect.
How PROXY, DIRECT, REJECT, and FINAL work together
The first three specify what happens when a rule matches; FINAL specifies what happens when none of the earlier rules match. They are not four equivalent match conditions. In particular, FINAL,PROXY does not check a domain or region. If placed too early, it will catch traffic before later rules can be evaluated.
- PROXY: Sends traffic through the proxy path. The connection still depends on the selected proxy or the policy referenced by the configuration being available; adding PROXY does not create a connection service.
- DIRECT: Connects to the destination without forwarding traffic through the selected proxy server. It does not guarantee the destination is reachable; the destination service, DNS, and local network can all affect the result.
- REJECT: Rejects matching connections. A rejected request may appear as a missing resource or loading error in a webpage; that does not necessarily mean the app has malfunctioned.
- FINAL: Place this at the end of the rules to handle traffic that did not match earlier rules. Common forms include
FINAL,PROXYandFINAL,DIRECT; choose based on your intended routing.
If you want only the listed domains to use a proxy and all other traffic to connect directly, use FINAL,DIRECT after reviewing the full rule set. If unlisted destinations should also use a proxy, use FINAL,PROXY. There is no universally correct choice; it depends on your routing goals. Changing FINAL affects every connection that did not match an earlier rule, so its impact is often broader than adding a domain rule.
[Rule]
DOMAIN-SUFFIX,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTThis example rejects a specific subdomain, sends other example.com domains through a proxy, and connects all other destinations directly. It demonstrates how the three outcomes can be combined; it is not a complete privacy or network access setup. Before copying it into your configuration, keep any necessary existing rules and verify that the referenced proxy policy matches your active configuration.
Edit and verify: change one variable at a time
Do not overwrite a configuration that is still in use. Keep the original file, then edit a copy. If the file is updated remotely, remember that a later update may overwrite local changes. Follow these steps; file names in the interface depend on what you saved:
Confirm the routing mode
Open Home → Global Routing → Config and note the currently selected proxy. Do not change DNS, proxy selection, or On Demand at the same time.
Keep the original file
Open Config in the bottom navigation and check which file is active. Before editing, use the file controls to keep a copy or export a backup so you have a known-good version to restore.
Edit the rules
In Config, open the file you want to edit and locate the
[Rule]section. Add just one exception or swap two rules, keep FINAL at the end, then save and confirm that the edited file is active.Send a new request
Return to Home and check the connection status. End the existing request in the target app, then start a new connection. Changing the rule text does not turn an existing long-lived connection into a new one.
Check the connection log
In Data, review the connection record for the relevant time. Use the destination domain or IP, matching rule, and actual policy to assess the result. Record the test destination and compare results before and after the change; do not rely only on whether a webpage opens.
To test a domain exception, for example, check both an exception subdomain and a regular subdomain. To test FINAL, choose a destination that clearly does not match any earlier condition. If you use your own test service, common HTTPS and HTTP ports are 443 and 80, respectively; the domain-suffix rules in this guide do not distinguish traffic by either port.
A connection failure alone does not prove that a rule failed. A PROXY match may use an unavailable proxy path, a DIRECT match may be unreachable on the local network, or a REJECT match may block the request—all can produce similar page errors. Verify in this order: “Did the expected condition match? → Was the expected policy applied? → Is that path reachable?” Do not infer the rule result from the page error.
Common questions: Why did the rules make no difference?
I changed the rules. Why does all traffic still use the proxy?
First, check Home → Global Routing to see whether Proxy is selected, then confirm the active file in Config. If Config is selected, review the rules from the top for an overly broad condition that matches first, or a FINAL rule placed above an exception.
Why doesn't a DIRECT rule lower down override an earlier PROXY rule?
Later rules do not override earlier ones. Move the more specific DIRECT condition above the PROXY condition that covers it, save, and start a new connection. Also make sure you changed the rule order, not just a display name in the list.
I added IP-CIDR, but domain traffic doesn't match. Why?
Check whether the actual destination IP falls within the range and whether no-resolve is in use. A domain may return multiple addresses or use IPv6; an IPv4 IP-CIDR example will not match IPv6. If your goal is to route by domain, use a clearly defined domain condition instead.
My custom rules disappeared after an update. What should I do?
In Config, first check whether the update affected a remote configuration file or another item, then compare it with your backup. A server list in a subscription and a configuration file's rules are separate data. Keep a separate copy of local changes; after restoring them, confirm which file is active to avoid repeatedly editing a file that remote updates can overwrite.
Why does the connection turn back on after I turn it off?
Check the conditions under Settings → On Demand. On Demand controls when a connection is established; it does not replace the rule-by-rule matching in [Rule]. Check the connection state first, then Global Routing and the rules, so you do not confuse two separate behaviors.
Keep a minimal set of changes that clearly serves its purpose: exceptions first, broad conditions later, and FINAL at the end. For each test, record the routing mode, active file, destination, and matching policy. More rules do not automatically improve accuracy; maintenance is easier when you can explain what each rule covers and why it is in that position. For more interface and connection terminology, see the Glossary; for persistent issues, follow the Troubleshooting steps.