This guide is for users who have already imported their own configuration into Shadowrocket and want to route only a few websites through a proxy. Add the target domains as DOMAIN-SUFFIX rules, keep FINAL,DIRECT at the end, and set Global Routing to Config. The sections below cover the minimal rule set, editing steps, connection checks, and common issues. Example domains illustrate syntax only; they do not provide connection services.
1. Define the scope of whitelist routing
Here, a “whitelist” means a list of proxy destinations: listed domains use PROXY, while all other requests use DIRECT. This is not an access-control list and does not block other websites from connecting. DIRECT means connecting to the destination directly; it does not turn Shadowrocket off. Connections may still pass through the local tunnel and rule processing.
For the rules to take effect, go to Home → Global Routing and select Config. Proxy and Direct cannot be used to verify this domain-based configuration. Scene is for scene-based routing and is not the basis for this check. Select Config before editing the rules so a change in routing mode is not mistaken for a rule taking effect.
Rules are checked in order. When a rule matches, its policy is applied and subsequent ordinary matching rules are not checked. If an earlier DIRECT rule already covers a destination, a new proxy rule may never be reached. To configure whitelist routing, check both the rules and their order—not just whether a domain appears in the file.
2. Create a minimal rule set with DOMAIN-SUFFIX and FINAL,DIRECT
Here is a minimal example of the rules section. example.com and example.net are illustrative domains; replace them with the domains you want to route. Existing configurations usually contain other sections. This example shows only [Rule] and should not replace a complete connection configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECTDOMAIN-SUFFIX,example.com,PROXY matches example.com and subdomains such as www.example.com and assets.example.com. It does not match arbitrary strings containing the domain: notexample.com and example.com.other.test are not matches. Enter only the domain as the rule parameter—no https://, path, query string, or port.
FINAL,DIRECT catches requests that did not match earlier rules, so it must come after every specific rule you want evaluated. If it appears first, the domain rules below it will not work as intended. PROXY is not a server address; it is a proxy policy. Before using it, make sure a server you already have is available in Home and that the configuration routes outbound traffic as expected.
Takeaway: start with the smallest rule set
For the first test, use one target domain and the fallback rule. Confirm one reproducible proxy match and one direct match before adding more domains.
3. Edit and enable the configuration in Config
Before editing, note the server selected in Home, the Global Routing mode, and the file currently in use in Config. Make a copy before changing the configuration so you can roll back easily. If the original file is maintained at a remote URL, keep a local copy; a later remote update may overwrite your changes.
-
Keep a copy of the original configuration
In Config, find the file currently in use and use the file actions to save a copy or export a backup. Make sure the copy is easy to identify before editing. A server subscription update is not a backup of your rules file.
-
Edit the rules section
In Config, open the text editor for the file you want to change and find the existing
[Rule]section. Add the target DOMAIN-SUFFIX rules there; do not create a second section with the same name. Separate fields in each rule with English commas. -
Check the fallback rule
Check the order of the entire rules section and move
FINAL,DIRECTto the end. To ensure that only listed domains use the proxy, also check existing GEOIP and IP-CIDR rules, rule-set references, and other proxy rules that could expand the scope. -
Select the file
After saving, return to Config and make sure the file you just edited is selected—not a remote file with a similar name. Saving a file and selecting it are separate steps; confirm both.
-
Enable Config
Go to
Home → Global Routing → Config, select a server you already have, and connect. Then make a new test request. If an existing connection is being reused, disconnect and reconnect, then reopen the test page.
If the connection turns back on after you switch it off manually, check the existing settings under Settings → On Demand. On Demand controls when connections are made; it does not define which website domains use the proxy. To make the test reproducible, note the original settings, temporarily disable relevant automatic connection conditions, and restore them when testing is complete.
4. Handle subdomain exceptions and website resources
If most of a domain should use the proxy but a specific subdomain must connect directly, put the more specific exception before the broader suffix rule. For example, to send only status.example.com DIRECT, use the order below. DOMAIN matches that exact hostname and does not automatically include its subdomains.
[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTA website does not necessarily use just one domain. Its main page, login API, images, fonts, or video may come from different hosts. Adding only the main domain for the page may leave text working while images fail to load, or let the page open while login fails. Check the actual hostname of each failed request and decide whether to add it to the list. Do not route all traffic through the proxy to compensate for a missing rule.
- Subdomains under the same domain:
cdn.example.comis already covered byDOMAIN-SUFFIX,example.com,PROXY; there is no need to add the same policy again. - Separate resource domains: If the page relies on
static.example.net, you can start with the exact matchDOMAIN,static.example.net,PROXY, then decide whether to cover the entire suffix based on your needs. - Direct IP connections: DOMAIN-SUFFIX alone cannot guarantee a match. IP-CIDR matches address ranges, while GEOIP routes by the region associated with an address. Neither is a substitute for a domain-suffix match.
- URL paths:
example.com/accountandexample.com/newshave the same hostname. A domain rule cannot route just one of these paths through the proxy.
Be careful when adding IP-CIDR rules because IP addresses can be shared by multiple domains. Routing an address through the proxy may affect requests to domains that are not on your list. For a “specific websites only” setup, start with the actual hostnames and add address rules only when you understand their scope and impact.
5. Verify rule matches instead of checking only whether a page loads
A page loading only shows that one route worked; it does not prove that it used PROXY. A page failing to load does not by itself mean the rule is wrong. Check the target host, matched rule, and final policy in Shadowrocket’s connection records or logs. Inspect a newly established connection rather than relying only on a server latency test.
- Choose one real website on your list and one off-list website that is currently reachable directly on your network. Note the full hostname for each. Example domains illustrate syntax only and are not substitutes for your own test targets.
- After connecting in Config mode, revisit the website on your list. Confirm that the target matches the expected DOMAIN-SUFFIX or DOMAIN rule and that the policy is PROXY. Then check which proxy outbound was ultimately used.
- Visit a website that is not on your list. Check whether FINAL catches its request and whether the policy is DIRECT. If another rule matches, review the remaining entries in Config.
- Check the records for the main page and any failed resources separately. Seeing both PROXY and DIRECT on the same page is not necessarily a problem; what matters is whether each host follows the list.
- Change one thing at a time, reconnect, and repeat the same tests. Record the target, matched rule, and result before and after each change so you can identify which edit made a difference.
If domain resolution fails, a connection may never be established. An app’s built-in encrypted DNS or requests made directly to an IP address can also affect which domain information is available. Do not change several DNS settings at once while trying to fix a domain rule. Keep the current settings and check the resolution result first; troubleshoot DNS separately if needed. For an existing long-lived connection, reconnect before checking the new records.
6. Distinguish rule issues from connection issues
When something goes wrong, check two things: first, whether the request matched the expected rule; second, whether the selected outbound could establish a connection. The two messages below are examples of raw network errors. They may not appear in exactly the same form in every interface; use the recorded destination and outbound direction to diagnose them.
Error: Connection timed out
Cause: The connection did not complete before the timeout. This can happen while connecting to the proxy server or to the destination website; the message alone does not mean DOMAIN-SUFFIX is invalid.
What to do: Check the matched policy first. If it is PROXY, test connectivity to a server you already have and check access to the same destination to distinguish an outbound proxy issue from an unreachable website.
Error: Connection refused
Cause: The remote end refused the connection. Common causes include no service listening on the destination port or a mismatch between the server address, port, and actual service.
What to do: First determine whether the error refers to the proxy server or the website. Then check the address and port in your existing configuration with your service provider. Do not assume that the website’s HTTPS port 443 is also the proxy server port.
- All websites use the proxy: Check whether Global Routing is still set to Proxy. Then look for broader proxy rules in the configuration or a final rule that still reads
FINAL,PROXY. - A website on the list still connects directly: Check whether a different configuration file is in use, whether an earlier DIRECT rule matches, and whether the domain parameter mistakenly includes a protocol prefix or path.
- Only some content fails: Check the hostname of the failed resource. If it correctly matches PROXY, troubleshoot the proxy connection instead of repeatedly adding the same main-domain rule.
- Changes disappear after a refresh: Check whether you updated a remote Config or a server subscription. They maintain different content. Keep custom rules in a local copy and check for differences after updating.
Takeaway: use the match record to choose your next step
If the wrong rule matched, fix the rule or its order. If the right rule matched but the connection failed, troubleshoot the corresponding outbound. Keeping these issues separate helps preserve the intended setup: listed domains use the proxy, and everything else connects directly.
Keep a verified local configuration and a fixed set of test targets both on and off your list. Repeat the same checks whenever you add a website, adjust a subscription, or update a remote configuration. The Shadowrocket app purchase and connection services are separate; this guide assumes you already have your own service provider and configuration.