How to Use REJECT Rules in Shadowrocket: Blocking Requests and Understanding Their Limits

What REJECT does: blocks connections, not page content

Shadowrocket rules consist of a matching condition and an action. The condition specifies which connections qualify; the action determines what happens when a rule matches. For example, DOMAIN,blocked.example.com,REJECT means that when the rule evaluation identifies the target domain as that exact name, the connection is rejected instead of being routed according to a later rule.

This flow assumes the traffic is within Shadowrocket’s handling scope and the current routing mode uses the relevant rules. It is not a blanket guarantee for all device communications, nor does it mean every unwanted element on a web page will disappear. An app may retain a loading placeholder, show an error, or retry the failed request.

• PROXY: Sends matching connections through the applicable proxy. The actual exit also depends on the current selection and configuration.
• DIRECT: Connects matching traffic directly to its destination; it does not reject the request.
• REJECT: Blocks matching connections; it does not switch them to a direct connection.

To determine whether a rule worked, check whether the connection matched and was rejected—not whether a blank area remains on the page. Blank spaces, loading indicators, and error messages can all result from failed resource requests; they do not show that REJECT adjusted the page layout.

Check Global Routing first, then review rule order

On Home, check Global Routing. To verify rules in the current configuration, use Config and confirm that the configuration you just edited is enabled. Proxy and Direct are global routing modes, so their results cannot be used to judge whether REJECT rules in the current configuration are working correctly. If you use Scene, also confirm which configuration and routing settings the scene actually uses.

Rules are evaluated in order. The action for the first matching rule is applied; evaluation does not skip ahead to find a “more specific” rule. Put exact exceptions before broader rules, and keep FINAL last. The syntax example below is independent, and all example domains are illustrative. Don’t use it to change the overall outbound policy of an existing configuration.

[Rule]
DOMAIN,allowed.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

With this order, allowed.example.com matches the first line and is not rejected by the second; blocked.example.com can match the second line. If you move the first line below the second, the exact exception no longer takes effect. GEOIP uses location data for the destination IP; it does not refer to the page language or the website operator’s location.

When to use DOMAIN, DOMAIN-SUFFIX, or IP-CIDR

For a known problem domain, start with a narrowly scoped DOMAIN rule. Consider DOMAIN-SUFFIX only after confirming that all subdomains should be rejected. It covers the specified domain and its subdomains; it does not match every domain that happens to contain the same string. Using a main site domain could also affect sign-in, images, and API requests.

Domain rules rely on target domain information being available to the rule evaluator. If an app connects directly to an IP, the domain association is incomplete, or the request switches to another destination, the original domain rule may not match. Check the actual destination in the connection records first; don’t respond to a missed domain match by blocking a large IP range.

• In IPv4, /32 identifies a single address, while /24 covers a range of addresses—a much wider scope.
• A shared IP or CDN address may host multiple sites. Rejecting the IP can affect other legitimate requests too.
• DNS results can change, so blocking one IP seen at a particular time does not necessarily keep covering the domain.
• Don’t include https://, a page path, or query parameters in the domain field of a DOMAIN rule.

What REJECT can block—and what it can’t

Domain-level blocking is easier to scope when an unwanted resource comes from a dedicated domain that serves no essential functions. But if the same domain serves page content, sign-in verification, and other resources, a domain rule can’t distinguish among them by URL path alone. The specific contents of an HTTPS connection also do not automatically become matching criteria just because you add a DOMAIN rule.

If an area still appears on the page, its content may already be embedded in the main document or stored in the app’s local cache. The page may also retain a fixed-height container after a request is blocked. Don’t keep adding rules for the main site and static resource domains just to remove this visual leftover. Rules control where connections go; they don’t hide page elements.

From adding a rule to verifying it: test one rule at a time

Before making changes, save a restorable copy of the original configuration in Config, and note the original Global Routing mode, selected outbound, and test page. If the configuration is managed remotely or updated from a source, check whether a later update could overwrite your local changes. Any services and subscriptions you already use are responsible for their own content; this guide covers testing local rules only.

1. Record a baseline. Before adding REJECT, open the target page and note how sign-in, images, and APIs normally behave. Don’t attribute existing problems to the new rule.
2. Edit the configuration. In Config, open the configuration currently in use and edit it. Add one exact DOMAIN rule in the rules section, above any broader rule that could match first.
3. Confirm it’s active. Save your changes, verify the current configuration, then return to Home and check Global Routing → Config. Make sure you haven’t just saved an inactive copy.
4. Reconnect. If needed, turn the connection toggle on Home off and back on, then have the target app send the request again. This temporarily interrupts the current connection, so avoid doing it during an active task.
5. Check the evidence. Review the connection or request records available in the app and look for the target domain and action at the relevant time. If the details show which rule matched, note that too. Don’t draw conclusions if there’s no record of the target request.
6. Retest functionality. Check the relevant features, such as normal page loading, sign-in, search, and images. Keep the rule only if the target is rejected while essential features continue to work.

Don’t treat faster response times as the only evidence, or assume a single timeout means a rule matched. Resource requests on the same page can vary with caching, sign-in state, and server responses. A reliable diagnosis checks the target request and its actual action, then compares the result after removing the rule.

If a page breaks, roll back the smallest change first

False positives often involve sign-in verification domains, image services, shared APIs, or configuration requests an app needs to start. The visible symptom may be an unresponsive button, content that keeps loading, or repeated sign-in redirects, while the blocked request is actually a background dependency. Undoing the rule you just added is usually a clearer way to identify the cause than adding more “fix” rules.

If the problem persists after removing the rule, restore the full configuration saved before the change. Then check which file is active, the connection status, and whether the target service itself is available. Only narrow the rule further if the problem reliably occurs when that rule is present. If an exception is needed, put the exact rule before the broader REJECT and use the DIRECT or PROXY action the target actually requires; don’t assume it should always be DIRECT.

• Keep a record: Note the rule you added, the steps that reproduce the issue, the target domain, the matching action, and the rollback result. This helps prevent broadening the scope again next time.
• Avoid bulk changes: Changing rule order, DNS, and outbound selection all at once makes it hard to identify the cause of a problem.
• Protect your privacy: Before sharing troubleshooting details, hide account information, tokens in subscription URLs, and other authentication data.