Shadowrocket REJECT Rules Explained: What Request Blocking Can and Can’t Do

1. Where REJECT Fits in the Rule Chain

When routing according to a configuration, Shadowrocket matches rules using the information available for each connection. Match conditions and actions are separate: DOMAIN, DOMAIN-SUFFIX, and IP-CIDR determine whether a rule matches, while REJECT at the end determines what happens when it does. REJECT is not a protocol, and it doesn’t require selecting a proxy route to take effect.

This describes the path taken when a REJECT rule matches. A match for DIRECT sends the connection directly; a match for a valid proxy policy in the configuration sends it through that outbound route. Rules are checked from top to bottom. The first match determines the action, so later rules aren’t checked for a “better” result. When troubleshooting, check both whether REJECT is present and whether an earlier rule has already matched the request.

• Check the routing mode first: In Home, check Global Routing → Config so this test uses the rules in the current configuration. Don’t use results from a global Proxy or Direct mode test to judge whether Config rules are working.
• Check the active configuration: In Config, verify which configuration file is enabled. Editing a different, inactive file won’t change the rules currently in use.
• Test a new connection: Existing connections may be reused. After making a change, establish a new connection and try the target page again. This makes the result easier to interpret than simply refreshing the page you already have open.

2. Start with an Exact Domain Rule

Start with DOMAIN to target one hostname, and use DOMAIN-SUFFIX only if you need broader coverage. For example, to reject only metrics.example.com, an exact match won’t also reject www.example.com. By contrast, DOMAIN-SUFFIX,example.com,REJECT covers the root domain and its subdomains, potentially blocking sign-in, images, and APIs too. The domains below illustrate syntax only; they aren’t recommended blocking targets.

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,blocked.example.org,REJECT
FINAL,DIRECT

This is a rule-structure example, not a complete configuration you can use to replace your existing file. Add the rules you need to the existing [Rule] section; don’t create a duplicate section. Keep any other rules and fallback policies your configuration requires. FINAL,DIRECT is shown only to illustrate its position at the end; it doesn’t mean everyone should change their own FINAL action to DIRECT.

Don’t put a full URL in a DOMAIN condition. For example, /banner/image in a page address is a path, not part of the domain; :443 is a port, not part of the hostname. These domain rules can’t distinguish between HTTPS on port 443 and HTTP on port 80 when both services use the same hostname.

3. Check Rule Order When a Rule Doesn’t Block

Rules aren’t automatically reordered to put more specific matches first. Suppose the configuration has DOMAIN-SUFFIX,example.com,DIRECT before DOMAIN,metrics.example.com,REJECT. A request to that subdomain matches the earlier DIRECT rule first. The later, more specific rule never gets a chance to run.

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

The example places the specific rejection rule before the broader direct rule. To allow a particular subdomain, put its allow rule before the corresponding suffix rejection rule. Don’t add overlapping rules and judge the result by page appearance alone; first verify which rule matched the connection and what action it applied.

GEOIP and IP-CIDR match based on the destination IP and shouldn’t replace a verified exact domain condition. Multiple websites can share an IP, so rejecting an address range can affect many more connections. Whether a domain rule can match also depends on whether usable domain information is available for that connection. A connection identified only by its IP won’t necessarily match a DOMAIN rule.

4. Limits: Same-Domain Content, Caching, and Blank Space

REJECT can reject matching connections, but it can’t tell whether a webpage area is article text, an ad slot, or a video player. Suppose www.example.com serves both an article API and a promotional API. A DOMAIN or DOMAIN-SUFFIX rule can’t reject just one path; blocking the domain will affect both. In other words, these domain rules can’t selectively distinguish content served from the same domain.

Under HTTPS, paths and response bodies are encrypted; ordinary domain rules don’t use that content to make matching decisions. Adding more DOMAIN-SUFFIX rules won’t give Shadowrocket the ability to identify page elements. If a browser has already loaded a resource into memory or its local cache, the image may remain visible even after new requests are rejected.

5. Test One Change at a Time and Keep a Way Back

Before testing, save a copy of your working configuration and note the new rule and its original position. Don’t change networks, switch proxies, refresh a subscription, and add a batch of rejection rules all at once. If the page changes, you won’t know which action caused it. The steps below are for users with a working connection who want to test one rejection target.

1. Record a baseline: Keep the same network and configuration, open the target page, and note specific details such as whether you can sign in, images load, and playback works.
2. Identify the target: Find the relevant request in the connection log and check its hostname, matched rule, and action. A page may contact multiple domains; don’t assume a domain can be blocked just because its name looks like an analytics service.
3. Change one rule: Add one exact DOMAIN rule to the [Rule] section of the active configuration in Config. Place it before any broader rule that might match first and before FINAL. Save the change and confirm the configuration is active.
4. Establish a new connection: Reconnect and open the target page again. If needed, close the old tab and test in a new session. Note whether REJECT matched and whether sign-in, images, video, or other features were affected.
5. Compare after undoing the change: Temporarily remove the rule, establish a new connection, and test again. If the problem appears with the rule and goes away when it’s removed, treat the rule as the likely cause.
6. Keep the scope narrow: Keep the rule only after confirming it works without affecting features you need. If more subdomains need to be covered, expand gradually; don’t immediately reject an entire shared domain or IP range.

Server details in a subscription and routing rules in the current Config are separate things. If behavior changes after a subscription update, check the selected connection and active configuration separately rather than assuming the update either replaced or preserved local rules. When updating a configuration from a remote URL, check whether your local changes are still there. Use your backup to restore the configuration; don’t repeatedly overwrite it without first checking the differences.

6. Common Issues and What to Check

Keep a rule only if the target’s new connections actually match REJECT, the features you need still work, and removing the rule restores the previous behavior. REJECT is suited to rejecting clearly defined requests; these domain rules can’t guarantee page-level content cleanup, response filtering, or layout adjustments. For more on the basics, see the user guide; for rule terminology, see the glossary.