Shadowrocket REJECT Rules: Syntax, Scope, and Limitations

At a glance

In Shadowrocket, REJECT is a connection-handling policy, not a page-element filter. This guide is for users with a working connection who want to adjust Config rules. It explains how domain and IP rules match, then walks through making a targeted change, checking whether it matched, and restoring the original configuration. It also helps distinguish rules that are not taking effect from resources that cannot be blocked independently.

What REJECT applies to: connections, not individual page elements

A rule consists of a matching condition and an action. When the client can obtain information such as the destination domain or IP, it uses the active configuration to decide how to handle the connection. If a rule with the REJECT action matches, that connection is denied. Shadowrocket does not inspect a webpage, identify an image as promotional, and remove only that image. Whether a rule is suitable therefore depends first on whether the target resource can be separated from necessary resources at the connection level.

For example, if a page is served from www.example.com and an additional resource comes from the separate host metrics.example.com, you can create a domain rule for the latter. If the login, page content, and additional resources all use the same domain and differ only by path, rejecting that domain will usually affect all of them.

3 fields

Common domain rule fields: type, match value, and action

TCP 443

Common HTTPS port; does not identify a resource type

UDP 443

Common HTTP/3 port; does not identify a separate domain

A port is only one part of connection information. A connection using port 443 is not necessarily a resource you want to block; rejecting traffic by port can disrupt many normal connections. All domains and IPs below are documentation examples, not a blocklist.

Common rule syntax: start with DOMAIN, then consider DOMAIN-SUFFIX and IP-CIDR

These are partial examples you can add to the configuration's [Rule] section. Each line defines a separate condition. Do not use these lines to replace a complete configuration, or remove existing policy groups and fallback rules just to match the examples.

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve

Rule type	Example scope	Check before use
`DOMAIN`	Matches only the domain `metrics.example.com`.	A good first test for a single host, once you have confirmed it does not handle essential functions.
`DOMAIN-SUFFIX`	Matches `telemetry.example.com` and its subdomains.	Includes `a.telemetry.example.com`, so it covers more than an exact match.
`IP-CIDR`	`192.0.2.0/24` represents an IPv4 subnet.	A single subnet may host multiple domains, so do not use it to guess what traffic is for.

DOMAIN-SUFFIX,example.com,REJECT matches the root domain and its subdomains. It does not mean “block only a certain type of resource on this site.” Do not include https://, a path, or query parameters in the domain field. DOMAIN and DOMAIN-SUFFIX do not match paths such as /banner/ in a URL.

no-resolve means this IP rule will not trigger an additional domain lookup. It does not guarantee that the rule cannot match a domain connection: if the client already knows the corresponding IP, the actual connection details still determine whether it matches. An IPv4 subnet rule also does not cover IPv6 addresses used by the same service. If the destination uses IPv6, check the actual address rather than arbitrarily widening the IPv4 subnet.

Bottom line: start with one specific domain

Start with one DOMAIN rule to verify the target and any side effects. Use DOMAIN-SUFFIX only after confirming that the entire subdomain tree should be rejected. Do not block an entire shared address range based on a single IP you happened to observe.

Rule order and Global Routing: correct syntax is only part of the story

In Config-based routing, rules are generally evaluated in order, and the first matching rule determines the action. If an earlier rule already allows traffic to the target, a later REJECT rule will never handle that connection. FINAL is a fallback for traffic that did not match any preceding rule; do not place it ahead of ordinary rules that still need to be evaluated.

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

The example rejects one exact domain first, then sends other connections under the same root domain through DIRECT. If you swap the first two lines, metrics.example.com will match the broader DIRECT rule first. The final FINAL,DIRECT is included only to demonstrate rule order. Keep the fallback action your configuration needs; do not change the handling of all unmatched traffic based on this example.

Config

Recommended

The active configuration determines the action. To test a custom REJECT rule, first confirm that Home → Global Routing → Config is selected.

Best for: everyday rule-based routing and checking whether custom rules match.

Proxy

Routes traffic through the proxy path rather than applying Config's regular routing rules one by one. After switching to this mode, a webpage being blocked or allowed is not a valid test of the Config rules you just edited.

Best for: temporarily checking proxy connectivity while isolating the effects of regular routing rules.

Direct

Routes traffic directly. Like proxy mode, it is not a suitable way to test whether custom Config rules match. A webpage opening over a direct connection does not mean the REJECT syntax is wrong.

Best for: comparing direct access and checking for differences in network conditions.

If you use Scene, first check which configuration and handling mode the active scene selects. Temporarily fixing the mode to Config can reduce variables while troubleshooting. These are three common test modes, not a complete list of Global Routing options.

Make and test a targeted change: add one rule at a time

These steps assume you already have a working configuration. Server entries in Home, configuration files in Config, and general preferences in Settings serve different purposes. Editing a configuration that is not active will not change how the current connection is handled.

Keep the original configuration

