Shadowrocket REJECT Rules: How Domain Blocking Works, When to Use It, and Its Limits

At a glance

REJECT is a policy applied when a rule matches, not a page-element selector. For Shadowrocket users who want to block connections to specific domains, this guide covers DOMAIN and DOMAIN-SUFFIX syntax, choosing Global Routing, rule order, and troubleshooting false positives. It assumes you already have your own service provider, subscription, and working configuration. Back up your configuration first, then test with one rule. Avoid importing large lists from unknown sources.

Where REJECT takes effect

A routing rule consists of a match condition and a policy applied when it matches. For example, DOMAIN,ads.example.com,REJECT uses DOMAIN to match an exact domain, ads.example.com as the match value, and REJECT as the policy. The difference from DIRECT is that DIRECT still attempts to connect to the destination directly, while REJECT does not pass the matched connection to the destination through the normal direct or proxy route.

App request Tunnel interception Rule matching Request rejected Request fails

This flow applies only to requests handled by Shadowrocket and evaluated against rules. Whether a domain rule matches depends on whether the connection provides domain information to match against. If the connection record shows only a destination IP with no associated domain, the name in the browser's address bar alone does not guarantee that a DOMAIN rule will match.

REJECT does not rewrite DNS or edit web pages. It does not inspect the structure of an HTTPS response or remove content based on a button's text or an image's position. The browser may show a failed resource, a missing image, or a request error; the specific result depends on the website's own error handling. Do not assume any one page appearance is the guaranteed effect of REJECT.

Basic domain rule syntax

Rules in a configuration file are usually placed in the [Rule] section. The domains below are documentation examples, not a ready-to-use blocklist. In practice, confirm the target name in your own connection records, then add only a rule that matches the intended scope. Do not assume a domain is safe to block just because its name contains ads or track.

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

The first line applies only to ads.example.com; it does not also cover img.ads.example.com. The second line covers metrics.example.net and its subdomains, such as event.metrics.example.net, but does not match notmetrics.example.net as an arbitrary substring. Do not include a protocol prefix, path, query parameters, or port in the domain field.

Exact match

Keyword: DOMAIN
Match value: ads.example.com
Policy: REJECT
When to use it: You have confirmed the purpose of a single host and want to test a narrow scope first.

Start with the full domain to reduce the chance of affecting other hosts used by the same service.

Suffix match

Keyword: DOMAIN-SUFFIX
Match value: metrics.example.net
Policy: REJECT
When to use it: You have confirmed that the domain and its subdomains can all be blocked.

Before using a suffix match, check whether it includes login, image, or API services.

The example's FINAL,DIRECT line shows a complete minimal rule section. It means unmatched traffic uses DIRECT. Existing configurations may use a different final policy. Do not replace your existing FINAL rule just to add REJECT, and do not append the entire example after an existing FINAL rule. Usually, only the target rejection rule needs to change; keep the existing routing structure intact.

Correct: DOMAIN,ads.example.com,REJECT.
Do not enter a URL such as https://ads.example.com/banner; DOMAIN does not match URL paths.
The standard HTTPS port is 443, and the standard HTTP port is 80. That does not mean you should include :443 or :80 in the domain field.
Do not use a suffix rule for the parent domain example.com in place of a rule for one host unless you really intend to block the entire domain scope.

Select Config and check rule order

Adding a rule does not mean the current connection is using it. In Config, confirm you are editing the configuration currently in use, then save it. Return to Home → Global Routing and select Config. Proxy and Direct are global routing options; do not use them to test individual rules in a configuration file. Scene determines routing based on its selected use case. When troubleshooting, check which Scene is active rather than treating it as another name for Config.

Back up: Keep a copy of the original configuration in Config, and note the existing FINAL rule and rules near the target domain.
Add: Place one verified DOMAIN rejection rule before any broad rule that might match first, and make sure it appears before FINAL.
Select: Return to Home, set Global Routing to Config, and confirm the connection toggle is on.
Retry: Close the target page or app, then try again to create a new connection. Reconnect if needed.
Check: Review the request's destination, matched rule, and final policy. If there is no corresponding new record, do not assume the rule is ineffective.

Rules are evaluated in order, and the first matching rule determines the policy. For example, if DOMAIN-SUFFIX,example.com,DIRECT comes before DOMAIN,ads.example.com,REJECT, the latter may never run because the earlier parent-domain rule already matches. GEOIP and IP-CIDR match based on an IP's geographic location and address range, respectively. They are not page classification tools, and their position in the rule order matters too.

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

