This guide is for users who already have a configuration in Shadowrocket and want to add a few blocking rules. First, distinguish match conditions from the REJECT policy, then follow these steps: back up your configuration, add a precise rule, check its position, and test a new request. The examples use reserved domains and documentation addresses to explain the syntax; they are not a blocking list you can use to replace your existing configuration.
1. REJECT Is a Policy, Not a Domain Match Condition
A rule typically consists of a match type, a match value, and an action. In DOMAIN-SUFFIX,ads.example.com,REJECT, DOMAIN-SUFFIX specifies how to match, ads.example.com is the domain suffix to match, and REJECT is the action taken when the rule matches. Writing REJECT alone does not specify which domain to block.
When a request falls within Shadowrocket’s handling scope and is checked against the active rules, a connection matching REJECT is denied instead of being routed through the DIRECT or proxy policy it might otherwise use. This does not remove elements from a webpage or reflow the resulting blank space; an app may show a load error, a placeholder, or a retry prompt.
Rules are matched while a connection is being handled, but that does not mean a REJECT match guarantees that no DNS lookup occurs. Name resolution, caching, and the process of obtaining an address for IP-based rules can all affect what happens. REJECT denies a matching connection; it is not a standalone DNS privacy control.
2. Common Rule Types: Exact Domains, Suffixes, and IP Ranges
Start with an exact domain. Use DOMAIN-SUFFIX only after confirming that the entire subdomain tree should be blocked. Do not include https://, a path, query parameters, or a trailing slash in the domain field. The examples below illustrate different syntax options; you do not need to add them all to the same configuration.
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
IP-CIDR6,2001:db8::/32,REJECT,no-resolve| Rule type | What it matches | Notes |
|---|---|---|
DOMAIN | The exact domain specified. | Use this to block a single confirmed hostname. |
DOMAIN-SUFFIX | The specified domain and its subdomains. | metrics.example.com also matches a.metrics.example.com, but not othermetrics.example.com. |
IP-CIDR | An IPv4 address range. | An address may be shared by legitimate services, so do not assume an IP returned for a domain is dedicated to it. |
IP-CIDR6 | An IPv6 address range. | An IPv4 rule alone does not cover IPv6 destination addresses. |
no-resolve prevents this IP-based rule from actively resolving a domain to an IP address. It does not disable all DNS resolution or prevent requests that already use an IP address from being matched. The example addresses 192.0.2.0/24 and 2001:db8::/32 are reserved for documentation; do not expect them to block a real service.
Choose the match carefully: start narrow, then expand only if needed
If you see an unwanted request from one hostname, start with a DOMAIN rule. Switch to DOMAIN-SUFFIX only after checking the purpose of each subdomain. Do not start by blocking an entire shared IP range.
3. Rule Order: Exceptions First, FINAL Last
In a standard rule list, requests are checked in order, and the first matching rule determines the action. Putting REJECT at the end does not make it override earlier allow rules. Likewise, an exception later in the list cannot undo a broad blocking rule that already matched.
[Rule]
DOMAIN,assets.ads.example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTIn this example, assets.ads.example.com matches the exact exception first, while video.ads.example.com matches the suffix block on the next line. GEOIP matches based on the destination IP’s geographic location, not the purpose of the content; if placed before a blocking rule, a request that meets its criteria may be routed DIRECT first. FINAL is the fallback for requests that match no earlier rule and belongs at the end of the rule list.
Exact exception
- Type
DOMAIN- Target
assets.ads.example.com- Policy
DIRECT- Position
- Place it before the suffix rule that would otherwise match it.
DIRECT means a direct connection only; use the policy that the service actually requires for a legitimate exception.
Suffix block
- Type
DOMAIN-SUFFIX- Target
ads.example.com- Policy
REJECT- Position
- After exact exceptions, but before broad allow rules and FINAL.
FINAL and DIRECT are used here only to explain fallback behavior; this is not a recommendation to replace your existing routing policies.
When combining rules, insert the relevant lines into the existing [Rule] section. Do not paste the entire section again or delete existing proxy policies, rule references, or fallback settings. If your configuration also includes external rule references, check their positions when reviewing the full order; looking only at the lines you just added is not enough.
4. Edit and Test Rules in Config
Rules are stored in the configuration; existing node subscriptions mainly provide connection details, and updating a subscription does not replace editing rules. Before making changes, keep a copy of your working configuration. Then open Config and confirm that you are editing the same configuration that is in use. A remote configuration update may replace local edits, so keep a separate copy of your custom rules.
- Note the current setup. Record the current selection in Home → Global Routing and the active configuration in Config. Keep the original file so you can restore it if needed.
- Add just one test rule. Open the target configuration’s editor in Config. Add a DOMAIN rule for a confirmed target inside
[Rule], before any broad rule that might match first. Save and enable the configuration. - Use rule-based routing. Choose Config under Home → Global Routing. Proxy and Direct are different global routing modes, so they cannot be used to verify whether rules in the same Config are matching as expected. If you use Scene, first check which configuration and routing mode the scene selects.
- Send a new request. Make sure the connection is enabled, then close and reopen the target page. If needed, disconnect and reconnect to establish a new connection; refreshing a page over an existing long-lived connection may not show the effect of the rule change.
- Check the logs. Review the connection or log entry for the destination domain, destination address, matched rule, and action. A new request matching REJECT is evidence; a section of a page temporarily disappearing is not enough on its own.
5. Limits of Domain Blocking and Common Causes of False Positives
DOMAIN and DOMAIN-SUFFIX match hostnames, not individual pieces of a webpage. With HTTPS, these paths on the same host—https://example.com/news and https://example.com/promo—cannot be distinguished using these domain rules alone. Rejecting example.com will affect connections for both paths.
- Legitimate and unwanted content share a domain. Images, sign-in, payment verification, and analytics may use the same infrastructure. If sign-in fails or images disappear, first undo the most recently added rule, then check the hostnames one by one.
- The request has only an IP destination. If the rule engine has no associated hostname available, a DOMAIN-SUFFIX rule cannot identify the domain from the IP alone. Do not assume that every mismatch is caused by rule order.
- The content is cached or uses an existing connection. Offline data, local caches, and reused connections can make a page appear unchanged after an edit. Check new requests after enabling the rule instead of relying only on an already-open page.
- Hostnames and network addresses change. A domain may switch to a backup hostname, and its IP address may change. An IP-CIDR rule based on a temporary resolution can quickly become ineffective or block other sites sharing that address.
- The request is not using the intended configuration. The connection may be disabled, another configuration may be selected, or the Global Routing mode may be different from what you expect. Confirm the request’s handling path before broadening the block.
Domain-based blocking usually does not require HTTPS decryption. Adding a certificate or changing unrelated settings will not solve the problem of multiple types of content sharing one hostname. When resources cannot be distinguished independently, respect that limitation; a single REJECT rule cannot be relied on to remove an entire category of page content.
6. Common Questions: No Match, False Positives, and Reverted Changes
Why does the page still open after I add a REJECT rule?
First check whether the target is the page’s main host or a host used by one of its resources. Go to Home → Global Routing and check Config, then open Config to confirm which file is enabled. Send a new request and check the logs. If the request uses a different hostname, add a precise rule based on the log rather than repeatedly adding the same line.
What if legitimate images disappear after a rule matches?
Restore your backup or remove the most recently added blocking rule, then confirm that the images return. Next, narrow DOMAIN-SUFFIX to a confirmed DOMAIN. If there is a separate, legitimate hostname, place its exact exception before the blocking rule. If the images and the content you want to block share a hostname, domain rules alone cannot separate them.
Why didn’t the rules change after I updated an existing subscription?
First check whether you updated a node subscription in Home or a remote configuration in Config. Updating the former is not the same as updating rules; the latter may overwrite local edits. Go back to Config and inspect the actual [Rule] section. Keep separate backups of your custom rules and the original configuration, then check each rule after an update.
Can I replace FINAL with REJECT to avoid blocking domains one by one?
FINAL,REJECT denies every connection that did not match an earlier rule, which has a much broader effect than blocking one domain. Do not use it as a replacement for targeted rules unless you are maintaining a deliberate allowlist. Restore the original FINAL policy first, then add a narrowly scoped DOMAIN or DOMAIN-SUFFIX rule.
7. Quick Checklist Before Saving
A maintainable REJECT configuration should answer four questions: what is being blocked, why this match type is appropriate, where exceptions go, and how to undo the change. Change one match condition at a time and keep before-and-after records; this makes problems easier to diagnose than importing a large set of unverified rules at once.
- The rule is in the
[Rule]section of the active configuration, and the domain field contains no scheme or path. - Exact exceptions come before the corresponding blocking rules, and blocking rules come before any broad rule that could match first.
- Keep FINAL’s existing fallback role; do not change it casually when adding a blocking rule.
- Home → Global Routing is set to Config, and the actual match has been checked against a new connection log.
- Sign-in, images, and other essential functions have been tested, and a restorable copy of the original configuration is saved.