Open Config and confirm which configuration is active. Save a copy or export a backup first. Note the current Global Routing mode so you can restore the previous setup.
Set the handling mode

In Home → Global Routing → Config, select Config-based routing. Check that the connection toggle in Home is on so you are testing rules while the client is handling connections.
Add an exact-match rule

In Config, open the editor for the active configuration and find the [Rule] section. Add one DOMAIN rule for the confirmed target before any broad rule that would match it and before FINAL, then save.
Start a new connection

Make sure the edited configuration is still active, and reconnect if needed. Close and reopen the target page or app, then check the client's connection log for the domain's action and match details.
Check the result and roll back if needed

Test essential features individually, including login, page content, images, and playback. If something breaks, remove the rule you just added and save, then reconnect. Avoid changing DNS, servers, and multiple groups of rules at once.

Check two things: whether the target connection matched REJECT and whether essential features still work. A missing page element is only an observation, not proof that the rule is correct. Temporary server issues, app caches, and resource timeouts can look similar. Conversely, an old image may remain visible because the local cache has not expired; that does not mean a new request got through.

Limits of blocking: same-domain content, encrypted paths, and embedded resources

Basic domain and IP rules do not need to read the full webpage, but that also means they cannot make decisions based on page content. HTTPS encrypts information such as request paths, query parameters, and request bodies. A domain rule cannot identify and filter a complete encrypted URL. Whether the client can determine the destination domain also depends on the connection method, resolution path, and available connection metadata.

Different paths on the same domain: If example.com/article and example.com/promo use the same host, DOMAIN cannot reject only the latter path. Switching to an IP rule does not provide path-level matching either.
Multiple requests on one connection: HTTP/2 and HTTP/3 can carry multiple requests over a single connection. REJECT cannot pick out one page component within that connection; rejecting it may also affect other resources carried over it.
Resources bundled with an app: Images, interface elements, and text already stored in the app do not need a new remote connection. Network rules cannot remove this local content.
Content combined by the server: If an API returns page content and other content together in one response, rejecting that API may make the page content disappear too. There is no guarantee that only part of the response can be kept.
Shared infrastructure: Multiple services may share a CDN or IP address. If rejecting an address range makes other sites unavailable, narrow or remove the IP rule first rather than expanding the scope.

Even when a connection matches REJECT, an app may show a placeholder, an error, cached content, or retry using another domain. Blocking a connection and changing the page layout are two different things. If the target shares infrastructure with payments, account verification, or media APIs, prioritize essential features instead of trying to eliminate every failed request.

Troubleshooting: did the rule miss, or can the target not be handled separately?

Why does the site still open after I added a REJECT rule?

First, check Home → Global Routing → Config, then confirm the file actually active in Config. Check whether the rule comes after a matching DIRECT rule, policy-group rule, or FINAL. Reconnect and review the connection log; do not judge by cached content still on screen.

Can I block one URL without affecting other pages on the same domain?

DOMAIN and DOMAIN-SUFFIX match domains only; pasting a full URL into the domain field will not filter by path. First check whether the resource uses a separate host. If only the path differs, do not broaden the domain rule, or you may also block normal traffic to the same domain.

What should I do if login and images stop working after adding a rule?

Remove the last rule and reconnect first, then confirm that the affected features work again. If you used DOMAIN-SUFFIX or IP-CIDR, check whether it covers a shared host or address. Use a narrower DOMAIN rule only if the connection log confirms a separate destination.

Do local rules update automatically when I refresh a subscription?

A server subscription under Subscribe in Home and a configuration file in Config are separate items. Refreshing the server list does not update local rules, while a remote configuration update may overwrite manual changes. Check which item was updated and which configuration is active, and keep a copy of local edits.

Do not use Settings → On Demand to check whether a rule matched. On Demand controls when to request a connection under certain conditions; REJECT determines how a connection is handled once it reaches rule evaluation. If the connection state changes on its own during troubleshooting, check the On Demand conditions too, but do not treat them as a rule editor.

When to keep a rule: clear matches, acceptable side effects, and an easy rollback

More rules do not necessarily mean better rule maintenance. Every rule you add should have a clear target, a reproducible result, and a way to undo it. Do not add broad rules from unknown sources—especially rules rejecting an entire IP range or a wide root domain—if you cannot explain what they do.

Keep the configuration from before the change, and note the target domain and reason for each new rule.
After adding a rule, check the log for new connections, then test accounts, payments, playback, and other features you rely on.
Recheck rules when an app or site changes its resource domains; a rule that worked once is not guaranteed to keep working.
Before updating a remote configuration, check whether it will overwrite local changes. After updating, confirm which configuration is active.

Shadowrocket is a closed-source commercial app obtained through the App Store, primarily used on iPhone and iPad, and developed by Shadow Launch Technology Limited. A one-time app purchase is not a service plan. This guide does not provide connection services; get subscription links from your service provider. Check the App Store listing for pricing, system requirements, and purchase availability.