This guide is for users who already route traffic with Config and want to block connections to specific targets. First, check where REJECT applies; then write rules for exact domains, domain suffixes, or destination IPs. Finally, use connection logs to verify matches and catch unintended blocks. Example domains illustrate syntax only—identify actual targets from your own request logs.
What REJECT does: blocks matching connections
REJECT is a policy, not a standalone match condition. The rule’s preceding fields determine whether a target matches; the final REJECT specifies what happens when it does. For example, DOMAIN,metrics.example.com,REJECT matches the exact domain and rejects the request. It won’t automatically identify all analytics services or generate a list of domains.
This flow assumes the request is within Shadowrocket’s handling scope and rule-based routing is active. REJECT blocks further communication while the connection is being handled; it does not wait for the full response and then hide the resulting page. The app may show a connection error, retry, or time out, depending on how it handles the failure. The message alone won’t tell you which rule matched.
Rules are generally checked from top to bottom, and the first matching rule determines the policy. So adding a REJECT rule does not guarantee that a request will use it: an earlier, broader allow rule may match first, leaving the later blocking rule no chance to handle that request. When troubleshooting, check the target, rule order, and active configuration together.
Check Config before adding a narrowly scoped rule
Under Global Routing on Home, select Config, then confirm which configuration file is active. Proxy and Direct are not substitutes for this step. If you use Scene, also verify which configuration and routing mode the current scene actually uses; a REJECT rule in a file does not prove that file is active.
- In Config, keep a copy of the current configuration and note the existing rule order and
FINALpolicy so you can restore them if needed. - Open the active configuration and use its edit option to find the
[Rule]section. Start with one exact-domain rule; don’t broaden it to a whole domain group yet. - Place the rule before any broad rules that might match first, while keeping precise exceptions required for your services.
- Save the configuration and confirm it remains active. Close existing connections in the target app, then repeat the same action.
- Check the target and policy for the new connection. The block is working as intended only if the new request actually matches
REJECT.
If the configuration updates from a remote source, check whether future updates will overwrite your local changes. Get subscriptions and nodes from your service provider. Updating server subscriptions and editing Config rules are separate operations; refreshing the server list does not confirm that your new rule has loaded.
DOMAIN, DOMAIN-SUFFIX, and IP-CIDR syntax
Choose the narrowest condition that covers the target. Use an exact domain for a single host, a domain suffix for a clearly defined group of domains and their subdomains, and an IP range for targets with a confirmed address range. Don’t include https://, a path, query parameters, or a port in the domain field.
Match by domain
- Exact domain
DOMAIN,metrics.example.com,REJECT- Domain suffix
DOMAIN-SUFFIX,metrics.example.com,REJECT- How they differ
- The first matches only the specified host; the second also matches its subdomains.
Suffix matching follows domain boundaries; it does not match arbitrary text containing the suffix.
Match by destination IP
- Single IPv4 address
IP-CIDR,192.0.2.8/32,REJECT- IPv4 range
IP-CIDR,192.0.2.0/24,REJECT- Example
- These documentation-only addresses are not actual blocking targets.
Check the range against the actual connection addresses; don’t assume a shared IP belongs to just one service.
DOMAIN-SUFFIX,metrics.example.com,REJECT matches metrics.example.com and img.metrics.example.com, but not othermetrics.example.com. There’s no need to write *.metrics.example.com; a wildcard is not the suffix parameter syntax for this rule.
IP rules and domain rules are not interchangeable. A domain may resolve to multiple addresses, and one address may host multiple domains; the client may also use another address or IPv6. Rejecting one IPv4 address does not prove that all connections to a related domain are blocked. GEOIP matches by IP address location and covers a broader range, so it is not a substitute for precisely blocking a specific domain.
Rule order: put exceptions first, blocking rules next, and FINAL last
Here’s an example that preserves an exception: allow one specified host to connect directly, then reject other hosts under the same suffix. The example’s PROXY must be a policy or policy group available in your configuration. If your configuration uses a different name, keep its existing FINAL rule instead of copying the example’s fallback.
[Rule]
DOMAIN,health.metrics.example.com,DIRECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,PROXY| Request target | First matching rule | Result |
|---|---|---|
health.metrics.example.com | First DOMAIN rule | Uses DIRECT |
img.metrics.example.com | Second DOMAIN-SUFFIX rule | Uses REJECT |
www.example.com | Final FINAL rule | Uses the example’s PROXY |
If you put the suffix block on the first line, the health-check host will also match REJECT, and the later DOMAIN exception can’t allow it through. Conversely, adding DOMAIN-SUFFIX,example.com,DIRECT before the blocking rule will allow those targets through first. FINAL handles the remaining requests; placing it before the blocking rules prevents them from being checked.
Need an exception? Narrow the rule’s scope first
Move the exact rule for the required host above the broad blocking rule, then test again. Don’t remove every REJECT rule to fix one unintended block, or use a broader DIRECT rule to mask an ordering problem.
What REJECT can and can’t block
REJECT is suited to connections with clearly identifiable targets that can be distinguished by domain or address, such as a separate resource host you’ve confirmed you don’t need. It matches connection targets—not individual visual elements on a page, and not content based on its meaning.
- Paths on the same domain can’t be matched separately: If business requests and unwanted resources both come from
api.example.com, a DOMAIN rule affects them all. It can’t reject only the/metricspath. - HTTPS is not decrypted: REJECT does not need to read encrypted content and does not automatically get access to page structure. Blocking a resource connection does not remove the space reserved for it in the page layout.
- Cached content can hide the result: The app may display a previously cached image or other content. That doesn’t mean the latest request got through. Check new connection logs instead of judging by whether the screen changed.
- Existing connections need separate consideration: After a rule changes, an established connection that’s being reused may not immediately go through the matching process again. Have the app establish a new connection when testing.
- Targets can change: Fallback domains, rotating addresses, and shared infrastructure can all affect what a rule covers. Use actual connection logs to confirm the target instead of blocking an entire shared IP range.
Distinguish DNS resolution failures from REJECT matches. DNS can fail before a destination address is available, while a REJECT match should have corresponding rule-policy evidence. A domain that won’t open is not, by itself, proof that REJECT blocked it. Whether domain information is available for matching also depends on the request and resolution path. If only an IP address is available, check the relevant IP rules in the connection logs rather than assuming a domain condition is present.
Rules not taking effect, unintended blocks, and how to undo changes
Change one variable at a time when testing: use the same app, action, and network, and compare new connections before and after the change. Troubleshoot in this order: confirm the configuration is active, check whether the rule matched, then consider whether cached content is masking the result.
The rule is saved. Why can the target still open?
First, check that Home → Global Routing is set to Config, then verify which file is active in Config. Next, check whether an earlier DIRECT, PROXY, or other broad rule matches the target’s new connection first. Don’t just look for a REJECT line in the file.
The log shows REJECT. Why is the original content still on the page?
Quit and reopen the target app to distinguish cached content from new requests. Check whether the page fetched resources from other domains and review those connections too. Content still visible from cache does not prove that a matching request was allowed through.
After adding a suffix rule, sign-in or images stop working. What now?
First, disable the rule you just added and try again to confirm it caused the problem. Then identify the required host in the failure logs and switch to a narrower DOMAIN block, or add a precise allow exception before the suffix rule. Don’t allow the entire parent domain.
Why did my blocking rule disappear after a configuration update?
Compare the active configuration’s [Rule] section with your saved copy to see whether remote content overwrote your local changes. Add back the smallest rule that you’ve verified, and preserve the existing FINAL rule. Refreshing server subscriptions does not restore rules.
To undo a change, first remove the last blocking rule you added, save, and establish a new connection to the target. If you changed several things and can’t tell which came first, restore the saved configuration copy. Keeping a record of the test target, matched rule, and recovery result makes it easier to find the cause than repeatedly changing every setting.