This guide is for Shadowrocket users who want to adjust an existing configuration. First, distinguish rule conditions from the REJECT action. Then test rule order with example domains and use connection records to investigate false positives. The steps assume you already have your own service provider and subscription. Examples illustrate syntax only; they are not complete configurations to use as-is.
1. REJECT is an action, not a content detector
Shadowrocket is a paid client for Apple platforms, available exclusively on the App Store. It is developed by Shadow Launch Technology Limited, has app ID 932747118, and is sold as a one-time purchase. It is primarily for iPhone and iPad; check the App Store listing for compatibility with other devices and system requirements. Buying the app does not include a connection service. This guide covers matching and handling in local configuration, not the provision of connection services.
In a rule such as DOMAIN-SUFFIX,example.com,REJECT, DOMAIN-SUFFIX is the match type, example.com is the condition, and REJECT is the action taken when it matches. The request is denied if it meets the condition. Shadowrocket does not continue to the rules below or automatically retry the request through a proxy.
This flow describes only new requests handled by Shadowrocket. Existing connections, content cached by an app, and traffic outside Shadowrocket's handling scope will not disappear just because you add a rule. So an old image still showing on screen does not mean REJECT failed. Check a newly initiated request and its connection record instead.
2. Check Global Routing before investigating rule order
Check the current mode under Home → Global Routing. To test the standard configuration rules covered here, first select Config, then confirm which configuration file is active under Config. Saving rules to a different file without using that file will not change how current connections are handled.
| Mode | How traffic is handled | What to check |
|---|---|---|
Config | Rules are applied according to the active configuration. | Use this mode to test rule order and REJECT matches as described here. |
Proxy | All traffic uses proxy routing. | This is not an equivalent test environment for standard Config rules. |
Direct | All traffic uses direct routing. | If switching modes restores access, that does not necessarily mean the proxy server is faulty. |
Scene | Traffic is handled according to the configured scene. | Check the active scene's conditions and routing settings first to avoid changing the test conditions. |
Settings → On Demand controls automatic connections based on conditions. It is not a rule list and does not determine whether a domain should use REJECT or DIRECT. If you switch between Wi-Fi and cellular during a test, recheck the tunnel connection, Global Routing, and active configuration. Do not confuse an automatic connection trigger with a rule match.
- Back up the active configuration before editing, and note the current Global Routing mode and the domain you are testing.
- In Config, edit the configuration file you are actually using. Change just one condition or rule at a time.
- After saving, confirm that the same configuration file is still active. Close the target page and make a new request.
- Check the new request's destination, matched rule, and final action before making further changes.
3. Writing DOMAIN-SUFFIX, IP-CIDR, and FINAL rules
Rules are generally checked from top to bottom, and the first match determines how a request is handled. Put more specific exceptions before broader rules, and place FINAL at the end as a fallback. A broad REJECT rule followed by a DIRECT rule usually cannot restore a request that has already matched.
The readable example below uses sample domains and the example address 192.0.2.10. DIRECT is used as the fallback to avoid relying on a user-defined policy name; this does not mean your everyday configuration should send everything direct. Do not replace your existing configuration with this snippet.
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.10/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTDomain matching boundaries
- DOMAIN
- keep.example.com,DIRECT: an exception for this exact domain only.
- DOMAIN-SUFFIX
- example.com,REJECT: matches the root domain and its subdomains.
- Similar names that do not match
- notexample.com is not a subdomain of example.com.
Put exact-match exceptions before suffix rules. Matching is not based on whether a string contains a particular sequence of letters.
IP and fallback boundaries
- IP-CIDR
- 192.0.2.10/32,REJECT,no-resolve: matches one example IPv4 address.
- GEOIP
- CN,DIRECT: routing is based on the IP geolocation database.
- FINAL
- DIRECT: handles requests not matched by earlier rules.
no-resolve means this IP rule will not actively trigger a domain lookup for matching. It does not disable all DNS queries.
In this order, keep.example.com matches the exact exception first, while img.example.com matches the suffix REJECT rule. Whether an IP rule can be evaluated also depends on the destination address information available at the time. GEOIP reflects the database's geolocation data; it does not guarantee where a service is hosted or what its content is. These conditions are not interchangeable ways to filter domains.
4. Shared domains and HTTPS: where REJECT falls short
A domain rule can determine whether requests to a target domain are denied; it cannot determine which part of a page should be removed. If essential features and unwanted content share a domain, using REJECT on that domain may also break sign-in, images, payment redirects, or other dependent requests.
| Scenario | What domain REJECT does | What you cannot infer |
|---|---|---|
| Resources hosted on a dedicated subdomain | If the target can be identified and the rule matches, requests to that subdomain can be rejected. | This does not guarantee that an empty placeholder will disappear from the page. |
| Different HTTPS paths on the same domain | Rejecting a domain affects requests to that domain. | A domain rule alone cannot distinguish /content from /metrics. |
| Multiple domains share one IP address | An IP-CIDR rule may affect multiple unrelated services. | One IP address does not necessarily represent one website. |
| Requests use UDP 443 | Check the actual destination and whether a rule matched. | The port alone does not tell you the traffic type or whether it has been blocked. |
Ordinary domain and IP rules do not gain access to full HTTPS paths or message bodies just because traffic passes through a tunnel. Application-layer content in an encrypted connection cannot be filtered piece by piece with a single DOMAIN-SUFFIX condition. Shadowrocket's supported connection protocols and local rules operate at different layers; changing the proxy protocol does not give domain rules the ability to identify page elements.
Bottom line: narrow the scope when you cannot isolate the target
If a domain serves both essential features and requests you want to block, remove the domain-wide REJECT and look for a target that can be identified independently. If no such condition exists, keeping the service working is easier to verify and maintain than adding broader IP rejection rules.
5. Troubleshooting false positives: trace failed requests instead of repeatedly changing connections
Typical signs of a rule causing unintended blocking include a page loading while sign-in hangs, text appearing without images, or an action failing at the same step every time. These are clues, not proof that REJECT matched. DNS failures, remote connection errors, and app errors can look similar.
- Repeat the same steps. Note when the failure occurred, what you did, the network in use, and the configuration name. For example, revisit the same sign-in page each time instead of testing multiple apps at once.
- Check connection records. Look for the destination domain or IP around the time of the failure. Confirm whether it shows REJECT and which rule matched. If the record does not show REJECT, investigate DNS, connection setup, or the remote response instead.
- Undo one change. Temporarily remove the rule you just added, save the configuration, and repeat the same action. Do not delete an entire block of rules at once, or you will not know which change made the difference.
- Add an exception for essential destinations. If a domain is a confirmed dependency, add an exact DOMAIN exception before the broader rejection rule and use a policy appropriate for that destination in your existing configuration. Do not automatically switch it to DIRECT.
- Restore and verify. Retest the main feature and the target you intended to reject. The exception is working as intended only if both results meet expectations and the blocked scope has not been opened up entirely.
When testing a new rule, establish a fresh connection to the target. If needed, disconnect and reconnect the tunnel, and confirm that On Demand has not changed the expected state. Reload the page before judging content that remains on screen. When reporting an issue, share only redacted destinations, rules, and symptoms; hide full subscription URLs, tokens, passwords, and other credentials.
6. FAQ: seeing content does not mean a rule failed
I added REJECT. Why is the old image still there?
Reload the page first and watch for new connections. The image may be cached by the app or may have loaded before you added the rule. Investigate the active configuration, domain condition, and rule order only if a new request to the target still succeeds without matching the expected REJECT rule.
Why did rejecting one domain break the entire sign-in flow?
Remove the rule and reproduce the issue once, then check the request destinations from the failure. Authentication and service resources may share a domain. If you need to keep one specific subdomain, add an exact DOMAIN exception before the broader DOMAIN-SUFFIX rule, then test the sign-in flow again.
Why did nothing change when I put REJECT after FINAL?
FINAL is the fallback for requests that have not matched earlier rules. Ordinary rules placed after it cannot handle requests already caught by that fallback. Put specific matches before FINAL, in a clear order: exact exceptions, target rejections, other routing rules, then the final fallback.
Can I reject every IP address used by a resource?
First check whether the address is shared with other services you need. CDN addresses can change, and one IP can host multiple domains. If you want to restrict a particular domain, prefer a domain condition you can verify; do not use a broad IP range in place of an unidentified target.
After troubleshooting, keep a brief change log with the rule you changed, why you changed it, how to reproduce the issue, and how to revert the change. If something goes wrong later, review recent edits before broadening the investigation. For basic Home, Config, and Settings steps, see the Getting Started guide. Look up rule terms in the glossary.