REJECT blocks connections that match a rule; it does not remove individual elements from a webpage. This guide is for users with an existing configuration in Shadowrocket: first check Config mode and rule order, then test blocking with an exact domain, and finally distinguish among three limitations: hidden domains, reused connections, and content served from the same domain.
What REJECT does
REJECT is a rule action, not a matching keyword. DOMAIN,ads.example.com,REJECT has three parts: DOMAIN specifies the match type, ads.example.com is the value to match, and REJECT means the matching connection is blocked instead of being routed through DIRECT or a proxy policy.
This flow assumes the request is within Shadowrocket's scope. Adding a REJECT rule alone does not make it effective if the connection is off, the expected configuration is not enabled, or the current routing mode is not using those rules. After a connection is blocked, the app may show a blank screen or an error, or keep retrying. What appears depends on the app's own error handling.
REJECT does not erase content already downloaded by a page, data stored in the local cache, or promotional screens built into an app. When checking the result, look for whether new requests are blocked rather than judging only by what remains on screen.
Check Config mode and rule order first
In Home, set Global Routing to Config, then open Config and confirm which configuration is enabled. Do not use page behavior in Proxy or Direct mode to verify a Config routing rule. If you normally use Scene, note the scene settings first, then switch to a clearly defined Config test setup to reduce interference from automatic switching.
- Keep a copy of the original configuration in Config and make sure you are editing the file you intend to enable.
- Add the test rule to the configuration's
[Rule]section, before any broad rules that might match first and beforeFINAL. - Save and enable the configuration, then return to Home and confirm
Global Routing → Config. Check that the connection is on. - Have the target app establish a new connection, then check the connection log for the destination, matched rule, and action. Do not draw conclusions from a single page refresh.
Regular rules are checked in order, and the first matching rule determines the result. The example below illustrates the structure only; example.com domains are not a real blocklist, and FINAL,DIRECT is only a fallback example. Do not let it override the final policy in your existing configuration.
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,DIRECTIf DOMAIN-SUFFIX,example.com,DIRECT is the first rule, requests to ads.example.com will match it, so a later exact-match block rule will not handle them. Order specific exceptions, destinations to block, and broader rules according to your priorities; the last rule added does not automatically take precedence.
Choosing between exact domain and suffix matches
When troubleshooting a single destination, start with DOMAIN to keep the scope narrow. Consider switching to DOMAIN-SUFFIX only after confirming that the entire subdomain branch serves the same purpose. Do not block the whole root domain just because one subdomain is generating unwanted requests.
Exact match
- Keyword
- DOMAIN
- Match value
- ads.example.com
- Action
- REJECT
- Scope
- Only ads.example.com
Does not also match img.ads.example.com; useful for testing one specific destination first.
Suffix match
- Keyword
- DOMAIN-SUFFIX
- Match value
- metrics.example.com
- Action
- REJECT
- Scope
- The domain and its subdomains
Covers both metrics.example.com and api.metrics.example.com; check what they are used for first.
DOMAIN-KEYWORD matches a keyword anywhere in the domain, so its scope is harder to control than a specific suffix. For example, using only ad as the keyword may match many domains unrelated to the service you want to block. IP-CIDR matches an address range, while GEOIP matches by IP geolocation; neither can target one part of a webpage. Blocking an IP on a shared server or address can affect other domains as well.
Bottom line: start narrow, then widen the match
First, test the destination with a single DOMAIN rule and verify its purpose and match result. Switch to DOMAIN-SUFFIX only after confirming that all subdomains in the branch can be blocked. Do not use the entire root domain as your first test.
Domain rules cannot target content by page location
Suppose the main content comes from api.example.com/content, while a promotional request goes to api.example.com/promo. Both use the same domain, and standard DOMAIN and DOMAIN-SUFFIX rules cannot distinguish them by URL path. Blocking api.example.com affects both types of connection, not just the promotional request.
- Different domains: Content uses
api.example.com, while additional requests useads.example.com. You can try isolating them with an exact-domain rule, but first check whether either depends on the other. - Same domain, different paths: Domain rules cannot handle
/contentand/promoseparately. - Multiple types of content in one response: If the response contains both primary content and promotional data, blocking the connection blocks both. It cannot remove just one field.
- Content stored in the app: Offline resources and already-cached screens need no new connection, so they do not trigger a new network rule match.
HTTPS commonly uses port 443, but the port alone does not reveal what a request is for. Standard domain rules cannot access the path or body of an encrypted request. The same applies to in-app web content: what matters is whether the destination uses a separate connection and whether its domain is available for matching—not whether it appears in a browser or inside an app.
Encrypted DNS and the limits of domain visibility
Domain rules need domain information to match against. When an app uses the system resolver, a link may be available between the lookup and the connection. When an app uses its own DoH or DoT, DNS queries are carried inside a separate encrypted connection; do not assume Shadowrocket can recover the queried domain from the destination IP alone. Whether other connection metadata is available also depends on the traffic and settings.
| Scenario | What to check | What you cannot conclude |
|---|---|---|
| Standard DNS | The lookup-to-connection association, destination domain, and rule that actually matched | Seeing a DNS query does not mean the subsequent connection will match REJECT |
| In-app DoH | Whether it connects to a separate resolver endpoint and whether the destination connection still exposes domain information | DoH commonly uses port 443; that does not make every connection on port 443 a DNS request |
| In-app DoT | Whether there is a connection to destination port 853 and what it is used for | Port information alone cannot reveal query contents |
| Direct connection to an IP address | Whether the connection log shows only an address or also has an associated domain | Do not assume a DOMAIN rule can match that connection |
In these cases, first check the DNS settings in Settings and the app's own resolver options. See the DNS settings reference for details. Blocking a known resolver endpoint may cause resolution to fail or trigger a fallback endpoint; neither outcome proves that the target content is being blocked. In particular, do not replace domain troubleshooting with a blanket block on all port 443 traffic, which would affect ordinary HTTPS connections.
Run a block test you can verify
Change only one variable at a time. Placeholder areas, loading times, and error messages are indirect signs; more useful evidence is the destination, the first rule matched, and the action applied. The steps below help you check your existing configuration and do not involve obtaining any connection service.
- Record a baseline: Save the current configuration and note the Global Routing mode, target domain, and page behavior before adding a rule.
- Add just one rule: Write the confirmed destination as a complete rule, such as
DOMAIN,ads.example.com,REJECT. In a real test, use a domain you have recorded; the example domain is not a blocklist entry. - Establish a new connection: Quit and reopen the target app, and reconnect Shadowrocket if needed. Existing long-lived connections may be reused, so a single refresh may not trigger a new rule check.
- Check the match: Review the new connection's destination, rule, and action. If it still shows DIRECT or a proxy policy, first check that the configuration is enabled and that no earlier rule matched.
- Check for side effects: Test sign-in, content loading, images, and submissions one by one. If something breaks, remove the new rule and repeat the same action for comparison.
Include automatic connection behavior in your notes. Settings → On Demand manages condition-based connections; it does not replace REJECT rules. If the connection state changes with the network during testing, first confirm whether the request entered the tunnel at the time. Do not change On Demand, DNS, and the rule list at once, or it will be difficult to identify what caused the result.
Common symptoms and fixes
Why is the content still there after adding REJECT?
Reopen the target app and check whether a new connection matched REJECT. If the log shows it was blocked but the content remains on screen, check for cached data, local resources, or multiple types of content in the same response. Do not immediately widen the rule to the entire root domain.
Why does blocking a connection prevent sign-in?
Remove the new rule and test sign-in again. If sign-in works, narrow DOMAIN-SUFFIX to a confirmed DOMAIN, then test the authentication endpoint and additional requests separately. When one domain serves multiple purposes, keep the connections that are required.
Why does the log show an IP address instead of a domain?
Check whether the app connects directly to an IP address or uses its own encrypted DNS, and review the DNS settings in Settings. Do not expand the block to an entire IP range without checking: shared addresses may host other services, so confirm the target and potential impact first.
Why did my manually added rule disappear after a configuration update?
In Config, check which file is enabled and review its rules. Updating a remote configuration is not the same as updating the server list for a subscription already in Home. Keep a local copy before replacing a configuration, then check that your custom rules are still in the intended position after the update.
The right test is whether the specified connection is blocked as expected while essential features still work—not a promise that a particular kind of content will disappear from every app. REJECT works best for destinations that can be identified as separate connections. When content shares a domain, connection, or response with essential functionality, accept the limits of domain-based routing instead of continually widening the block.