Shadowrocket REJECT 规则写法:屏蔽原理、匹配范围与做不到的事

一、REJECT 的作用位置：拒绝连接，不编辑页面

Shadowrocket（小火箭）的规则由匹配条件和目标策略组成。REJECT 位于策略位置，表示拒绝命中的请求；它不是一种协议，也不是必须另行添加的服务器。规则生效的前提，是相关流量进入 Shadowrocket 的处理路径，并采用当前配置的规则进行判断。

域名规则判断的是目标域名，而不是网页里的文字、图片含义或按钮位置。若某个页面单独从一个域名加载统计资源，拒绝该域名可能阻止相应资源获取；若正文、登录和图片都依赖同一个域名，拒绝它也可能使这些功能一起失败。规则并不能自动区分哪些响应是用户需要的内容。

被拒绝后的外观由发起请求的应用决定，可能是空白区域、加载失败、重试提示，也可能保留旧内容。不能仅凭“页面还在显示”判定规则没有执行，也不能把一次加载失败直接归因于 REJECT；网络中断、DNS 异常和服务器错误也可能产生相近现象。

二、基本语法：先用 DOMAIN，再决定是否扩大范围

普通域名规则的结构是“规则关键字、匹配内容、策略”，各字段以英文逗号分隔。下面是一个独立的教学片段：第一条只拒绝指定主机，第二条拒绝指定后缀及其子域名，最后一条让其余请求直接连接。实际使用时应把需要的规则合并到已有配置，不要用这段内容整体替换原来的分流设置。

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

不要在 DOMAIN 或 DOMAIN-SUFFIX 的匹配内容中填写 https://、端口、路径或查询参数。https://example.com/banner?id=1 是 URL，不是域名；把整段写入域名规则，并不会获得按路径屏蔽的能力。

三、规则顺序与 Global Routing：写对不等于正在使用

在 Home 中检查 Global Routing。验证本地配置中的普通分流规则时，应选择 Config；Proxy 与 Direct 是全局路由姿态，不能拿它们的结果证明 Config 中的 REJECT 规则有效。Scene 需要结合实际场景配置判断，不能简单当作 Config 的同义项。随后在 Config 确认选中并启用了刚刚修改的配置。

1. 在 Config 保存当前配置副本，再打开需要修改的本地配置。
2. 在 [Rule] 内添加一条范围明确的 REJECT 规则，避免重复创建多个同名段落。
3. 把例外规则放在可能覆盖它的宽泛规则之前，保持 FINAL 位于规则末尾。
4. 保存并确认当前使用的是修改后的配置，回到 Home 核对 Global Routing 为 Config。
5. 重新发起目标请求，结合请求记录中的目标、策略和命中规则检查结果。

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

这个例子先为 account.example.com 设置 DIRECT 例外，再拒绝其余匹配 example.com 后缀的请求。普通规则按从上到下的顺序匹配，首条命中后采用对应策略；如果把宽泛的后缀规则移到前面，下面的例外就无法挽回已经作出的判断。

四、DOMAIN-SUFFIX 与 URL Rewrite 的边界

DOMAIN-SUFFIX 不检查 HTTP 路径。假设同一主机同时提供 /article/ 和 /banner/，域名规则无法只阻止后者。URL Rewrite 面向可见的 HTTP 请求 URL，可以按其支持的匹配和处理方式工作，但不能因此推导出“所有 HTTPS 路径都能直接读取”。

HTTPS 的路径与查询参数受 TLS 保护。需要检查这部分内容时，通常涉及为相应主机正确配置 HTTPS 解密、证书安装与信任；仅添加一条 URL Rewrite 不会自动完成这些条件。部分应用使用证书固定等机制，可能不接受这类处理。HTTP/3 等传输路径也需要单独核对支持情况，不能仅按端口推断能否改写。

证书与 HTTPS 解密会改变信任边界，不应为了尝试一条屏蔽规则就扩大到所有主机。本文不提供通配解密配置；当不能确认作用范围时，优先保留精确域名规则，或使用目标应用自身提供的内容设置。

五、IP-CIDR 与 GEOIP：地址匹配不是内容分类

目标可能直接使用 IP 地址，也可能使用共享的内容分发基础设施。此时应区分“域名规则没有获得可匹配的主机名”和“IP 规则范围过大”两种问题。GEOIP 判断地址所属地区，IP-CIDR 判断地址是否位于指定网段；两者都不能判断某个响应是不是广告或统计数据。

[Rule]
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,DIRECT

192.0.2.0/24 是文档示例网段，不是建议屏蔽的实际目标。no-resolve 表示不为这条 IP 规则主动触发域名解析；已有可用目标地址时仍可能按地址匹配。它不表示禁用所有 DNS，也不表示可以把 IP 规则变成域名规则。

• 同一 IP 可能承载多个域名，拒绝它可能同时影响正常图片、登录接口或其他网站。
• 同一域名可能对应多个 IPv4、IPv6 地址，只处理一个 IPv4 地址不等于完整覆盖该域名。
• GEOIP 的地区结果不描述内容用途，不适合作为“整类不需要内容”的替代标签。
• DNS、缓存和连接复用会影响观察结果，应结合新请求记录判断，不能只看一次解析结果。

六、验证与回退：用请求记录建立可重复的判断

测试时一次只改变一个条件。先保存规则未修改时的页面表现，再添加一条规则，重新打开目标页面或触发对应操作。若应用复用了现有连接，新增规则未必能在旧连接上体现；若内容已经缓存，则可能完全没有新请求。必要时关闭目标应用后重新打开，并以新产生的请求记录为准。

1. 确认目标：核对实际请求主机，注意跳转后主机可能变化，不要只照抄浏览器地址栏。
2. 确认接管：核对连接状态与 Global Routing，确保测试请求走当前 Config 的处理路径。
3. 确认命中：查看新请求是否采用 REJECT；没有命中时先查规则顺序、域名拼写和当前配置。
4. 确认影响：检查登录、图片、播放与支付等正常功能，不仅检查目标区域是否消失。
5. 确认可回退：删除或停用刚添加的条目，重新发起请求；若问题随之恢复，再缩小匹配范围。

不要使用一次延迟测试替代内容请求验证。连通性测试成功，只能说明相应测试目标的结果；它既不证明目标域名命中了 REJECT，也不能证明某个页面路径已被处理。若需要整理排查材料，保留目标主机、命中策略和操作顺序即可，分享前移除订阅地址、令牌和其他凭据。

七、常见问题：规则生效后仍看见内容怎么办

最终保留的规则应当同时满足三个条件：匹配目标明确、请求记录可核对、正常功能可恢复。规则数量多不代表覆盖更准确。对无法独立区分的内容，停止扩大范围，比依靠大量猜测性后缀规则更便于维护。