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

REJECT blocks connections, not individual page elements

When an app accesses the network, Shadowrocket checks connections routed through its processing path against your rules. If a rule matches REJECT, Shadowrocket won’t establish a normal outbound connection to the destination using DIRECT or PROXY. “Before a connection is established” refers to the outbound connection to the destination; it doesn’t mean the app hasn’t sent a request, or that no DNS lookup has occurred before the rule is evaluated.

What happens next depends on how the app handles errors: an image may fail to load, a separate analytics request may end, or the app may retry or show a timeout message. REJECT doesn’t generate a normal page for the app or automatically collapse blank areas in a webpage. A request can be rejected while the page appears unchanged.

• DIRECT: Connects directly to the destination; the request is still allowed to access the network.
• PROXY: Routes traffic through the selected proxy policy; it doesn’t block the request.
• REJECT: Blocks matching requests; it doesn’t replace content or reformat a page.

These policies are separate from the proxy protocol in use. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard describe proxy transports or tunneling methods. Switching protocols doesn’t give REJECT the ability to identify content inside an HTTPS page.

What domain and IP rules can match

When the destination domain is available at the matching stage, you can use DOMAIN or DOMAIN-SUFFIX. DOMAIN matches an exact hostname; DOMAIN-SUFFIX matches a domain and its subdomains. If you want to block just one endpoint, start with its exact hostname rather than applying a rule to the entire parent domain.

/32 represents a single IPv4 address, not a broad range. no-resolve prevents an extra DNS lookup just for this IP rule; it doesn’t mean that DNS is disabled for all requests. If an app connects directly to an IP and there’s no usable domain information associated with it, a domain-only rule may not match.

IP rules have limitations too. Multiple domains may share a CDN address, and the same domain may resolve to different addresses depending on region, network, or time. Blocking every IP returned by a lookup may miss new addresses later and affect other services sharing those IPs. GEOIP relies on an IP geolocation database; it doesn’t identify a website’s actual content or operator.

Rules are checked in order; REJECT has no special priority

With Config routing, rules are checked from top to bottom, and the first matching rule determines the policy. REJECT doesn’t automatically override an earlier DIRECT or PROXY rule just because it blocks traffic. Put specific exceptions before broader rules, and keep FINAL at the end of the rules section to handle connections that haven’t matched earlier rules.

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

In this example, which illustrates rule order only, login.example.com matches DIRECT first, metrics.example.com matches REJECT first, and other requests under example.com then match PROXY. Move DOMAIN-SUFFIX to the top, and it will match the first two hostnames before their specific rules can take effect.

Confirm Config is active, then run a minimal test

Having a rule file in Config doesn’t guarantee that current requests are being handled by it. First check Global Routing on Home. Proxy and Direct are overall routing modes; to test rules, explicitly select Config. Scene is a context-based routing mode—seeing Scene selected doesn’t by itself confirm how rules in the current configuration are being applied.

1. Keep a backup. In Config, confirm which configuration is active and save a restorable copy before editing. Don’t overwrite a complete rule set you haven’t reviewed.
2. Add one precise rule. Use the hostname shown in the request log and follow the structure DOMAIN,hostname,REJECT. Here, “hostname” indicates the field; it isn’t a ready-to-paste rule.
3. Confirm the active configuration. Save your changes and make sure the edited configuration is in use. On Home, set Global Routing to Config and confirm the connection is enabled.
4. Trigger a new request. Leave the target page and open it again. If needed, quit and reopen the app. Don’t rely on an image that has already loaded or an old browser tab.
5. Check the log. Find the destination hostname or IP in the request log and check which rule and policy matched. A new request showing REJECT confirms that this test reached the reject path.
6. Test recovery. Temporarily remove the rule you just added, then trigger the same request again. Compare the connection and app behavior before and after removal to confirm the rule caused the change.

Settings → On Demand controls automatic connections based on conditions; it isn’t a REJECT toggle. If the tunnel disconnects during testing, later requests may no longer follow the same processing path. Check the connection status before concluding that a rule has failed. For persistent connections, don’t assume that editing a rule closes existing sessions; make a new connection to test it.

Limitations involving HTTPS, caches, and content on the same domain

Domain and IP rules match connection destinations. Suppose regular content is at https://example.com/article and another type of content is at https://example.com/promo. Both use the same hostname. DOMAIN and DOMAIN-SUFFIX can’t distinguish between those paths; blocking the hostname could also block the article.

A port can hint at the type of traffic, but it can’t precisely identify content. Regular webpages and other HTTPS requests may both use port 443, so blocking the entire port isn’t a selective filter. Even when the destination domain is available, that doesn’t mean the URL path, request body, or response content inside an encrypted connection can be read. REJECT doesn’t decrypt traffic.

• Content is cached: The app may display data from disk or memory without making a new network request for REJECT to block. It may continue using cached content when you revisit the page.
• Content is part of the main response: Regular page content and other content may arrive in the same request. A connection-level rule can’t keep one part while blocking another.
• The page structure remains: Even if a remote image request fails, the webpage may still show the reserved space, heading, or button.
• The app switches endpoints: After a failed request, the app may contact another domain. The original rule applies only to the destination it matched; it won’t infer what a new endpoint is used for.
• The request bypasses the processing path: If the connection is off or traffic is excluded, adding rules won’t help. First confirm that the traffic passes through the active configuration.

URL Rewrite is a separate request-rewriting mechanism; its capabilities shouldn’t be attributed to REJECT. If a connection rule can’t isolate specific content, preserve necessary functionality and narrow the target rather than expanding IP ranges in an attempt to remove page elements.

Common issues and recovery steps

This guide assumes you already have your own service provider and subscription; get subscription details from your provider. Connection details from your provider solve the connection setup, while REJECT handles matching and blocking in your current configuration. They serve different purposes. After testing, keep rules precise, understandable, and easy to roll back instead of accumulating entries whose purpose is unclear.