This order means “reject the specified host first, allow other connections in that domain scope, then apply the fallback.” If your configuration uses rule sets or policy groups, check whether they match the target earlier. Finding a REJECT rule is not enough to finish troubleshooting; the current configuration, routing mode, and actual match record must all agree.

Scope and what may remain on the page

REJECT is best suited to blocking a request host whose purpose is confirmed and that is relatively independent of core functions. A domain that looks like an analytics service is not necessarily free of business dependencies. Some endpoints also handle session initialization, feature flags, or resource signing. Blocking one may do more than stop analytics—it could prevent the app from proceeding.

Request scenario	What REJECT can do	What to watch for
Dedicated resource host	Reject connections to the matching host	First confirm that the host does not deliver resources needed by the service.
Different paths on the same domain	A domain rule affects relevant connections to the whole host	You cannot block `/banner` while allowing `/login` on the same host.
Content embedded in a response	A domain rule cannot remove part of a response	Images or text already included in the response will not be removed automatically.
Locally cached resources	Affects only future requests that match the rule	A cache hit may not trigger a new connection to the destination.
Shared CDN address	An IP rule can affect connections to that address	The same IP may host unrelated domains, making the impact of a false positive broader.

Decision: start with a single host, then decide whether to expand

Change DOMAIN to DOMAIN-SUFFIX only after confirming that all hosts under the suffix can be blocked. If the target content shares a host with login or page content, do not broaden the domain scope or switch to a wider IP range just to clear the page.

HTTPS-encrypted content does not become plaintext that can be filtered piece by piece just because REJECT is configured. This guide's domain rules do not require HTTPS Decryption or a decryption certificate. Removing a specific page element is a content-layer task; success or failure of a connection-layer rule is not a substitute for that assessment.

Test with a new connection and keep a rollback path

Test against one confirmed, real request—not by opening a documentation example domain and expecting a particular result. First record the behavior before adding the rule. Then add one rule, make a new request, and check whether it matched. Change only one variable per test so you can tell whether the cause is rule order, caching, connection reuse, or a change at the destination.

Establish a baseline: Perform the target action with the original configuration. Note the time and domain, and whether essential functions such as login, images, and playback work.
Test one rule: Add an exact DOMAIN rule, save it, and confirm the active configuration. Do not change the service, protocol, and DNS settings at the same time.
Make a new request: Reopen the target app or page. A refresh may still use cached content, and an existing long-lived connection may not be evaluated against the rules again immediately.
Check the evidence: See whether the new connection record shows the expected destination and REJECT. If it points to a different host, check the request chain first; do not add guessed domains in bulk.
Test rollback: Remove or comment out the rule you just added, then repeat the same action. Treat the rule as a primary suspect only if the problem appears and disappears as the rule is added and removed.
Keep a record: Once the rule works, document why it is needed and its scope. After a configuration update, check whether the local change is still in the file currently in use.

If the source of a purchase or configuration is unclear, first distinguish the client app from the connectivity service. Shadowrocket is a closed-source commercial app; buying the app does not include a connection plan. This guide does not provide, sell, or recommend nodes or subscriptions. An existing subscription update also does not guarantee that local REJECT rules will be preserved; check the service information and the updated configuration separately.

Frequently asked questions and recovery

Why can I still see an image after adding a REJECT rule?

First check whether a new connection was made. The page may be using a local cache or loading the same resource from another host. Reopen the page and inspect the request record. If the destination did match REJECT but the image is still there, check whether it is embedded content; do not broaden the suffix scope.

The connection toggle is on. Why are the rules having no effect?

Check in order whether Home → Global Routing is set to Config, whether the active file in Config contains the new rule, and whether the rule comes before FINAL and any other rules that may match first. Then make a new connection. Saving the file will not apply the rule if another configuration is still in use.

Login failed after blocking a connection. Should I delete the entire configuration?

First remove the rule you added most recently, leaving all other settings unchanged. Reconnect and test login again. If it works, narrow the suffix rule to the confirmed host or allow that domain to connect normally. Do not block shared authentication, risk-control, or API domains based on their names alone.

Would switching protocols make REJECT block more completely?

No. It does not add the ability to filter page content. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard concern connection and transport methods; REJECT's scope depends on the match condition, rule order, and current routing. Fix the rules first rather than switching protocols to broaden blocking.

Keep a set of rules that is easy to explain, verify, and roll back. If a feature stops working, undo the most recent change first, then check the match records. When a target cannot be separated onto its own host, respecting the limits of connection-level rules is more likely to preserve normal access than continually expanding the block scope.