Shadowrocket Rules: Route Specific Websites Through a Proxy

Check Config and the default server first

Shadowrocket’s connection toggle, server selection, and routing rules are separate settings. Turning on the connection only enables the connection; domain-based routing also depends on Global Routing on the Home screen. This guide uses Config mode, where the rules in the active config determine how traffic is routed.

Before you begin, make sure your existing server connects. On Home, tap the selection circle beside the server you want in the server list to set it as the default, then run Connectivity Test. This guide uses the built-in PROXY policy. If the existing config routes rules to a custom policy group, the server selected in that group also affects the result, so checking only the default server is not enough.

Minimal rules: proxy selected domains, send everything else direct

Separate rule fields with commas. For DOMAIN-SUFFIX, enter the rule type, domain suffix, and target policy in that order. Enter only the hostname as the domain—no scheme, path, port, or wildcard. The snippet below is for the rules section, not a complete config with DNS and other settings.

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

Merge this section into the existing [Rule] section of your config; don’t create multiple sections with the same name. If the config already has rules, back it up first and check whether any existing rules will match earlier. To proxy only selected websites, remove broad rules that send other domains through a proxy, and make sure any old catch-all rule isn’t left in the middle.

• DOMAIN-SUFFIX,example.com,PROXY matches example.com itself and subdomains such as www.example.com and api.example.com.
• It does not match notexample.com or example.com.other.test, because neither hostname has the specified domain suffix.
• FINAL,DIRECT has no match-value field; it sends connections not matched earlier to DIRECT. Don’t write it in the three-field format.

Here, “everything else goes direct” means connections handled by this rules section that didn’t match an earlier rule. It doesn’t mean every system connection on the device will necessarily appear in the request log. Nor does it mean DNS queries always follow the exact same route as web connections; check DNS separately in the active config.

DOMAIN-KEYWORD and rule order

DOMAIN-KEYWORD checks whether a domain contains the specified text. Use it when you really need to cover multiple domains by keyword, but note that it has a wider scope than suffix matching. If you know a website’s main domain, prefer DOMAIN-SUFFIX to avoid proxying unrelated domains that happen to contain the same characters.

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

The second rule above matches connections whose domain contains media-example. It does not search page titles, page text, or full URLs. Don’t enter example.com/video to match a directory on a website; domain rules can’t distinguish pages on the same host by URL path.

Rules are checked from top to bottom. The first match determines the policy; Shadowrocket won’t automatically choose a later rule because it “looks more specific.” For example, to send local.example.com direct while proxying other domains with the same suffix, put the exact-domain rule before the suffix rule:

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

Save and enable the config on iPhone or iPad

These steps start with an existing, working config. Keep a copy of the original, then edit a local copy; don’t overwrite your only working file. If you download or update a remote config later, it may overwrite local changes, so distinguish between updating the server list and replacing the rule config.

1. Back up the config

   Open Config and check which file is selected. Use that file’s action menu to keep a copy, and note the original filename so you can switch back if anything goes wrong.

2. Edit the rules

   In Config, open the copy’s file action menu and choose Edit Plain Text. Find [Rule] and place the domain rules you need before FINAL,DIRECT; keep the other required config sections.

3. Save and select

   Save the file and return to Config, then select the local config you just edited. Make sure the selection indicator is on that file, not the original remote config.

4. Switch modes

   Go to Home → Global Routing → Config. Return to Home, confirm the default server, and turn on the connection. If iOS prompts you to authorize the VPN configuration for the first time, follow the system instructions.

5. Reconnect

   Close any test pages already open, then reopen the target. If needed, turn the Shadowrocket connection off and back on so new requests use the saved rules. Existing connections that are still being reused aren’t a reliable basis for testing.

If Settings → On Demand is enabled, manually disconnecting may trigger a reconnect when its conditions are met. Check those conditions before testing; if needed, temporarily disable On Demand and remember to turn it back on afterward. On Demand controls connection triggers; it does not replace domain rules.

Verify rule matches, then add required page domains

Test at least two groups: a target that should use a proxy and another target that isn’t listed in the rules. First, run Connectivity Test on Home to confirm basic connectivity through the default server, then make fresh web requests. A successful test confirms connectivity to that test target only; it doesn’t mean every website will be reachable.

• Check the target hostname: Compare the browser’s current address with the request log to verify the actual hostname. A redirect may send you to a different domain, so don’t rely only on the address you originally entered.
• Check the matched policy: Open the relevant connection in the request log and review the available rule and policy details. A target that should use a proxy should match a domain rule; other test targets should fall through to FINAL,DIRECT.
• Check dependent requests: If the page text appears but images, login, or video fail, check the hostnames of the failed requests. Resources may come from separate domains, which aren’t automatically covered by the main site’s suffix rule.
• Add rules one at a time: Add a rule only for a dependent domain you’ve confirmed needs a proxy, then test again. Don’t add an overly short keyword that could expand the proxy scope.

You can add a second confirmed resource domain using the structure below. static.example.net is an example; replace it with the hostname confirmed in the request log. If only this host needs a proxy, use DOMAIN for an exact domain match instead of proxying the entire parent domain.

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

Domain rules also depend on domain information available from the connection. If an app connects directly to an IP address, a domain rule may have nothing to match. Don’t immediately add a large address range; first confirm the request target, DNS resolution, and whether the connection actually belongs to the website you want to proxy.

GEOIP, IP-CIDR, and subscription updates: what they do and don’t cover

GEOIP matches by IP geolocation, while IP-CIDR matches IPv4 address ranges; neither is a website list. If your goal is to proxy only selected domains, the minimal snippet doesn’t need either rule type. Adding broad address rules near the top can change which connections are covered by later domain rules and fallback rules.

The table helps identify rule types; you don’t need to add every row to your config. In particular, shared server IP addresses may host multiple websites, so proxying an IP range can work against the goal of routing only selected websites. If the domain is known, start with domain rules and add address rules only when you’ve confirmed they’re needed.

• Updating a Subscribe entry on Home usually refreshes the existing server list; it doesn’t necessarily change the [Rule] section in your local config.
• Updating a remote Config file may change its rules. After an update, check the selected file, domain rules, and final FINAL rule again—not just the number of servers.
• After the server list changes, make sure the default server or policy group still points to a working entry. If a rule matches PROXY but the selected proxy target is unavailable, the webpage still won’t load.

Troubleshooting: rules aren’t routing traffic as expected

When you’re done, keep a working copy and note the domains you added. Change one thing at a time: mode first, then rules, then server. Checking in this order helps distinguish an inactive config, an unmatched rule, and a failed proxy connection—without repeatedly replacing the entire config.