Shadowrocket REJECT Rules: How Domain Blocking Works and Its Limits

1. REJECT Is a Policy, Not a Match Condition

A rule typically describes what to match and then specifies what to do when there is a match. DOMAIN-SUFFIX matches a domain suffix; REJECT rejects the connection. Together, they mean that a matching domain will not use a proxy or direct-connection policy to establish that connection. They do not scan a page and remove individual elements.

To test the rules in this guide, use configuration-based routing in Home → Global Routing → Config, and confirm that the edited configuration is enabled. Routing behavior under Proxy, Direct, and Scene is not equivalent to the Config test conditions described here. Turning on the connection does not mean a particular rule file is being used for matching.

Settings → On Demand controls when the system connects or disconnects the VPN based on conditions; it does not change a domain's policy to REJECT. When troubleshooting, check separately whether the tunnel is connected, the configuration is enabled, and which rule matched the request. Do not treat automatic connection settings as a domain-blocking switch.

2. Correct DOMAIN and DOMAIN-SUFFIX Syntax

The examples below use reserved example domains to illustrate syntax only. Add rules to the configuration's [Rule] section. If the section already exists, edit it rather than creating a duplicate. The domain field must not include a scheme, path, port, or query string. Separate fields with English commas.

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

In this minimal example, account.example.com matches the exact exception first and uses DIRECT; example.com and img.example.com match the suffix rule and use REJECT. notexample.com is not a subdomain of that domain, even though its name ends with a similar string. The final line only illustrates the fallback position; it does not mean you should change your existing FINAL policy to DIRECT.

If you only need to reject metrics.example.com, do not broaden the rule to all of example.com. A single parent domain may serve login, images, payment callbacks, and analytics requests. The broader the suffix, the greater the risk of false positives. Start by testing the target with DOMAIN, then decide whether the actual requests warrant DOMAIN-SUFFIX.

3. Rule Order: Specific Exceptions First, FINAL Last

With standard sequential matching, the first matching rule determines how a request is handled. A more specific rule later in the list does not automatically override a broader rule above it. Adding REJECT does not make blocking work simply because the line exists in the file; check that no earlier condition catches the request first.

GEOIP matches based on an IP address's geographic location, while IP-CIDR matches an address range. Neither identifies domain categories. Blocking an entire shared IP range to fix one domain rule may affect other sites hosted on the same infrastructure. Unless you have a clear need for address-based filtering, check the domain and rule order rather than broadening the IP range.

4. Steps to Add a Rule and Verify the Result

Change one condition at a time so you can link any page changes to the rule. These steps assume you already have your own configuration. If you need a proxy connection, continue using your own service configuration; this guide does not cover finding or recommending services.

1. Keep a recoverable copy. In Config, confirm which configuration is in use, then save a copy or note the original contents. Take particular care to preserve existing policy names, DNS settings, and FINAL. Do not import this minimal example as a complete, ready-to-use configuration.
2. Confirm the actual destination. Check the connection or request log for the destination domain of the failing request. Record the full hostname instead of guessing from the page title; the page itself, its images, and its API requests may use different hosts.
3. Add the smallest rule needed. Add a rule in the form DOMAIN,metrics.example.com,REJECT to the current configuration's [Rule] section, replacing the example domain with the destination you verified. Place it before relevant broad matches and FINAL.
4. Check the test setup. Save the configuration, then confirm the active configuration and Global Routing → Config in Home. Check the connection status as well. If the connection is unstable, troubleshoot the connection first and test the rule afterward.
5. Make a new request. Reopen the page or quit and relaunch the target app to generate a new connection if possible. Check the destination, matched rule, and policy in the relevant log entry. Do not rely solely on whether a particular page element disappears.
6. Revert one change at a time. Remove only the rule you just added, save, and repeat the same action. Check whether the feature works again. If the change had no effect, investigate other requests rather than deleting an entire group of rules.

HTTPS sites commonly use port 443, but DOMAIN,metrics.example.com,REJECT does not limit the match to port 443. This rule matches a domain, not a URL, request method, or port. Do not enter a full address containing :443 in the domain field.

5. Requests and Page Content Outside the Scope of Domain Rules

Domain rules apply to matchable connection destinations; they do not classify page content. The same domain can serve text, images, recommendations, and login APIs, and one connection may carry multiple requests. DOMAIN-SUFFIX alone cannot tell which part of the content should be allowed.

• Rules cannot distinguish paths on the same domain. example.com/news and example.com/banner use the same domain. This rule cannot reject one based only on the path that follows it.
• Cached in-app content is not deleted. Old images or local cache may still appear. Seeing content on the page does not prove that a new request bypassed the rule; check whether a connection was actually made.
• Existing long-lived connections may not be re-evaluated immediately. A connection that was already established may continue after you save the rule. Start a new connection and check the result rather than waiting for the current page to change on its own.
• A direct IP connection may not provide a domain to match. If the only destination visible to the client is an IP address, do not assume DOMAIN-SUFFIX will match. Check the destination details in the log first.
• Traffic that does not enter the current tunnel is not evaluated by this rule. A disconnected tunnel, system routing, and other bypass conditions must be checked separately from the rule itself.

DNS lookup records are not the same as the final connection result. A domain may resolve successfully and the subsequent connection may still be rejected. Conversely, a failed lookup may prevent the connection from reaching the expected rule-checking stage. Track DNS resolution, rule matching, and connection results separately.

6. Troubleshooting Page Errors and Rules That Don't Take Effect

False positives can cause repeated login redirects, blank images, buttons that keep spinning, or verification flows that never finish. These symptoms may indicate a failed dependency request, but they do not prove by themselves that the request should be allowed. Compare the new rule with the actual match log and narrow the scope one rule at a time.

If the issue persists after removing a single rule, continue checking the network, DNS, and server response instead of attributing every failure to REJECT. For basic connectivity checks, see the troubleshooting guide. If you're unsure how Config and Home differ, follow the getting started guide to confirm how to enable a configuration.