Shadowrocket Proxy for Specific Websites: Set Up DOMAIN-SUFFIX Rules

1. Define the scope: route by domain, not by URL

Shadowrocket’s DOMAIN-SUFFIX matches domain suffixes. Enter example.com to match the domain itself and subdomains such as www.example.com and api.example.com. It does not search for text in the browser’s address bar or depend on the page title.

To include a whole site and its subdomains, use DOMAIN-SUFFIX. To proxy only one specific hostname, use DOMAIN. Do not include https://, a path, query parameters, or a port in the domain field. For example, when visiting https://example.com:443/account, enter only example.com as the domain.

The example domains are for illustrating syntax only; they are not working proxy services. Rules determine which policy handles a request. They do not create connection details or restore an unavailable proxy connection.

2. Back up first, then add minimal rules in Config

Before you begin, check Home to make sure you have a working proxy configuration. If your connection details come from a subscription you already use, update it if needed, then confirm that the selected proxy connects successfully. Editing rules and updating a subscription are separate tasks: rules change how requests are routed, while subscription updates usually refresh connection details.

1. Keep the original configuration. In Config, use the configuration controls to make a copy or export a backup. Note which configuration is currently in use so you can restore it if needed.
2. Open the configuration you want to edit. In Config, open its editor and find the rules section. If you are editing the text, locate [Rule].
3. Review existing rules. Check for existing FINAL rules, broad domain rules, or rules that point to other policies. Do not simply append the new rules after an existing fallback rule.
4. Save and enable. Save your changes, then confirm in Config that the edited configuration is enabled—not another file with a similar name.

This minimal example needs only two rules. The snippet below is a rules section, not a complete connection configuration. Add it to the rules section of your existing configuration; do not replace the entire file with it.

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

The first rule sends example.com and its subdomains to PROXY. The last rule sends requests that did not match any earlier rule to DIRECT. PROXY uses the currently selected proxy; DIRECT connects to the destination directly. If your configuration uses custom policy groups, verify their names and available options. Do not use a rule name that does not exist.

3. Set Global Routing to Config to apply these rules

Return to Home, open Global Routing, select Config, and then connect. This setting determines the overall routing mode: selecting Proxy does not mean “proxy only the sites in the rules,” and selecting Direct will not apply the specific-site proxy rules in this guide.

Settings → On Demand controls when a connection is established automatically; it is not where you edit a list of websites. Even with On Demand configured, check the active configuration, Global Routing setting, and selected proxy. Automatic connection and traffic routing after connection are separate settings.

• The target website should use a proxy: check that Global Routing is set to Config.
• The target rule is saved: confirm that Config has the edited configuration enabled.
• The rule matches PROXY: check that the currently selected proxy on Home is working.

4. Put exceptions first and FINAL last

Rules are evaluated in order, and the policy for the first match is applied. Suppose you want all of example.com to use a proxy, except assets.example.com, which must connect directly. Put the more specific exception before the broader suffix rule. Otherwise, the asset hostname will match the suffix rule first, and the later exception will never take effect.

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

Also check for existing GEOIP and IP-CIDR rules. These match IP ranges or geographic locations, not website domain lists. IP-based rules and DNS settings can also affect matching. For strict “proxy listed domains, connect directly to everything else” routing, review every existing rule that could send traffic through a proxy—not just the final FINAL,DIRECT rule.

5. Test three types of requests; latency tests do not verify routing

After saving, reconnect and have the test page make a new request. The browser may reuse existing connections, and cached pages may not generate the new request you expect when refreshed. Try closing the tab and reopening it, then check the app’s connection log for the destination hostname and policy used.

The table shows expected results for the example configuration; it is not a report of tests performed on the example domains. For your own checks, use domains you need to access. A latency test can help assess the selected proxy connection, but it cannot show which rule handled a particular web request. Verify routing using the request’s hostname, matching rule, and policy in the connection log.

A webpage often connects to more than one domain. The main content may come from the primary site, while login, images, scripts, or media load from other domains. If only images fail to load, check the hostname used by the failed request before adding a rule. Do not switch all traffic to Proxy just because one resource failed.

1. Record the failed resource’s full hostname; do not use the page title as a rule target.
2. Decide whether to match only this hostname or cover all subdomains under its domain.
3. Choose DOMAIN or DOMAIN-SUFFIX, and place the new rule before FINAL.
4. Send the request again, confirm the policy changed, then check whether the resource loads.

6. If the rule matches but access fails, troubleshoot the connection separately

“Wrong policy” and “correct policy, but connection failed” are different problems. First confirm whether the request matched the expected rule. If it matched PROXY, check the specific connection error. The messages below are examples of English text that may appear in connection errors; refer to the in-app log for the actual details.

If the same destination fails with DIRECT but works with PROXY, that only shows that the two connection paths behave differently. It does not mean every website needs a proxy. If both paths fail, check domain resolution, the destination service, and your network environment rather than repeatedly adding duplicate rules.

Keep the same final check sequence: enable the correct configuration, select Config, verify match scope and rule order, check the request policy, then troubleshoot connection errors. This helps separate configuration issues from network issues. Change one variable at a time so you can tell what made a difference.