本文速览

本文适合已能正常连接、准备在 Config 中添加域名屏蔽规则的用户。先区分匹配条件与 REJECT 策略，再按顺序添加精确规则、检查连接记录，最后判断同域资源、缓存与应用内嵌内容是否超出域名规则的处理范围。文中域名和地址均为说明语法的保留示例，不能直接作为实际屏蔽清单使用。

一、REJECT 是匹配后的处理策略，不是内容识别器

Shadowrocket（小火箭）的规则需要分别回答两个问题：连接符合什么条件，以及符合条件后怎样处理。DOMAIN-SUFFIX、DOMAIN、IP-CIDR 属于匹配条件；REJECT 是处理策略。把一个域名写入规则，并不等于识别了网页中的广告、统计代码或视频片段，只是让符合条件的连接被拒绝。

应用发起连接 流量进入隧道 按序检查规则 命中拒绝策略 目标连接失败

上面的流程针对确实经过 Shadowrocket、且由当前规则配置处理的流量。若流量没有进入隧道，规则无法介入；若连接进入隧道但当前采用整体直连或整体代理的姿态，也不能据此判断某条 Config 规则是否生效。排查时先在 Home 核对连接状态，再检查 Global Routing。

拒绝后的外在表现由应用决定：可能显示资源加载失败、空白占位，也可能反复重试。REJECT 不负责删除页面布局，不保证让加载更快，更不代表把某段远端内容改写成另一段内容。

二、DOMAIN 与 DOMAIN-SUFFIX 的写法和边界

域名规则中只填写主机名，不填写 https://、端口、路径或查询参数。假设目标请求为 https://ads.example.com:443/banner?id=1，需要核对的是 ads.example.com。其中 443 是连接端口，/banner 是路径，二者都不是 DOMAIN-SUFFIX 的域名参数。

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT

精确主机匹配

关键字
DOMAIN
参数
ads.example.com
策略
REJECT
匹配范围
仅 ads.example.com，不含 img.ads.example.com

首次验证优先使用精确主机名，便于限定影响范围。

域名后缀匹配

关键字
DOMAIN-SUFFIX
参数
metrics.example.com
策略
REJECT
匹配范围
metrics.example.com 及其下级子域名

确认整个域名分支用途一致后，再扩大到后缀范围。

DOMAIN-SUFFIX,example.com,REJECT 会覆盖 example.com 和 api.example.com 等下级域名，但不是任意字符串包含匹配，不应把 notexample.com 当成它的命中对象。也不要写成 *.example.com 来替代后缀参数；按规则语法填写裸域名即可。

三、规则自上而下匹配：例外在前，FINAL 在后

规则顺序会直接改变结果。对同一连接，先命中的有效规则决定处理策略；后面更精确的规则不会自动获得更高优先级。因此，允许访问的例外应放在覆盖它的拒绝规则之前，而宽泛的 IP、地区规则和 FINAL 通常放在相关域名规则之后。

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

此片段仅演示顺序：keep.metrics.example.com 先命中精确例外，其余 metrics.example.com 域名分支再被拒绝。FINAL,DIRECT 只是为了让示例自洽；实际配置应保留原有兜底策略，不要为了添加一条屏蔽规则而把所有未匹配流量改为直连。

规则位置典型问题修正方法
拒绝规则在 FINAL 后连接已被兜底规则处理将拒绝规则移至 FINAL 前
例外在后缀拒绝之后例外主机先命中 REJECT把精确例外移至后缀规则前
宽泛放行在拒绝之前目标先命中放行策略核对命中记录，调整重叠规则的顺序

结论：先查首条命中规则，再增加新规则

如果目标连接已经被更靠前的规则处理，重复添加同一条 REJECT 不会改变结果。先确认当前配置及命中位置，再移动规则或收窄条件。

如果目标是 IP 地址，可以另行使用 IP-CIDR,192.0.2.0/24,REJECT,no-resolve 这样的语法理解地址段匹配；这里的地址段是文档示例。no-resolve 表示不为该条 IP 规则主动触发域名解析，不是关闭设备 DNS。共享 IP 可能同时承载多个无关域名，因此不能因为域名屏蔽没效果，就直接拒绝其整个地址段。

四、按域名屏蔽不能区分同域路径和应用内布局

