Shadowrocket REJECT Rules: How Blocking Works, Rule Order, and Limitations

At a glance

In Shadowrocket, REJECT is a request-handling policy, not a webpage element filter. This guide is for users with a working configuration who want to add local blocking rules. First distinguish match conditions from policies, then check rule order in Config mode, and finally compare behavior with a single rule enabled and disabled to catch false positives. Examples use illustrative domains and documentation-only IP addresses; replace them with actual requests. They are not ready-to-use blocklists.

What REJECT does: blocks matching requests

REJECT blocks requests that match the policy; it does not choose a proxy server for them. The first part of a rule defines the match condition, and the last part specifies what happens. For example, in DOMAIN,ads.example.com,REJECT, DOMAIN is the rule type, ads.example.com is the match value, and REJECT is the action taken when a request matches. Do not enter REJECT in a server address or port field.

Request enters the tunnel Match details are collected Rules are checked in order REJECT policy matches Request forwarding stops

Rules only apply to traffic that enters the relevant routing flow. To test the rules in this guide against the active configuration, use Config under Home → Global Routing. Proxy and Direct are global routing modes, not equivalent ways to test a configured REJECT rule. For Scene, check the settings for the selected scene. If a request does not pass through Shadowrocket, changing REJECT in the configuration will have no effect on it.

DIRECT: Sends the request over a direct connection; it does not block the connection.
PROXY: Sends the request to the corresponding proxy policy; whether it works depends on the current configuration and server.
REJECT: Blocks the request. No proxy outbound is needed for this rule.

Writing rules: start with an exact domain

Start with an exact DOMAIN match, then broaden it to DOMAIN-SUFFIX or DOMAIN-KEYWORD only if needed. The examples below show the syntax used in a configuration file’s [Rule] section. They illustrate three different match scopes. When troubleshooting, enable only the rule you need first; overlapping scopes make it harder to tell which rule is taking effect.

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,tracker.example.net,REJECT
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECT

Domain conditions and scope

DOMAIN: ads.example.com,REJECT: Matches only this exact domain.
DOMAIN-SUFFIX: tracker.example.net,REJECT: Matches this domain and its subdomains.
DOMAIN-KEYWORD: telemetry,REJECT: Matches requests whose domain contains this keyword.

Do not include https://, page paths, or query parameters in a domain condition.

Address conditions and fallback rules

IP-CIDR: 192.0.2.7/32,REJECT: Matches a single IPv4 address.
GEOIP: CN,DIRECT: Matches based on the region returned by the IP geolocation database.
FINAL: DIRECT: Handles requests that did not match any preceding rule.

Address rules depend on having usable destination IP information and cannot replace exact domain rules.

Domain rules match hostnames, not full URLs. For https://ads.example.com/banner?id=1, the domain rule checks ads.example.com, not /banner or id=1. Putting the full URL in DOMAIN-SUFFIX will not block just that page.

FINAL,DIRECT in this example is only here to show a complete rule list. It sends unmatched traffic directly and should not replace your existing FINAL policy. When merging the example into an existing configuration, add only the REJECT rules you need and keep the existing fallback behavior and valid policy names.

Rule order: exceptions first, broader matches later

Regular rules are checked from top to bottom, and a request uses the policy from the first rule that matches. A domain may match both an exact-domain rule and a suffix rule; Shadowrocket does not automatically choose the one that looks more specific. Put allowed exceptions before broad blocking rules, and place FINAL after the regular rules.

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

Request to login.example.com: The first rule matches, so the request uses DIRECT. The suffix REJECT rule below it is not checked.
Request to ads.example.com: The first rule does not match, but the second one does, so the request uses REJECT.
Request to example.com: The domain itself is also covered by the second rule, so the request is blocked too.
Request to example.org: Neither of the first two rules matches, so FINAL,DIRECT applies.

Takeaway: move exceptions up before broadening the block

If you need to keep a login domain accessible, move its allow rule above the suffix REJECT rule, then test both login and the rest of the service. If you reverse their order, the request will hit the broader rule first and the exact exception will have no effect, even though it remains in the configuration.

If a rule appears ineffective, first check for earlier matching conditions. For example, if DOMAIN-SUFFIX,example.com,DIRECT appears above DOMAIN,ads.example.com,REJECT, the request will still go direct. Fix the order or narrow the earlier condition instead of repeatedly adding the same REJECT rule.

Add and test rules: change one at a time

