For users with an existing, working server who want to send only selected websites through PROXY. Set Global Routing to Config, then add domain rules to [Rule] in the active configuration, and use FINAL,DIRECT for all other requests. This guide covers expected matches, rule order, and verification steps. Example domains illustrate syntax only and are not service recommendations.
1. Set Global Routing to Config
Shadowrocket is a paid Apple-platform app available through the App Store, primarily for iPhone and iPad. The developer is Shadow Launch Technology Limited. Refer to the App Store listing for system requirements. This guide assumes you already have a service provider and working connection details; it does not cover choosing a service. Buying the app and obtaining a connection service are separate things.
Rules alone won't produce the result you want if the routing mode is wrong. Go to Home → Global Routing and confirm that Config is selected. Config here means requests are handled according to the rules in the configuration file; don't confuse it with the Config tab at the bottom, which is used to manage files.
Config
RecommendedUses the rules in the active configuration to choose a policy. The domain rules and FINAL,DIRECT in this guide work in this mode.
Best for: Sending only selected websites through PROXY and connecting directly to everything else.
Proxy
Sends intercepted traffic through the proxy without applying the individual routing rules in this guide. Switching to this mode briefly can help determine whether a problem is caused by rule matching, but it does not verify that routing rules work.
Best for: Briefly checking whether the selected server can reach a destination.
Direct
Connects intercepted traffic directly. A PROXY rule in the configuration won't override this mode.
Best for: Comparing direct access with the device's current network.
Scene in Global Routing lets you switch modes based on a scenario; it isn't the same as the Config mode used throughout this guide. Keep the mode fixed during initial testing to avoid changes to routing results. Settings → On Demand manages connections that start or stop under specified conditions; it does not decide whether a domain uses PROXY.
2. Minimal rule set: domains first, FINAL last
This is a rule section, not a complete configuration file with all settings. Merge it into [Rule] in your existing configuration. If the file already has this section, don't add the section header again. Keep a copy of the original before making changes, and take care not to overwrite DNS or other settings.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECTThe first domain rule matches example.com and its subdomains, such as www.example.com and static.example.com. The second rule handles another domain family. Requests that match neither rule fall through to FINAL,DIRECT. Replace the example domains with the domains you actually need, keeping the English commas and policy keywords.
3. When to use DOMAIN-SUFFIX vs. DOMAIN-KEYWORD
For website-based routing, start with DOMAIN-SUFFIX for precise domain-boundary matching. Use DOMAIN when you need to match one fully qualified hostname. Use DOMAIN-KEYWORD only when you specifically want substring matching. A keyword match doesn't identify a site's ownership, so unrelated domains with similar names may also match.
Match at the domain boundary
- DOMAIN
- www.example.com,PROXY
- DOMAIN-SUFFIX
- example.com,PROXY
- FINAL
- DIRECT
DOMAIN matches only the specified hostname; DOMAIN-SUFFIX matches both the root domain and its subdomains.
Match by substring
- DOMAIN-KEYWORD
- example,PROXY
- Matches
- myexample.org
- FINAL
- DIRECT
Keyword matching is broader. myexample.org above also contains example, but it isn't part of example.com.
Enter only a domain or keyword as the rule's match value, not a full URL. For example, example.com is a domain, while example.com/account includes a path and shouldn't be used with DOMAIN-SUFFIX. Domain rules also can't route only a site's login page through PROXY while sending its other pages direct.
- Don't include a protocol prefix; leave
https://out of the domain field. - Don't add a wildcard such as
*.example.com; DOMAIN-SUFFIX already matches subdomains. - Don't include a port in the domain. For example, even if a website uses port 443, the match value is still
example.com. - A website may use separate domains for images, login, or API requests. Add rules based on actual requests rather than broadening the keyword match unnecessarily.
4. Rules are evaluated from top to bottom: put exceptions first
Rules don't automatically prioritize the most specific match. For a given request, the first matching rule determines the policy; later rules won't override it. To send most requests for example.com through PROXY but connect directly to status.example.com, put the hostname exception first.
[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT| Domain to match | First matching rule | Result |
|---|---|---|
status.example.com | DOMAIN exact-match exception | DIRECT |
www.example.com | DOMAIN-SUFFIX | PROXY |
myexample.org | DOMAIN-KEYWORD | PROXY |
example.org | DOMAIN-KEYWORD | PROXY |
example.net | FINAL | DIRECT |
This table shows the expected results based on the rules above; it isn't a network speed test. It also shows how easily keyword matching can reach beyond what you intended: example.org contains example too. If you only need the example.com domain family, remove DOMAIN-KEYWORD. There's no need to keep it just to demonstrate the rule type.
5. Save, enable, and verify in Config
Editing a file doesn't mean it's being used for the current connection. Follow these steps in order, changing one set of rules at a time. Test a simple domain first, then add exceptions and keywords. Updating a subscription doesn't mean local Config rules have been saved or enabled; check the server list and configuration file separately.
-
Back up the original file
Open Config, find the configuration you're currently using, and save a copy before editing. Make sure you'll be editing a file you can control locally, so a remote configuration refresh won't overwrite your changes.
-
Edit the rule section
In Config, open the target file for editing and find [Rule]. Add the domain rules, put exceptions first, leave FINAL,DIRECT at the end, and save.
-
Enable the target configuration
Return to the file list in Config and confirm the file you just saved is selected. Go to Home → Global Routing and choose Config, not Proxy or Direct.
-
Check the server
On Home, check which server is selected and connect. If an existing connection is still open, reconnect before testing so the old connection doesn't affect the results.
-
Check new requests
Visit one matching domain and one unmatched domain. In the request log, check the destination hostname, matching rule, and connection policy. The expected policies are PROXY and DIRECT, respectively.
Don't verify by checking only whether a page loads. The same page may display normally over either a direct or proxy connection, and a server latency reading can't show which rule the page used. Check the match details for an actual new request. If the request is reusing an old connection, close the relevant page and visit it again; if needed, reconnect the app before checking.
6. When to investigate GEOIP, IP-CIDR, and DNS
A minimal setup for sending only selected websites through PROXY usually doesn't need GEOIP. GEOIP,CN,DIRECT checks the region associated with the destination IP; it doesn't mean "connect Chinese-language websites directly," nor does it mean every service for a domain is in the same region. A broad IP rule placed before domain rules may determine a request's policy first.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECTThis additional example explicitly sends requests to destinations within 192.168.0.0/16 direct. no-resolve means the domain isn't actively resolved just to match this IP rule; it doesn't disable DNS globally. Since this example already has FINAL,DIRECT, the IP-CIDR rule is usually redundant for the final policy. It's included only to show the syntax and scope of an IP rule.
- The request includes a domain: Check whether DOMAIN or DOMAIN-SUFFIX matches the hostname in the request log. Don't guess the domain from the page title.
- The request shows only an IP: It may not include the information needed for a domain rule, so don't assume DOMAIN-SUFFIX will match. Check the request log and DNS resolution.
- Only part of the page loads: Check for separate resource domains. A main page matching PROXY doesn't mean images or login APIs hosted on another domain will match too.
- Connecting directly to an IP: Domain rules can't identify an IP based only on which website it belongs to. Use IP-CIDR only when an IP rule is needed; don't casually route an entire public address range through PROXY.
7. Common rule mistakes and how to recover
Troubleshoot in this order: is the configuration enabled, does the request match, and is the policy usable? Changing DNS, servers, rules, and On Demand all at once makes it hard to compare results. Restore a clear, minimal three-line rule set first, then add conditions one at a time. This is easier to diagnose than continuing to stack rules.
| Symptom | Check first | What to do |
|---|---|---|
| All new requests use PROXY | Is Global Routing set to Proxy? Is there a broad proxy rule earlier in the list? | Switch back to Config and check the rules before yours and the FINAL rule at the end of the entire [Rule] section. |
| The target domain still uses DIRECT | Active configuration, rule position, and actual request domain | Confirm the right file is enabled, then move the target rule above any rule that might match first. |
| Rules won't load after saving | Commas, field count, and section header | Use English commas. Domain rules have three fields; FINAL rules have two. |
| PROXY matches, but the connection fails | Selected server and its connection details | First make sure the proxy connection works. A rule match doesn't mean the remote connection succeeded. |
| Changes disappear later | Was the configuration edited in a way that lets a remote update overwrite it? | Restore your local backup and manage custom rules in a separate local configuration. |
Will FINAL,DIRECT disconnect the proxy?
No. It sends unmatched requests through DIRECT; it doesn't disconnect the app. Establishing a connection and routing requests are separate matters. On Demand handles connection triggers; rules choose the policy for each request.
Do I need separate domain rules for Shadowsocks and VLESS?
No. Domain rules specify match conditions and the target policy; you don't need a separate set for each server protocol. The selected server configuration determines the connection protocol. After changing servers, confirm the connection works and then verify the same rules again.
How do I undo these rule changes?
In Config, select the copy you saved before making changes. Confirm that Home → Global Routing is still set to the intended mode, then reconnect. Don't just delete FINAL: without a clear fallback, it's harder to check what happens next.