假设正文接口是 api.example.com/article，推广接口是 api.example.com/promotion。两者使用同一个主机名，DOMAIN 或 DOMAIN-SUFFIX 无法只拒绝后一个路径。把 api.example.com 设为 REJECT，可能连正文、登录状态和评论接口一起阻断。

内容交付方式域名规则能处理什么不能据此承诺什么
独立主机加载素材拒绝该主机的新连接不能保证应用移除空白占位
同一主机的不同路径按主机整体处理不能用域名规则只选中某个路径
推广与正文在同一响应中拒绝整条连接不能从响应内容中挑出某一部分
本地缓存或内置素材没有新连接时无从匹配不能保证已经展示的内容立即消失

HTTPS 通常隐藏 URL 路径和响应正文。即使规则能够获得目标域名，也不等于能读取加密连接里的每个资源。域名级 REJECT 不需要为了拒绝主机去解密内容，但它的能力也就停留在相应的连接范围。本文不把路径处理、响应改写或页面元素隐藏混同为域名规则能力。

五、添加与验证：一次只改一条，保留回退路径

测试应基于已经可正常使用的配置。本文以用户已有自己的服务商与订阅为前提，不提供或推荐任何连接服务。若测试目标是本来就能直接访问的资源，可以保持原有连接方案不变，只观察新增规则造成的差异。

  1. 备份当前配置。在 Config 确认当前选用的文件，保存副本或记录原始内容。不要把整个示例片段覆盖到现有文件上。
  2. 固定路由姿态。在 Home 确认连接已经启用，将 Global Routing 设为 Config，并核对使用的是刚才编辑的配置。
  3. 添加精确规则。先在该配置的 [Rule] 段内添加一条 DOMAIN,ads.example.com,REJECT 形式的规则，把示例主机换成自己记录到的目标主机，并放到相关宽泛规则与 FINAL 之前。
  4. 保存并重新发起请求。重新打开目标页面或应用；必要时重建连接，让新请求按新配置判断。已经建立的长连接和本地缓存不适合作为唯一验证依据。
  5. 核对连接记录。按目标主机查找新请求，查看实际策略是否为 REJECT，同时检查登录、正文、图片和播放等必要功能。
  6. 出现误伤先回退。删除或停用刚加的规则，重新测试。若功能恢复，再决定添加精确例外、收窄到 DOMAIN，还是放弃该域名的整体屏蔽。

若设备启用了自动连接，还应检查 Settings → On Demand，避免测试中连接被自动恢复或切换状态却未被注意。On Demand 决定何时触发连接，不负责调整 REJECT 的匹配优先级，两者需要分开排查。

六、常见问题：规则没命中、内容仍显示与误伤恢复

已经写了 REJECT，为什么网页还是能打开？

先确认拒绝的是网页主机还是某个附属资源主机。只拒绝素材域名时，正文继续打开可能正是预期结果。再核对 Home 的 Global Routing 是否为 Config、当前配置是否选对，以及规则是否放在 FINAL 前。最后查看新连接的实际策略，而不是只看页面整体能否打开。

记录里已经是 REJECT，为什么应用仍显示原来的内容？

重新打开目标页面并检查是否有新的请求。已下载的图片、预加载内容和本地内置素材可以继续显示；应用也可能换用另一个主机。先对照请求时间与目标域名，不要仅凭屏幕上还有内容就继续扩大拒绝范围。

加完规则后不能登录，应该怎么恢复？

先撤销最近添加的规则，重新发起登录。若登录恢复，说明该规则可能覆盖了必要接口。对比登录前后的主机记录，将后缀规则收窄为精确主机规则；只有确认某个主机应当放行时，才在拒绝规则前添加对应的精确例外。

换成另一个代理协议，REJECT 会更准确吗？

不会因为切换 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 就获得按内容识别的能力。REJECT 的命中取决于进入规则处理的流量、可用目标信息与规则顺序。先保持连接方案不变完成规则验证，避免同时修改协议和规则而无法定位原因。

判断一条规则是否值得保留，需要同时满足三个条件：目标新请求确实命中、预期资源受到限制、必要功能没有被误伤。域名不能把需要保留的内容和需要拒绝的内容分开时，应承认域名粒度的边界，而不是不断叠加更宽泛的拒绝项。