Shadowrocket REJECT Rules: How Blocking Works, Rule Order & Limits

1. Where REJECT takes effect: match the target, then apply the policy

Each rule answers two questions: does the request match the condition, and what policy applies if it does? For example, in DOMAIN-SUFFIX,example.com,REJECT, DOMAIN-SUFFIX is the match type, example.com is the match value, and REJECT is the action. Once a rule matches, the connection is refused; a failed connection does not fall through to the next rule.

This flow assumes the target traffic is handled by Shadowrocket. Editing a REJECT rule will not directly change a request's route if the connection is off, traffic bypasses the tunnel, or the current routing mode does not use these rules. Check the connection state, routing mode, configuration, and matching rule—in that order—instead of adding a batch of block rules first.

REJECT affects network requests; it does not remove text, image placeholders, or other content already displayed on a page. A refused request may show up as a failed resource load, a blank image, an app retry, or an error message. The result depends on how the app handles errors, so no single page change is guaranteed across all apps.

2. REJECT rule syntax: use domains first, and IP ranges with care

Use DOMAIN to block one exact hostname and DOMAIN-SUFFIX to cover a domain and its subdomains. Enter the hostname as the match value, without https://, a port, a path, or query parameters. For example, to match the host in https://ads.example.com/banner, enter ads.example.com, not the full URL.

DOMAIN-SUFFIX,example.com,REJECT matches example.com and img.example.com, but not every domain that happens to contain that string. If you only need to block one resource host, do not widen the rule to the entire root domain. Login, image, and API services may use different subdomains under the same root domain.

IP-CIDR matches an IPv4 address or range. /32 represents one IPv4 address; /24 represents a range of 256 addresses. Applying REJECT to a large range on shared infrastructure may affect multiple unrelated domains. Since the IP behind a domain can change, blocking an address based on one lookup is not a reliable way to block that domain over time.

3. Rule order: put specific exceptions first and FINAL last

When traffic is handled by configuration rules, they are checked from top to bottom, and the first match determines the policy. A more specific rule later in the list does not override a broader rule that has already matched. A common mistake is to put a REJECT for an entire domain suffix first, then add an exception for a subdomain below it. That exception never gets a chance to take effect.

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.8/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

In this ordering example, account.example.com matches the first rule and is not checked against the second; img.example.com is blocked by the suffix rule. GEOIP,CN,DIRECT matches using the destination IP's geographic database entry, not the webpage's language. Placing it before REJECT may allow requests that match its conditions.

FINAL is a fallback rule and has no domain match value. FINAL,DIRECT is used here only to complete the example; it does not mean you should change your configuration's final policy to DIRECT. Keep your existing final policy and insert only verified, specific rules in the appropriate place. Do not add a second FINAL to append block rules to the same configuration.

4. Edit and verify rules in Config: add one at a time

The steps below refer to the Home, Config, and Settings interface. The exact editing controls may vary in the current app UI. First, keep a copy of the working configuration, then edit the Config that is currently selected. Do not assume a file is active based on its name, and do not mistake a subscription list refresh for an update to the configuration rules.

1. Check the routing mode. On Home, check the connection status and Global Routing. Select Config to test configuration rules; Proxy and Direct are not modes for verifying rule matches in this guide. If you use Scene, first check the routing settings used by the active scene.
2. Check the active configuration. Open Config and confirm which file is selected. Keep a copy, then find the [Rule] section. If it already exists, edit its entries rather than adding a duplicate structure at the end of the file.
3. Add the smallest possible rule. Choose one exact hostname you know should be rejected. Add a DOMAIN rule before any relevant broad rules, leaving other existing policies unchanged.
4. Save and apply. Confirm that the saved file is still the selected configuration, then apply it as prompted. If you need to reconnect, keep in mind that other network activity may be interrupted.
5. Send the request again. Close and reopen the target page or app to establish a new connection if possible. Note the target domain, matching rule, and policy. If the logs do not show enough detail, a blank page alone is not proof that REJECT matched.
6. Test by reverting one change. Remove the rule you just added, save, and repeat the same test. Compare the results before and after, then decide whether to keep the rule, narrow its scope, or investigate further.

Existing connections, browser cache, and app cache can all make changes look different from what you expect. Start by sending the target request again instead of changing several settings at once. Distinguish between “new request rejected,” “no new request made,” and “request succeeded but the display did not change”—each calls for a different next step.

5. Limits of blocking: shared domains, cache, and shared IPs

Domain rules can route traffic only using the target information they can identify. If the normal API and the content you want to block use the same hostname and differ only by URL path, DOMAIN and DOMAIN-SUFFIX cannot distinguish them. Setting that hostname to REJECT will often block the normal API as well.

• HTTPS paths are not domain match conditions. https://api.example.net/feed and https://api.example.net/banner have the same hostname. Adding /banner to DOMAIN-SUFFIX will not filter by path, and port 443 cannot distinguish these types of traffic either.
• Local content does not generate a request to block. Downloaded resources, offline pages, and content bundled with an app will not disappear immediately when you add a network rule.
• A shared IP does not identify one site precisely. One IP address may serve multiple domains. Prefer a verifiable domain rule; do not reject an entire address range just to cover one resource.
• Connection details may be incomplete. A domain rule cannot match a request made directly to an IP address. Whether domain information is available also depends on how the address is resolved and the connection is made, so check the connection records.
• Server-side resource locations can change. A target may move to another domain or address, or use a different request method. If an old rule no longer matches, check the request target again instead of blindly widening the rule to the entire root domain.

REJECT can refuse connections to clearly identified targets, but it cannot promise to remove all promotional content or preserve page layout after blocking. Switching to protocols such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, or WireGuard does not give DOMAIN-SUFFIX the ability to read and filter webpage content. Outbound protocols and rule matching serve different purposes.

6. Common questions: rules not working, false blocks, and changes after updates

For long-term maintenance, record the target host, reason for each change, and how to revert it. If something is blocked by mistake, restore a working setup first, then investigate the target request. Avoid changing DNS, the outbound protocol, and the entire rule set at once, or it will be hard to tell what changed the result. For further troubleshooting, use the troubleshooting guide to check the active configuration and connection records.

This guide assumes you already have your own provider and subscription, and covers only local rule management. This site does not provide, sell, or recommend nodes, subscriptions, or connection services. A one-time app purchase does not include a connection plan, and adding a REJECT rule does not create a connection configuration.