本文适合已经使用 Config 分流、希望阻止特定目标连接的用户。先确认 REJECT 的作用位置，再按精确域名、域名后缀和目标 IP 编写规则，最后用连接记录验证命中与误拦截。示例域名仅用于说明语法；实际目标应根据自己的请求记录确定。
REJECT 的作用：阻止命中的连接
REJECT 是策略，不是独立的匹配条件。规则前半部分判断目标是否符合条件，末尾的 REJECT 指定命中后的处理方式。例如 DOMAIN,metrics.example.com,REJECT 表示按完整域名匹配，然后拒绝该请求；它不会自动识别所有统计服务，也不会自动生成域名列表。
这条流程以请求进入 Shadowrocket 的处理范围、且当前使用规则分流为前提。REJECT 不是先向目标发送完整内容、再把返回页面隐藏，而是在连接处理阶段阻止后续通信。请求方可能显示连接失败、重试或超时，具体表现取决于应用自身处理方式，不能仅凭页面提示判断是哪条规则生效。
规则通常自上而下匹配，首条命中的规则决定策略。因此，“写了 REJECT”与“请求实际采用 REJECT”是两件事：前面若已经命中更宽的放行规则，后面的拦截行就没有机会处理这次请求。排查时必须同时看目标、顺序和当前生效的配置。
先核对 Config，再添加最小范围的规则
在 Home 的 Global Routing 中选择 Config，再到 Config 确认正在使用的配置文件。Proxy 与 Direct 不能代替这一步；如果使用 Scene，还需要确认当前场景实际采用的配置与路由方式，不能仅凭某个配置文件里有 REJECT 就认定它正在生效。
- 在 Config 保留当前配置副本，记录原有规则顺序和
FINAL策略，便于恢复。 - 打开正在使用的配置，通过编辑入口找到
[Rule]段。先添加一条完整域名规则，不急于扩大到整组域名。 - 把这条规则放在可能提前命中的宽泛规则之前，同时保留业务必需的精确例外。
- 保存配置并确认其仍处于使用状态。关闭目标应用的旧连接，再重新发起同一操作。
- 查看本次连接对应的目标和策略；只有新请求实际命中
REJECT，才能确认拦截路径正确。
如果配置由远程来源更新，先确认本地修改是否会被后续更新覆盖。订阅与节点从你的服务商处获取；服务器订阅更新与 Config 规则修改不是同一项操作，刷新服务器列表不能证明新规则已经载入。
DOMAIN、DOMAIN-SUFFIX 与 IP-CIDR 的写法
优先选择能够覆盖目标的最窄条件。完整域名适合单个主机，域名后缀适合明确需要一起处理的域名及其子域，IP 网段则适合已确认地址范围的目标。域名字段不填写 https://、路径、查询参数或端口。
按域名匹配
- 完整域名
DOMAIN,metrics.example.com,REJECT- 域名后缀
DOMAIN-SUFFIX,metrics.example.com,REJECT- 匹配差异
- 前者只匹配指定主机；后者还匹配其下级子域。
后缀按域名层级匹配，不是任意文本包含匹配。
按目标 IP 匹配
- 单个 IPv4
IP-CIDR,192.0.2.8/32,REJECT- IPv4 网段
IP-CIDR,192.0.2.0/24,REJECT- 示例用途
- 这里使用文档示例地址，不代表实际拦截目标。
按实际连接地址核对范围，不要把共享地址误当成单一服务。
DOMAIN-SUFFIX,metrics.example.com,REJECT 能匹配 metrics.example.com 和 img.metrics.example.com，但不会匹配 othermetrics.example.com。也不需要写成 *.metrics.example.com；通配符不是这条规则的后缀参数写法。
IP 规则与域名规则不能互相等同。一个域名可能解析到多个地址，同一个地址也可能承载多个域名；客户端还可能改用其他地址或 IPv6。仅拒绝某个 IPv4 地址，不能据此认定相关域名的所有连接都已被阻止。GEOIP 按地址归属匹配，范围更广，不适合代替某个具体域名的精确拦截。
规则顺序：先写例外，再写拦截，FINAL 留在末尾
下面演示一组有意保留例外的规则：允许一个指定主机直接连接，再拒绝同一后缀下的其他主机。示例中的 PROXY 必须是你的配置里可用的策略或策略组名称；若当前配置使用其他名称，应保留原有 FINAL 行，而不是照搬示例兜底。
[Rule]
DOMAIN,health.metrics.example.com,DIRECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,PROXY| 请求目标 | 首条命中 | 结果 |
|---|---|---|
health.metrics.example.com | 第一条 DOMAIN | 采用 DIRECT |
img.metrics.example.com | 第二条 DOMAIN-SUFFIX | 采用 REJECT |
www.example.com | 末尾 FINAL | 采用示例中的 PROXY |
如果把后缀拦截放到第一行，健康检查主机也会先命中 REJECT，后面的 DOMAIN 例外无法再放行。反过来，若在拦截前放入 DOMAIN-SUFFIX,example.com,DIRECT，它会提前放行这些目标。FINAL 本身负责剩余请求，放在拦截前会使后面的规则失去匹配机会。
判断：需要例外时，先缩小规则覆盖范围
先把必需主机的精确规则移到宽泛拦截之前，再重新验证。不要用删除所有 REJECT 的方式处理单个误拦截，也不要用更宽的 DIRECT 规则掩盖顺序问题。
拦截的适用范围与能力边界
REJECT 适合阻止目标清晰、可以按域名或地址区分的连接，例如用户已确认不需要访问的独立资源主机。它的判断对象是连接目标，不是页面里的每一个视觉元素，更不是对所有内容进行语义识别。
- 同域内容不能按路径区分：如果业务请求与不需要的资源都来自
api.example.com，DOMAIN 规则会一起处理；它不能只拒绝其中的/metrics路径。 - HTTPS 不会因此被解密：REJECT 不要求读取加密正文，也不会自动获得页面结构。阻止一个资源连接，不等于删除页面布局中为它预留的空白区域。
- 缓存可能掩盖结果：应用可能直接展示已缓存的图片或内容，这不代表刚刚的请求已成功通过。应结合新连接记录判断，而不是只看屏幕是否改变。
- 已有连接需要单独考虑：规则修改后，已经建立并复用的连接不一定马上按新规则重走匹配流程；测试时应让应用重新建立连接。
- 目标可能发生变化：重试备用域名、地址轮换和共享基础设施都会影响覆盖范围，应从实际记录补充证据，而不是直接封锁整个共享网段。
DNS 解析失败与 REJECT 命中也应区分。前者可能发生在获得目标地址之前，后者应有对应的规则策略证据；看到域名打不开，不能直接归因于 REJECT。另一方面，域名信息是否可用于匹配，取决于实际请求及解析路径；只有地址信息时，需要结合连接记录检查 IP 相关规则，不能假定域名条件一定存在。
写了不生效、误拦截与恢复方法
验证时一次只改一个变量：同一应用、同一动作、同一网络环境，对照修改前后的新连接。下面的问题按“配置是否使用、规则是否命中、结果是否被缓存掩盖”的顺序排查。
规则保存了，为什么目标还是能打开？
先核对 Home → Global Routing 是否为 Config，再检查 Config 中实际使用的文件。随后查看目标的新连接是否被前面的 DIRECT、PROXY 或其他宽泛规则提前匹配；不要仅检查文件中有没有 REJECT 这一行。
显示命中 REJECT，为什么页面还有原来的内容？
退出目标应用后重新进入，区分缓存显示与新请求。检查页面是否从其他域名重新获取资源，并记录这些连接；已缓存内容仍在屏幕上，不能证明命中的请求被放行。
加完后缀规则，登录或图片也失败了怎么办？
先停用刚添加的单条规则并重试，确认关联性。再从失败记录找出必需主机，改用更窄的 DOMAIN 拦截，或在后缀规则前加入精确放行例外；不要直接放行整个父域名。
更新配置之后，之前的拦截为什么消失了？
对照保存的副本检查当前配置的 [Rule] 段，确认本地修改是否被远程内容覆盖。重新加入经过验证的最小规则，并保留原有 FINAL；不要把服务器订阅刷新当作规则恢复操作。
需要回退时，优先撤销最后加入的拦截行，保存后重新建立目标连接；如果已经修改多处且无法确认先后，恢复此前保留的配置副本。保留测试目标、命中规则与恢复结果这三项记录，比反复切换所有设置更容易定位原因。