本文适合已经在 Shadowrocket 中启用配置、希望添加或排查屏蔽规则的用户。先区分“匹配条件”和“处理策略”，再通过最小规则示例检查命中顺序，最后判断同域请求、加密连接和缓存为何限制屏蔽效果。所有域名与地址均为演示值；涉及连接测试时，以用户已有自己的服务商与订阅为前提。
一、REJECT 是处理策略，不是内容识别规则
Shadowrocket（小火箭）中的规则通常同时包含匹配条件和处理策略。例如 DOMAIN-SUFFIX,example.com,REJECT 的前两项决定哪些连接符合条件，末尾的 REJECT 决定命中后拒绝连接。它不会因为页面上出现某个词、某张图片或某种版式，就自动识别并删除对应内容。
在按配置分流的场景中，可以把过程理解为下面五步。这里描述的是规则处理逻辑，不表示客户端总能从每条连接中取得完整域名，更不表示能够读取加密请求的正文。
规则一般自上而下检查，首条命中后执行对应策略。因此，一条写在文件末尾的精确屏蔽规则，可能永远不会被执行：连接已在更靠前的宽泛规则处命中 DIRECT 或其他策略。排查时必须同时查看“匹配到了什么”与“最后执行什么”，不能只搜索文件里是否出现 REJECT。
二、用最小规则核对 DOMAIN 与 DOMAIN-SUFFIX
先在 Config 中备份当前配置，再编辑用于测试的副本。下面片段只展示 [Rule] 的匹配关系，不是可直接替换现有设置的完整配置。示例使用保留的演示域名，不对应任何真实屏蔽对象。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT按此顺序，account.example.com 会先命中精确例外；media.example.com 和根域名 example.com 则由后缀规则拒绝；不属于该后缀的其他连接交给 FINAL。这里选择 DIRECT 只是为了说明逻辑，不代表实际使用时应把所有未匹配流量改成直连。
精确例外
- 关键字
- DOMAIN
- 匹配值
- account.example.com
- 策略
- DIRECT
- 放置位置
- 位于宽泛后缀规则之前
仅允许该主机名；不会自动允许它的下级域名。
后缀屏蔽
- 关键字
- DOMAIN-SUFFIX
- 匹配值
- example.com
- 策略
- REJECT
- 覆盖范围
- 根域名及其子域名
后缀字段不写 https://、路径或端口，也不需要添加星号。
保存后还要确认这个副本已在 Config 中选为当前配置，并在 Home → Global Routing 中选择 Config。不能把 Proxy 或 Direct 当成启用配置规则的等价姿态；使用 Scene 时则需先核对场景最终应用的路由行为。修改后重新建立测试连接，避免沿用修改前已经存在的连接。
结论：先用精确主机名验证，再扩大范围
先添加一条 DOMAIN 规则并检查命中记录；确认目标和影响范围后，再决定是否改用 DOMAIN-SUFFIX。不要一开始就屏蔽整个平台的根域名。
三、REJECT 与 REJECT-DROP：区别在拒绝方式
REJECT 与 REJECT-DROP 都属于拒绝方向的策略，但拒绝的反馈方式不同。通常使用 REJECT 可让连接较快失败；REJECT-DROP 偏向静默丢弃，使发起方等待自身超时。实际错误表现还受 TCP、UDP、应用重试机制以及当前实现影响，不能保证所有应用都立即停止请求。可用策略名称以当前客户端规则编辑器与支持情况为准。
| 策略 | 处理取向 | 需要关注的现象 |
|---|---|---|
REJECT | 拒绝连接，通常较快给出失败反馈 | 应用可能立即报错，或马上尝试备用域名 |
REJECT-DROP | 静默丢弃，等待发起方超时 | 应用可能长时间显示加载，也可能重复发送请求 |
两者都不会把拒绝结果自动变成“页面已正确隐藏”。应用收到失败后，可能留下空白位置、显示错误图标，或启用备用接口。也不要把 REJECT-DROP 理解为更强的域名匹配：若连接根本没命中这条规则，替换末尾策略不会扩大匹配范围。
- 需要验证规则是否命中时，先检查请求记录，不靠加载动画持续时间猜测。
- 出现持续转圈时，先排查被拒绝的是否为登录、鉴权或初始化接口。
- 切换拒绝策略时每次只改一个变量，并重新发起相同操作，记录行为差异。
四、域名屏蔽的边界：同域内容、HTTPS 与共享地址
如果希望拒绝的资源使用独立域名，域名规则通常比较容易划清范围。但当正常内容与目标资源都来自 api.example.com，只是在路径上分别使用 /content 与 /promotion 时，DOMAIN 和 DOMAIN-SUFFIX 无法区分两者。拒绝该主机名，可能连正文、登录与账号状态一起中断。
对常见的 HTTPS 连接，例如目标端口 443，域名规则并不等于解密 HTTP 请求。URL 路径、查询参数和响应正文位于加密内容中，不能通过给域名规则追加路径来获得内容级筛选。本文的规则示例也不涉及 HTTPS 解密。
| 请求形态 | 域名规则能否区分 | 操作边界 |
|---|---|---|
track.example.com 与 api.example.com | 可以按不同主机名分别匹配 | 仍需验证前者是否承担必要功能 |
| 同一主机名下的两个 HTTPS 路径 | 不能仅靠 DOMAIN 区分路径 | 不要把完整 URL 填进域名字段 |
| 多个域名共用一个服务地址 | 按 IP 屏蔽时无法保留域名粒度 | 可能同时影响其他正常服务 |
| 应用读取本地缓存 | 没有新连接时无从匹配 | 页面仍显示不等于规则失效 |
把域名规则换成 IP-CIDR 也不能解决同域内容混合的问题。例如 IP-CIDR,192.0.2.10/32,REJECT 表示拒绝这个演示 IPv4 地址，并不只拒绝某个网站；192.0.2.0/24 的范围则更大。实际服务还可能使用多个地址或 IPv6，随意扩大地址范围既容易误拦，也不保证覆盖完整。
结论：同域混合内容先保留功能，再判断是否值得屏蔽
当正常功能与目标资源共用主机名时，先撤销宽泛拒绝规则恢复功能。只有发现可独立验证的请求域名，才添加范围更小的规则，不用整段地址屏蔽代替内容判断。
五、规则没有效果时，按证据逐步排查
“仍然看到了原内容”并不能单独证明规则失效。可能是应用没有重新请求，也可能是请求转到备用主机名，或者当前连接未经过预期的规则路径。建议保留修改前后的配置副本，并记录测试时间、操作动作、目标主机名与最终策略，便于复现。
- 确认当前配置与姿态。进入
Config确认启用文件，再核对Home → Global Routing → Config。只保存文件而没有启用，不能影响当前连接。 - 重新触发网络请求。保存后断开并重新连接，必要时退出目标应用后再次打开。刷新页面时留意是否真的产生新请求，而不是只读缓存。
- 检查请求记录。在客户端的连接或请求记录中，按测试时间找到目标，核对可见的主机名、目标地址、匹配规则和最终策略。仅看到 REJECT 字样还不够，要确认它对应的是本次目标请求。
- 核对顺序与可见信息。查看是否先命中了更宽泛的放行规则；若记录只有 IP，不能假定 DOMAIN-SUFFIX 一定有可用的域名信息。检查应用是否自行通过加密 DNS 解析，或直接连接地址。
- 做单项对照。临时停用刚添加的一条规则，再重复同一动作。恢复后功能正常，说明该规则与问题有关；接下来缩小匹配范围，而不是继续叠加拒绝规则。
规则顺序还要结合 GEOIP、IP-CIDR 和 FINAL 一起检查。它们不是内容分类器：GEOIP 按地址归属匹配，IP-CIDR 按地址段匹配，FINAL 承接前面没有命中的连接。若宽泛规则先命中，后面的目标域名规则就没有执行机会。
六、常见问题：误拦、缓存与配置更新
加完规则后登录失败，先删哪一条？
先临时停用本次新增的 REJECT 规则并重试登录，确认是否恢复。再查看登录时的请求记录，优先检查覆盖根域名的 DOMAIN-SUFFIX。若已确认某个鉴权主机名必须保留，可在宽泛规则之前添加精确例外，策略沿用原有可用路径，不要未经验证直接放行整个平台。
记录已经显示 REJECT，为什么页面上还在显示？
先确认记录对应的是该页面本次发起的请求，而不是后台其他连接。随后重新打开页面并观察是否出现新连接。已缓存的图片、已下载的内容和应用内置素材不会因连接被拒绝而自动消失；规则也不负责折叠页面占位区域。
应用换了一个域名请求，要把所有新域名都屏蔽吗？
不要按出现顺序批量添加。先对照每个主机名出现时的操作，判断是否与目标功能相关，再一次只测试一个主机名。备用接口可能同时承载正常内容；没有确认用途的登录、支付或同步请求应先保留。
更新订阅以后，自定义 REJECT 为什么不见了？
先区分 Home 中连接条目的订阅更新与 Config 中配置文件的更新，它们不是同一件事。检查当前启用文件是否改变，以及远程配置更新是否覆盖了手工修改。保留本地测试副本与自定义规则清单，每次更新后对照文件内容和规则顺序，不要只凭连接条目还在就判断规则也保留。
判断屏蔽是否适用，最终看三个条件：请求是否经过当前规则路径、客户端是否取得足够的匹配信息、目标能否与必要功能分离。满足这些条件时，使用精确规则并保留回退副本；不能分离时，应接受域名级处理的边界，而不是用更宽的规则掩盖问题。