本文适合已经有可用配置、准备调整屏蔽规则的 Shadowrocket（小火箭）用户。先在 Home 核对 Global Routing，再到 Config 检查当前配置的 [Rule]：用 DOMAIN 精确匹配、用 DOMAIN-SUFFIX 覆盖子域名，把例外放在屏蔽规则之前，并通过请求记录验证。文中的域名与地址只用于语法教学，不代表可用服务。
先核对 Home 与 Config：REJECT 在哪里生效
在 Home 中查看 Global Routing，进行本文的规则验证时选择 Config，再到 Config 确认当前使用的配置文件。打开该配置的编辑界面，检查 [Rule] 段。只把规则写进某个文件而没有启用该文件，不会改变当前连接的处理方式；同样，Home 的连接开关关闭时，也不能用浏览结果判断这份规则是否生效。
REJECT 是规则匹配后采用的策略，不是规则类型，也不是服务器名称。规则先判断请求是否符合条件，符合时才执行拒绝处理。它不需要把请求发送到某台代理服务器后再拒绝，也不会删除网页已经保存在本地的内容。
验证入口
- Home
- 确认连接开关已打开
- Global Routing
- 选择 Config
- Config
- 确认启用的是刚修改的配置
- [Rule]
- 检查规则顺序与最终策略
先确认配置参与请求处理，再判断规则本身是否正确。
Global Routing 姿态
- Config
- 按当前配置中的规则分流
- Proxy
- 全局代理，不用于验证本文的规则分流
- Direct
- 全局直连，不用于验证本文的规则分流
- Scene
- 按场景设定工作，需另行核对当前场景
排查期间固定使用 Config，避免场景变化干扰验证。
Settings → On Demand 管理按条件建立或断开连接的行为，它不替代 [Rule] 中的域名匹配。若测试时连接状态反复变化，先检查 On Demand 的条件；不要通过反复添加 REJECT 规则去处理连接本身没有保持的问题。
理解匹配顺序：命中前面的规则后就停止
在常规规则分流中，规则按从上到下的顺序检查。一个请求命中某条规则后，就采用该条规则指定的策略，不会继续向下寻找“更合适”的策略。因此，精确放行通常放在宽泛屏蔽之前，而 FINAL 用于承接前面没有匹配到的请求。
[Rule]
# 先允许这个精确域名直连
DOMAIN,help.example.com,DIRECT
# 再拒绝 example.com 及其子域名
DOMAIN-SUFFIX,example.com,REJECT
# 本片段中其余请求直连，仅作语法演示
FINAL,DIRECT在这组三条规则中，help.example.com 先命中第一条并使用 DIRECT；media.example.com 命中第二条并使用 REJECT；其他未匹配的域名由 FINAL 接管。如果把第二条移到第一条上方，帮助页面也会被拒绝，因为它同样属于 example.com 的子域名。
选择规则范围：DOMAIN 与 DOMAIN-SUFFIX 的写法
只想屏蔽一个明确的主机名时，优先使用 DOMAIN。需要覆盖主域名及其所有子域名时，再使用 DOMAIN-SUFFIX。两种写法的目标字段都填写域名本身，不带协议、端口、路径或查询参数；例如不能把整个 https://ads.example.com/banner 当成域名字段。
| 规则示例 | 匹配范围 | 使用前检查 |
|---|---|---|
DOMAIN,ads.example.com,REJECT | 精确匹配 ads.example.com | 确认请求记录中的主机名完全一致 |
DOMAIN-SUFFIX,example.com,REJECT | 匹配 example.com 及其子域名 | 确认登录、图片与接口是否共用该域名后缀 |
IP-CIDR,192.0.2.7/32,REJECT,no-resolve | 匹配单个 IPv4 目标地址 | 此处是文档示例地址，不是实际屏蔽目标 |
IP-CIDR 根据 IP 地址范围匹配，GEOIP 根据 IP 地理归属匹配，两者都不等同于域名后缀匹配。示例中的 no-resolve 表示不为这条 IP 规则额外触发域名解析；若请求此时只有域名，不能把它理解为一定会命中该地址规则。对共享地址直接使用 REJECT，还可能影响同一地址上的其他站点。
先精确匹配，再扩大范围
先用请求记录中确认的单个主机名建立 DOMAIN 规则；只有确认其他子域名也应拒绝时，才改成 DOMAIN-SUFFIX，避免一次屏蔽整个业务域名。
明确适用边界：REJECT 不能按网页元素筛选
REJECT 适合拒绝能够独立识别的网络目标，例如页面单独请求的某个域名。它不是网页元素过滤器：当正文、图片和需要屏蔽的内容共用同一主机名时，简单的域名规则无法只区分其中一个路径。拒绝这个域名，可能同时让正文接口、登录验证或静态资源加载失败。
- 同域名不同路径：
example.com/news与example.com/banner不能靠 DOMAIN 规则分别处理；路径不是该规则的匹配字段。 - 内容已经缓存：命中 REJECT 后，页面仍可能显示先前缓存的图片或文字。应观察新请求的处理记录，而不是只看旧页面是否消失。
- 目标域名变化：页面可能从另一个主机名重新请求内容。应核对新的实际请求，不要凭相似名称连续扩大后缀范围。
- 只出现目标 IP：当匹配阶段没有可用域名信息时，不能假定 DOMAIN-SUFFIX 会命中；先检查记录中的目标类型。
- 共享基础设施：一个 IP 可能承载多个域名。改用 IP-CIDR 并不天然更准确，宽网段屏蔽尤其需要谨慎。
HTTPS 的加密并不意味着所有域名规则都失效，但 REJECT 本身也不会解密并检查网页正文。不要为了屏蔽一个网络目标就先开启 HTTPS 解密或安装证书；本文的规则验证不需要这些操作。也不要把网页里的空白占位视为规则失败：网络请求被拒绝后，页面布局未必会自动移除原有区域。
验证与回退：从实际请求定位误拦
在 Config 保存修改后，重新确认该配置处于启用状态。回到 Home 核对 Global Routing 为 Config，并在需要时重新建立连接，然后重新打开目标页面以触发新请求。在应用内的请求记录中查看目标域名或 IP、处理策略及可见的规则信息；记录入口与字段以当前界面显示为准。
- 先留原始配置：修改前保留可恢复的副本，并记下新增规则的位置，确保可以撤销，而不是只能继续追加规则。
- 每次只改一项：先添加一条精确规则，保存并验证；不要同时改 Global Routing、DNS 与多条 IP 规则，否则难以定位变化来源。
- 看新请求是否出现：如果记录里没有目标请求，先重新加载页面或重新打开相关功能，避免把缓存、旧连接误认为新的规则结果。
- 对照实际策略：记录显示 DIRECT 或其他策略时，检查是否被更靠前的规则命中；显示 REJECT 但页面仍有内容时，检查缓存与其他请求域名。
- 最小范围回退：先撤销最近新增的规则。确定必须保留后缀屏蔽时，再把精确例外放到它上方，并使用原有配置需要的放行策略。
放行不等于必须使用 DIRECT。DIRECT 表示直连；如果某个服务在原配置中应走代理，就应恢复它原本使用的策略。前文的 DIRECT 只是展示例外顺序，不能机械套用到所有业务。若需要恢复的策略名称引用了策略组，还要确认该名称在当前配置中存在。
写了 REJECT，为什么还是能打开？
先到 Home 核对 Global Routing 是否为 Config，再到 Config 核对启用文件。重新触发请求后看实际主机名；若命中了前面的放行规则，就调整顺序，而不是重复添加同一条 REJECT。
加完规则后，登录按钮一直转怎么办？
撤销最近新增的规则，重新打开登录流程，并检查请求记录中的验证或接口域名。若是宽泛的 DOMAIN-SUFFIX 误拦，缩小为精确 DOMAIN，或在它前面加入必要的精确例外。
Connectivity Test 正常，能证明屏蔽成功吗？
不能。Home 中的 Connectivity Test 用于检查连接可达性，不代表指定域名已命中 REJECT。需要让目标功能发起请求，再核对这一次请求的处理记录。
更新订阅后，手写规则会保留吗？
先区分 Home 中服务器订阅的更新与 Config 中配置文件的更新。更新服务器列表不等同于编辑 [Rule]；远程配置重新获取则可能替换本地改动。操作前保留副本，更新后核对当前文件与规则位置。订阅链接从你的服务商处获取。
最终验收应同时满足两点：目标新请求按预期使用 REJECT，需要保留的登录、图片和接口仍使用正确策略。只确认“某个页面打不开”不足以证明规则准确；可复现的目标、明确的匹配范围和可恢复的配置，才是后续维护的依据。