How to Write Shadowrocket REJECT Rules: Domain Blocking and Its Limits

What REJECT does: blocks connections, not page elements

A rule consists of a matching condition and an action. DOMAIN-SUFFIX,example.com,REJECT means that when the destination domain used for rule evaluation is example.com or one of its subdomains, the REJECT action is applied. It does not download a page and remove a section, nor does it identify content by reading text on the page.

This process depends on two things: the request must be handled by Shadowrocket, and the active routing mode must use the rules in this Config. Saving rule text in a file does not prove that it is being used to process connections. Content already displayed by an app may not trigger a new network request.

REJECT, DIRECT, and PROXY serve different purposes. DIRECT still makes a connection, but sends it out without a proxy; PROXY uses a proxy route; REJECT blocks the connection attempt. Changing REJECT to DIRECT is not another way to block a connection—it allows the connection to be attempted directly.

DOMAIN-SUFFIX syntax: omit the protocol and path

In the [Rule] section of a Config file, put each rule on its own line and separate fields with English commas. The example below shows the syntax only; it is not a complete Config to replace your existing file. If your file already has a [Rule] section, add the rule there rather than creating a duplicate section.

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

DOMAIN-SUFFIX,example.com,REJECT matches example.com and a.example.com, but not notexample.com just because the names share letters. It matches domain-label suffixes, not arbitrary strings, and does not require a wildcard such as *.example.com.

• Do not include https://: the match value is a domain, not a full URL.
• Do not include a path such as /banner/image.png: paths are not part of the DOMAIN-SUFFIX match field.
• Do not append :443: the port is not part of this domain rule.
• Do not use a non-English comma: ， is not the same as the , required by the rule syntax.

Rule order: the first matching condition determines the action

For the standard rules covered here, rules are evaluated from top to bottom, and the first match determines the action. A REJECT rule farther down will not override an allow rule that has already matched. When troubleshooting, check both the target rule and the rules above it—not just whether the file contains REJECT.

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

This example allows account.example.com to connect directly first, then rejects other matching requests under that domain suffix. If the suffix REJECT rule is moved to the top, the account subdomain will match REJECT first, so the later exact-match exception will have no effect. When editing your Config, keep its existing outbound actions. Do not change your own FINAL rule to DIRECT just because DIRECT is used as the fallback in this example.

Domain rules and IP rules use different information. If the domain is unavailable for matching, do not assume a suffix rule will still match. Also check whether an earlier allow rule matching the destination IP affects later domain rules. Do not reject an entire IP range just because a request ultimately connected to an IP address; other services may share that address.

Apply the rule in Config: change one target at a time

Make changes and verify them separately. First check the active Config and routing mode, then add a single rule, and finally inspect a new request. Config mode under Global Routing routes traffic according to the Config rules. Proxy and Direct modes cannot be used to verify whether this Config's REJECT rules are working. In Scene mode, check the active scene's settings; for an initial test, switch back to Config.

1. Check the file. Open the Config screen and verify which Config is selected. Save a backup before opening it for editing. Do not edit a same-named file that is not currently selected.
2. Add the rule. Add one clearly targeted REJECT rule to the [Rule] section, above any broad rule that might allow the request first. Keep any necessary exact-match allow exceptions.
3. Save and apply. Return to Home, select Config mode under Global Routing, and make sure the connection switch is on. If needed, reconnect so subsequent tests use the saved Config.
4. Make a new request. Close the existing test page, then revisit the target. Check the request log for the destination domain, matched rule, and action. An existing long-lived connection is not a reliable test on its own.
5. Verify rollback. Remove the rule you just added, save and reapply the Config, then make a new request to the same target. A clear change in the result after blocking and then removing the rule provides stronger evidence of cause and effect.

Settings → On Demand controls automatic connection behavior, not a domain blocklist. If the connection turns back on after you manually switch it off during testing, check On Demand first so automatic reconnection is not mistaken for a rule that cannot be undone. If a remote update may overwrite the Config file, keep a record of your edits and verify that the rule is still there after updating.

Limits of domain blocking: a suffix rule cannot distinguish content on the same domain

Domain-level blocking is suited to cases where the entire destination connection is unnecessary. If both wanted and unwanted content come from the same domain, DOMAIN-SUFFIX sees the same match value and cannot allow only some paths. For HTTPS requests, do not treat this rule as a way to read and inspect encrypted page content.

• Different paths on the same domain: For domain rules, example.com/article and example.com/banner both match example.com. Rejecting that domain may make the entire page unusable.
• Different functions, shared resource domain: Images, verification, and analytics may use the same resource endpoint. Blocking it may break images, sign-in verification, or page loading—not just remove one section of content.
• Domain rotation and fallback endpoints: An app may request a different domain after a connection fails. Rejecting an old domain does not mean all fallback endpoints are covered.
• Cached content and existing connections: Cached images, offline data, and established connections can affect what you see. Content still appearing on a page does not, by itself, prove that the rule failed to match.
• Domain information unavailable: Connections made directly to an IP address or apps that handle name resolution themselves can affect whether domain information is available. Check the actual request log rather than inferring the matching process from the browser's address bar.

Blocking a connection does not guarantee that blank space on the page will disappear. The app or website controls the layout; when a resource fails to load, its reserved space may remain or an error message may appear. REJECT determines whether a connection proceeds—it does not fix page layout.

Common symptoms: use match records to decide what to check next

The troubleshooting steps below assume you already have a working Config. If the issue involves a subscription, get its link from your service provider; buying the client and purchasing a routing service are separate matters. Do not replace an entire subscription and all routing settings to troubleshoot a single REJECT rule.

Base your final decision on three checkable facts: which Config is active, which rule matched the new request, and whether the symptom goes away after undoing the change. Keep the rule only if you can reliably reproduce all three. If not, narrow the test target rather than adding more REJECT rules.