Shadowrocket REJECT Rules: How Blocking Works, Match Scope, and Limitations

1. What REJECT Does: Blocks Connections, Not Page Elements

Shadowrocket rules combine a match condition with a policy. REJECT is a policy that denies matching requests; it is not a protocol or a server you need to add. A rule can take effect only when the relevant traffic passes through Shadowrocket and is evaluated against the rules in the active Config.

Domain rules match the destination domain, not text or images on a webpage or the location of a button. If a page loads analytics from a separate domain, blocking that domain may prevent the resource from loading. But if the page content, login, and images all rely on the same domain, blocking it may break them all. Rules cannot automatically tell which responses contain content you want to keep.

What you see after a request is denied depends on the app that made it. You might see an empty area, a loading error, a retry prompt, or previously loaded content. The page still appearing does not prove the rule failed, and a single loading error does not prove REJECT caused it. Network interruptions, DNS issues, and server errors can look similar.

2. Basic Syntax: Start with DOMAIN Before Widening the Match

A standard domain rule has three fields: a rule keyword, a match value, and a policy, separated by English commas. The standalone example below denies requests to a specific host, then denies a suffix and its subdomains, and sends all remaining requests directly. Add only the rules you need to your existing Config; do not replace your current routing rules with this snippet.

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

Do not include https://, a port, a path, or query parameters in the match value for DOMAIN or DOMAIN-SUFFIX. https://example.com/banner?id=1 is a URL, not a domain. Adding the whole URL to a domain rule does not enable path-based blocking.

3. Rule Order and Global Routing: A Correct Rule May Not Be Active

Check Global Routing on Home. To test standard rules in a local Config, select Config. Proxy and Direct are global routing modes; their results do not show whether a REJECT rule in Config works. Scene depends on its own setup and is not simply another name for Config. Then, in Config, confirm that the edited configuration is selected and enabled.

1. In Config, save a copy of the current configuration, then open the local configuration you want to edit.
2. Add a narrowly scoped REJECT rule under [Rule]. Avoid creating multiple sections with the same name.
3. Place exceptions before broader rules that could match them, and keep FINAL at the end of the rules.
4. Save the changes and confirm the edited Config is active. Return to Home and check that Global Routing is set to Config.
5. Repeat the target request and check the destination, policy, and matched rule in the request log.

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

This example sets a DIRECT exception for account.example.com, then rejects other requests matching the example.com suffix. Standard rules are evaluated from top to bottom; the first match determines the policy. If the broad suffix rule comes first, the exception below it cannot undo that decision.

4. Where DOMAIN-SUFFIX Ends and URL Rewrite Begins

DOMAIN-SUFFIX does not inspect HTTP paths. If the same host serves both /article/ and /banner/, a domain rule cannot block only the latter. URL Rewrite works with visible HTTP request URLs and the match and handling options it supports. This does not mean it can read every HTTPS path directly.

HTTPS paths and query parameters are protected by TLS. Inspecting them usually requires correctly configuring HTTPS decryption for the relevant host, installing a certificate, and trusting it. Adding a URL Rewrite rule alone does not meet these requirements. Some apps may reject this handling because they use certificate pinning or similar mechanisms. Check support for transport paths such as HTTP/3 separately; the port alone does not tell you whether rewriting is possible.

Certificates and HTTPS decryption change the trust boundary. Do not expand decryption to every host just to try one blocking rule. This guide does not provide a wildcard decryption setup. If you cannot confirm the scope, stick to precise domain rules or use content controls provided by the target app.

5. IP-CIDR and GEOIP: Address Matching Is Not Content Classification

A target may use an IP address directly or rely on shared content delivery infrastructure. Distinguish between a domain rule that cannot match because no hostname is available and an IP rule with too broad a scope. GEOIP checks the region associated with an address; IP-CIDR checks whether an address falls within a specified range. Neither can tell whether a response contains ads or analytics.

[Rule]
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,DIRECT

192.0.2.0/24 is a documentation example range, not a real target to block. no-resolve means this IP rule will not actively trigger a domain lookup. It can still match an address if a usable destination IP is already available. It does not disable all DNS or turn an IP rule into a domain rule.

• A single IP may serve multiple domains. Blocking it may also affect legitimate images, login APIs, or other websites.
• A single domain may resolve to multiple IPv4 and IPv6 addresses. Handling only one IPv4 address does not cover the entire domain.
• A GEOIP result describes the region associated with an address, not the purpose of its content. It is not a substitute for a label meaning “content of this type is unwanted.”
• DNS, caching, and connection reuse can affect what you observe. Check new request logs rather than relying on a single DNS result.

6. Verify and Roll Back: Make Your Checks Repeatable with Request Logs

Change one condition at a time. First note how the page behaves before changing the rules. Add one rule, then reopen the page or repeat the action. If the app reuses an existing connection, the new rule may not affect it. If the content is cached, there may be no new request at all. If needed, close and reopen the app, then use newly generated request logs to verify the result.

1. Check the destination: Confirm the actual request host. Redirects can change the host, so do not rely only on the address bar.
2. Check traffic interception: Verify the connection status and Global Routing to ensure the test request uses the active Config.
3. Check the match: See whether the new request used REJECT. If it did not match, first check rule order, domain spelling, and the active Config.
4. Check the impact: Test essential features such as login, images, playback, and payments—not just whether the target area disappeared.
5. Check rollback: Remove or disable the new rule and repeat the request. If the issue goes away, narrow the match scope.

Do not use a single latency test to verify content requests. A successful connectivity test reports only the result for its test target. It does not prove that REJECT matched the target domain or that a page path was handled. If you need to share troubleshooting details, keep the destination host, matched policy, and steps taken; remove subscription URLs, tokens, and other credentials first.

7. FAQ: Why Is Content Still Visible After Adding a Rule?

Keep a rule only if it meets all three conditions: the target is clearly defined, the match can be verified in request logs, and normal functionality can be restored. More rules do not mean more accurate coverage. When content cannot be distinguished on its own, stop widening the scope; that is easier to maintain than a long list of speculative suffix rules.