Shadowrocket REJECT 规则怎么写:屏蔽原理、匹配顺序与能力边界

一、REJECT 在哪里生效：先匹配目标，再执行策略

一条规则要回答两个问题：请求是否符合匹配条件，符合后采取什么策略。例如 DOMAIN-SUFFIX,example.com,REJECT 中，DOMAIN-SUFFIX 是匹配类型，example.com 是匹配值，REJECT 才是动作。命中后该连接被拒绝，不会因为它失败就继续尝试下一条规则。

这条流程的前提是目标流量进入 Shadowrocket 的处理范围。连接开关关闭、流量绕过隧道，或者当前路由模式不使用这份规则时，编辑 REJECT 都不能直接改变该请求的去向。因此，验证顺序应当是连接状态、路由模式、配置文件、命中规则，而不是先批量增加屏蔽条目。

REJECT 主要影响网络请求，不负责删除页面中已经显示的文字、图片占位或应用本地内容。被拒绝的请求可能表现为资源加载失败、图片空白、应用重试或错误提示。具体表现取决于应用自身的错误处理，不能把某一种页面变化当作所有应用都会出现的结果。

二、REJECT 规则语法：域名优先，IP 范围谨慎使用

只拦截一个完整主机名时使用 DOMAIN；需要覆盖一个域名及其下属子域时使用 DOMAIN-SUFFIX。匹配值填写主机名，不带 https://、端口、斜杠路径或查询参数。例如，想匹配 https://ads.example.com/banner 的主机，应填写 ads.example.com，而不是整段地址。

DOMAIN-SUFFIX,example.com,REJECT 可以覆盖 example.com 与 img.example.com，但不等于任意包含这串字符的域名。只想拦截一个资源主机时，不要直接扩大为整个主域；登录、图片、接口可能分布在同一主域的不同子域下。

IP-CIDR 匹配 IPv4 地址或网段，/32 表示单个 IPv4 地址，/24 表示一个包含 256 个地址的网段。对共享基础设施使用大网段 REJECT，可能同时影响多个无关域名。域名背后的地址也可能变化，因此记录一次解析结果后长期屏蔽该 IP，并不能稳定等同于屏蔽那个域名。

三、规则匹配顺序：精确例外在前，FINAL 在后

在按配置规则处理的情况下，规则自上而下检查，首次命中的规则决定策略。后面更精确的条目不会自动覆盖前面已经命中的宽泛条目。最常见的错误是先写整个域名后缀的 REJECT，再把需要保留的子域放在后面；这样例外永远没有机会生效。

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.8/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

在这段顺序演示中，account.example.com 先命中第一条，不再交给第二条；img.example.com 才会被后缀规则拒绝。GEOIP,CN,DIRECT 根据目标 IP 的地理归属数据库进行匹配，不是根据网页语言判断。它放在 REJECT 前面时，符合其条件的请求可能先被放行。

FINAL 是兜底规则，没有域名匹配值。这里使用 FINAL,DIRECT 仅为了使示例完整，不代表应把你原配置的最终策略改为 DIRECT。实际操作时保留已有的最终策略，只把验证过的精确规则插入合适位置；同一份配置中也不要为了追加屏蔽项而重复添加 FINAL。

四、在 Config 中修改并验证：一次只增加一条

以下按 Home、Config、Settings 的界面结构说明检查位置，具体编辑入口的呈现以当前应用界面为准。先保留当前可用配置的副本，再编辑正在选中的 Config。不要只凭文件名称判断它正在使用，也不要把订阅列表更新误认为配置规则已经更新。

1. 确认使用模式。在 Home 检查连接状态与 Global Routing。验证配置规则时选择 Config；Proxy、Direct 不作为本文规则命中的验证模式。若使用 Scene，应先核对当前场景实际采用的路由设置。
2. 确认目标配置。进入 Config，核对当前选中的文件，保留副本后找到 [Rule] 段。已有此段时编辑其中的条目，不要直接在文件末尾另起一套重复结构。
3. 增加最小规则。先选择一个确定需要拒绝的完整主机名，用 DOMAIN 规则放在相关宽泛规则之前，并保持原有其他策略不变。
4. 保存并应用。确认保存后的文件仍是当前所选配置，按界面提示应用。若需要重新建立连接，留意其他正在进行的网络任务会受影响。
5. 重新发起请求。关闭并重新打开目标页面或相关应用，尽量建立新连接。记录目标域名、命中的规则与策略；若日志未显示足够信息，不要仅凭页面空白推断已命中 REJECT。
6. 做单变量回退。移除刚添加的这一条，保存并重新测试相同操作。对比前后现象，再决定保留、缩小范围或继续排查。

已经建立的连接、浏览器缓存和应用本地缓存，都会让规则修改后的外观与预期不一致。优先重新发起目标请求，而不是连续修改多项设置。记录中应区分“新请求被拒绝”“没有产生新请求”和“请求已成功但画面未变化”，这三种情况需要不同的下一步操作。

五、屏蔽能力边界：同域内容、缓存与共享 IP

域名规则只能按它能识别的目标信息进行分流。若正常接口和待屏蔽内容使用同一个主机名，仅 URL 路径不同，DOMAIN 与 DOMAIN-SUFFIX 不能把两者分开。把这个主机名设为 REJECT，往往会连同正常接口一起拒绝。

• HTTPS 路径不是域名条件。https://api.example.net/feed 与 https://api.example.net/banner 的主机名相同。不能在 DOMAIN-SUFFIX 后加 /banner 来实现路径过滤，443 端口本身也不能区分这两类业务。
• 本地内容不产生可拦截请求。已经下载的资源、离线页面和应用包内的内容，不会因为新增网络规则立即消失。
• 共享 IP 不能精确代表一个站点。一个 IP 可能承载多个域名。优先验证可识别的域名规则，不要为了覆盖某个资源就直接拒绝整个地址段。
• 连接信息不总是完整。直接使用 IP 的请求不能仅靠域名条目匹配；域名信息是否可用还取决于实际解析与连接路径，需要结合连接记录判断。
• 服务端资源位置会变化。目标可能更换域名、地址或请求方式。旧条目没有命中，应重新核对请求目标，不要盲目扩大到整个主域。

因此，REJECT 可以用于拒绝明确的目标连接，但不能承诺清除所有推广内容，也不能保证被拦截后页面布局仍然完整。换用 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 等协议，不会让 DOMAIN-SUFFIX 自动具备读取并筛选网页内容的能力；出站协议与规则匹配承担的是不同职责。

六、常见问题：没生效、误拦与更新后变化

长期维护时，为每次修改记录目标主机、添加原因和回退方式。发现误拦时先恢复可用状态，再分析目标请求；不要同时改 DNS、出站协议和整套规则，否则难以判断究竟是哪一步改变了结果。需要继续定位时，可按排查手册核对当前配置与连接记录。

本文以用户已有自己的服务商与订阅为前提，只说明本地规则的管理方法。本站不提供、不销售、不推荐节点、订阅或连接服务。客户端买断 ≠ 线路套餐，添加 REJECT 也不会生成新的连接配置。