Copy your current configuration before making changes, and edit the copy. The steps below refer to Home and Config on iPhone / iPad; menus may differ on other platforms. Use a configuration and service you already have. This guide does not provide, sell, or recommend proxy servers or subscriptions.

Open Config, confirm which configuration is active, and keep a copy of it before making changes so you can restore it if needed.
Open the editor for the configuration you want to change and find its rules. If editing the text directly, add rules to the existing [Rule] section; do not create multiple separate sections with the same name.
Add one exact-match rule first, such as DOMAIN,ads.example.com,REJECT. Place it above broader rules that could match the domain, and leave the existing FINAL rule unchanged.
Save and select the edited configuration, then go to Home → Global Routing. Confirm that Config is selected and that the connection is enabled.
Close any existing connection from the target app or page, then make a new request. Note the results for both the target function and any functions that should remain available.
Temporarily remove or disable the rule you just added, then repeat the same request. If behavior changes when the rule is toggled, check whether its match scope is appropriate.

Existing connections and local caches can delay test results. Images already loaded on a page will not disappear when you add REJECT, and an app may reuse an existing connection. Start a new request and compare the results with the rule enabled and disabled. Do not mistake cached content for a rule failure or assume that a one-off network timeout was caused by REJECT.

Limits of blocking: rejecting a domain is not content filtering

REJECT works best for blocking independently identifiable request destinations, not for filtering text or individual elements on a page. If ads, login, and page content share a domain, rejecting that domain may break all of them. For HTTPS requests, DOMAIN rules alone cannot identify a specific URL path. The domain blocking described here does not require HTTPS decryption.

3 types

Domain conditions covered here: DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD

/32

Single IPv4 address prefix; /24 covers 256 addresses

443

Default HTTPS port; domain rules do not distinguish page paths by port

Shared domain: Rejecting an entire service domain may also block page images, account verification, or payment callbacks. Look for a destination you can identify independently first.
Overly broad keywords: DOMAIN-KEYWORD,ad,REJECT matches far more than a particular ad domain. Any regular service domain containing those characters could also match, so it is not a good first test rule.
Shared IP addresses: Multiple websites may use the same CDN address. Blocking an address with IP-CIDR may affect more than the site you initially observed.
Dynamic addresses: A server’s IP may change, leaving a manually recorded address out of date. Conversely, an old address may later be used by other services.
Insufficient match details: If the routing flow has only the destination IP and no domain information to match, a domain rule may not apply. Check the actual request records instead of widening the keyword match.

Takeaway: preserve service availability when destinations cannot be distinguished

If the content you want to block shares a domain with essential services and you cannot identify a separate request destination, do not keep widening DOMAIN-SUFFIX or IP-CIDR rules. Removing a rule that causes collateral blocking is easier to maintain than patching an overly broad condition with more exceptions.

FAQ: false positives, update overwrites, and automatic connections

Start troubleshooting with the active configuration, routing mode, and most recent change. Stop expanding the rule list, keep a reproducible single-rule test, and follow the steps below. The connection status in the app only indicates tunnel status; it does not prove that a particular REJECT rule matched.

Why can I still access a target after adding REJECT?

First, check that Config is selected under Home → Global Routing, then confirm in Config that you have selected the edited file. Look for a preceding DIRECT rule or other condition that matches first. Finally, close the existing connection and make a new request to rule out caching and connection reuse.

Login stopped working after blocking. What exception should I add?

First, remove the REJECT rule you most recently added and confirm that login works again. Then check which domains the login flow actually uses. If the login domain differs from the blocked target, put an exact allow rule above the broader REJECT rule. If they share a domain, domain rules alone cannot reliably distinguish them.

Why did my locally added rules disappear after an update?

First check whether you updated a server subscription in Home or a remote configuration file in Config. Updating the server list and updating a rules file are separate actions; refreshing a remote configuration may replace local edits. Save a copy before updating, then check the rules section and its order afterward and select the configuration you want to use.

Can Settings → On Demand replace rule toggles?

No. On Demand starts a connection when its configured conditions are met; it does not decide whether a particular domain uses DIRECT or REJECT. For testing, first confirm that the tunnel is connected, then check Global Routing and the active configuration. To undo a block, edit the relevant rule.

Keep a record of why each rule was changed and how to revert it. Handle one target at a time and note its actual domain, the rule type used, and any service functions that must remain available. If your configuration comes from a remote source, recheck local changes after each refresh. This helps separate whether the blocking scope is correct from whether the connection is working, instead of blaming every network issue on blocking rules.