Shadowrocket Rules for Proxying Specific Websites: DOMAIN-SUFFIX and FINAL,DIRECT

1. Check Config mode and the proxy route first

Check the active mode before editing rules. Home → Global Routing determines how traffic is handled. Editing a Config file alone will not give you the domain-based routing described here if Home is still set to Proxy or Direct. Server details and routing rules are separate: a working server does not mean the active configuration contains the right domain rules.

In these examples, PROXY is a proxy policy, not a server address. Don’t enter this word in the server’s Address field. If you use the default proxy policy, first check on Home that the selected server is available. If your configuration uses a custom policy group, check which option that group currently selects. DIRECT means the connection goes directly to its destination without using a proxy server.

2. Minimal DOMAIN-SUFFIX and FINAL,DIRECT syntax

To proxy example.com and its subdomains while sending other destinations DIRECT, use the snippet below as a starting point for your rules. The domain is an example; replace it with your own target domain. This snippet contains only [Rule], not a complete configuration file.

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

DOMAIN-SUFFIX matches on domain suffix boundaries. The rule above covers example.com, www.example.com, and api.example.com, but not notexample.com just because its name looks similar. Enter the domain itself as the rule parameter—not https://, a port, a path, or query parameters.

• DOMAIN-SUFFIX,example.com,PROXY: Use PROXY when a domain matches this suffix.
• FINAL,DIRECT: Use DIRECT when none of the preceding rules match. This rule takes no domain parameter.
• Separate fields with standard English commas, and put each rule on its own line. Don’t combine multiple rules on one line.
• To proxy only the specific host login.example.com, use DOMAIN,login.example.com,PROXY. This avoids matching the entire domain and its subdomains.

Shadowrocket checks rules in order, and the first match determines the policy for that connection. If you put FINAL,DIRECT before the target domain rules, it catches traffic first and prevents later rules from taking effect. When editing an existing configuration, check for broad rules earlier in the list too—a few lines appended at the end may not be enough.

3. Multiple websites and the limits of DOMAIN-KEYWORD

For multiple unrelated websites, listing rules on separate lines is usually easier to maintain. A page may load login, static asset, and API domains that don’t share the same suffix. Add rules for domains you see in actual requests rather than routing all traffic through a proxy just because part of a page isn’t displaying.

[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN-SUFFIX,example.org,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD doesn’t check whether domains belong to the same website, or require the keyword to appear at a specific domain level. For example, DOMAIN-KEYWORD,example,PROXY could match both example.com and notexample.net. It matches domain names, not page titles, page content, or URL paths. It can’t route just one page on a domain through a proxy.

4. Five steps to save, enable, and verify your rules

After changing rules, confirm that the file is saved, the right configuration is selected, the running mode is correct, and new requests have been made. Existing connections may continue using their original sessions, so an already-open page in your browser can’t tell you whether the new rules are working.

1. Check the route

   On Home, select a server you already have, then use Connectivity Test to check whether it’s reachable. The result only indicates connectivity to the test target; it doesn’t verify the rules for a specific website.

2. Edit the rules

   Go to Config, open the menu for the configuration you plan to use, and select Edit Config. Check the [Rule] section and edit its existing rules—don’t add a second [Rule] section. Put target domain rules before FINAL,DIRECT.

3. Select the configuration

   After saving, return to the Config list and select the file you just edited. Then go to Home → Global Routing and choose Config to avoid using another configuration or running mode.

4. Make new requests

   Reconnect, then visit the target website and a website that isn’t on your list. If needed, close and reopen old pages to reduce the effect of browser caching and persistent connections.

5. Review the request log

   In the in-app request log, check the destination domain, matched rule, and policy for each new connection. The target request should match a domain rule and use PROXY; a non-target request should fall through to FINAL and use DIRECT.

Change one thing at a time when testing. For example, if a website’s home page loads but its images don’t, check the image requests’ domains and policies before adding a rule for an asset domain. Don’t change the server, DNS, and the entire rule set at once, or you won’t know which change affected the result.

5. Handling existing GEOIP, IP-CIDR, and DNS settings

“DIRECT for everything else” works only if other traffic hasn’t already matched a proxy rule. Existing configs may also include GEOIP, IP-CIDR, or remote rule sets. Adding FINAL,DIRECT as the last rule does not override proxy rules above it.

• Check for broad proxy rules: A PROXY rule earlier in the list that covers many addresses may also route connections outside your domain list through a proxy. In a copy of the configuration, first remove rules unrelated to your targets, then restore only the ones you need.
• Handle domains and IP addresses separately: A connection made directly to an IP address may not have a domain for DOMAIN-SUFFIX to match. Use IP-CIDR only when you have a specific need for a fixed address; don’t route an entire shared address through a proxy without careful consideration.
• Understand no-resolve: IP-CIDR,192.0.2.0/24,DIRECT,no-resolve is a syntax example. no-resolve means this IP rule won’t trigger a domain lookup to complete the match; it does not disable DNS for the entire configuration.
• Keep the scope of IP geolocation rules in mind: GEOIP matches IP geolocation rather than individual domain names. It can’t replace a precise list of target domains.

192.0.2.0/24 is a documentation example range, not a real target to copy. For websites with dynamic addresses, shared hosting, or a CDN, domain rules are usually easier to maintain. An IP address from a single lookup may stop working when the address changes, or affect other domains sharing that address.

6. Distinguish rule issues from connection errors

First check whether the request matched the expected rule, then check whether the connection succeeded under that policy. You may see the English-language errors below when diagnosing a connection; the exact wording depends on the in-app log. An error by itself doesn’t prove that a domain rule is incorrect.

If there are no connection errors but every website goes through a proxy, first check whether Home → Global Routing is still set to Proxy and whether broad PROXY rules remain near the start of [Rule]. If only one website routes incorrectly, check the domain used by the actual request instead of relying on the browser’s address bar.

• Target matches FINAL: Check the domain spelling, confirm the right configuration is selected, and check whether you’re connecting directly to an IP address.
• Target matches PROXY but still fails: Check whether the selected route is reachable and whether the website requires other domains to use a different route.
• Non-target matches PROXY: Check whether DOMAIN-KEYWORD is too broad or an earlier proxy rule is matching the request.
• Behavior hasn’t changed after saving: Confirm you edited the active configuration, reconnect, and check a new request.

7. Common questions about routing specific websites