Shadowrocket（小火箭）的 REJECT 是规则命中后的拒绝策略，不是页面内容编辑器。本文适合已经有可用配置、准备添加域名屏蔽规则的用户：先确认 Config 模式与规则顺序，再用单个域名验证命中，最后通过撤销对照区分规则误伤、缓存和页面自身行为。涉及订阅时，均以用户已有自己的服务商与订阅为前提；订阅从你的服务商处获取。
一、REJECT 在规则链中的位置
在按配置分流的场景中，Shadowrocket 根据连接可用的信息匹配规则。匹配条件与执行策略是两个部分：DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等决定“是否命中”，末尾的 REJECT 决定“命中后拒绝”。它不是一种协议，也不需要额外选择一条代理线路才能执行。
这里描述的是命中 REJECT 的分支。若命中的是 DIRECT，连接走直连；若命中的是配置中有效的代理策略，连接走相应出站。规则自上而下检查，命中即按对应策略处理，不会再到后面寻找一个“更合适”的结果。因此，排查时既要看有没有写 REJECT，也要看请求是否先被前面的规则接走。
- 先确认路由姿态：在 Home 检查
Global Routing → Config，让本次测试使用当前配置的规则。不要用 Proxy 或 Direct 的全局测试结果推断 Config 规则是否正确。 - 再确认配置：到 Config 核对当前启用的配置文件。编辑另一个未启用文件，不会改变正在使用的规则。
- 最后确认新请求：已建立的连接可能继续复用。修改后重新建立连接，再重试目标页面，比仅在原页面轻点刷新更便于判断。
二、从精确域名开始写规则
先用 DOMAIN 限定一个主机名，再考虑扩大到 DOMAIN-SUFFIX。例如只想拒绝 metrics.example.com，精确规则不会同时拒绝 www.example.com；而 DOMAIN-SUFFIX,example.com,REJECT 会覆盖根域名及其子域名，可能连登录、图片和接口一起阻断。以下域名仅用于语法说明，不代表实际屏蔽目标。
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,blocked.example.org,REJECT
FINAL,DIRECT这是一段规则结构示例，不是可以替换现有文件的完整配置。将需要的规则加入已有的 [Rule] 段，不要重复创建该段；保留原配置所需的其他规则和兜底策略。示例中的 FINAL,DIRECT 只展示末尾位置，不意味着所有用户都应把自己的 FINAL 改为 DIRECT。
精确拒绝
- 规则类型
DOMAIN- 匹配值
metrics.example.com- 执行策略
REJECT- 完整写法
DOMAIN,metrics.example.com,REJECT
匹配值只写主机名，不附带协议、端口或页面路径。
后缀拒绝
- 规则类型
DOMAIN-SUFFIX- 匹配值
blocked.example.org- 执行策略
REJECT- 完整写法
DOMAIN-SUFFIX,blocked.example.org,REJECT
包含该域名及其子域名；扩大范围前先确认正常业务是否共用。
不要把完整网址直接放进 DOMAIN 条件。例如页面地址中的 /banner/image 是路径，不是域名的一部分；:443 是端口，也不属于主机名。使用这些域名规则时，即使同一主机同时提供 HTTPS 443 和 HTTP 80 服务，也不能靠 DOMAIN 条件只区分其中一个端口。
三、用顺序检查解释“规则写了却没拦住”
规则并不按“越具体越优先”自动重排。假设配置先出现 DOMAIN-SUFFIX,example.com,DIRECT，随后才写 DOMAIN,metrics.example.com,REJECT，访问该子域名时会先命中前面的 DIRECT。后面的精确规则虽然更窄，仍然没有执行机会。
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECT上例把明确的拒绝目标放在宽泛直连规则前面。若需要保留某个子域名，则应把该子域名的允许规则放在相应后缀拒绝规则之前。不要同时添加多条相互覆盖的规则后只凭页面外观判断；先确认目标连接命中的具体规则与最终策略。
判断：先修正顺序，再扩大屏蔽范围
若目标连接命中了前面的 DIRECT 或代理策略，先移动那一条精确 REJECT 规则并复测；不要通过扩大到整个根域名来掩盖顺序问题。
GEOIP 与 IP-CIDR 属于基于目标 IP 的匹配条件，不应拿来替代已经确认的精确域名条件。多个网站可能共享一个 IP，按地址段拒绝会影响更大范围；域名规则能否匹配也取决于该连接是否具有可用的域名信息。只有 IP 的连接不能当然地视为一定会命中某条 DOMAIN 规则。
四、同域名内容、缓存与页面留白的边界
REJECT 能拒绝匹配到的连接，但不会理解一个网页区域是正文、推广位还是播放器。假设同一个 www.example.com 同时返回文章接口和推广接口，使用 DOMAIN 或 DOMAIN-SUFFIX 无法只拒绝其中一个路径；直接拒绝这个域名会同时影响正常内容。“拦不住同域名内容”准确地说，是无法仅凭这类域名规则选择性地区分它们。
| 请求形态 | 可以做到 | 不能据此保证 |
|---|---|---|
| 独立资源域名 | 拒绝命中该域名规则的新连接 | 页面其他域名不会提供替代内容 |
| 同域名不同路径 | 拒绝整个匹配域名 | 只移除其中一个路径的内容 |
| 页面已缓存资源 | 阻止后续匹配的新请求 | 立即删除本地已经保存的资源 |
| 服务端合并返回 | 拒绝承载该响应的连接 | 在响应内部只去掉指定片段 |
| 页面预留区域 | 阻止该区域的远程资源请求 | 自动调整页面排版并消除空白 |
HTTPS 下的路径和响应正文受到加密保护，普通域名规则并不以这些内容为判断依据。添加更多 DOMAIN-SUFFIX 条目也不会让它获得页面元素识别能力。若浏览器已经把资源留在内存或本地缓存里，即使新请求被拒绝，原来的图片仍可能显示。
五、按单变量步骤验证并保留回退
测试前先保存当前可用配置的副本，记录新增规则及原始顺序。不要同时更换网络、切换代理、刷新订阅并添加一整组拒绝规则，否则即使页面行为变化，也无法确定是哪项操作造成。下面的步骤适用于已有正常连接、只验证一个拒绝目标的情况。
- 建立基线：保持同一网络与同一配置，打开目标页面，记录能否登录、图片能否加载、播放是否正常等具体表现。
- 定位目标：在连接记录中找到相关请求，核对目标主机名、匹配规则和执行策略。一个页面会访问多个域名，不能仅凭域名看起来像统计服务就认定可以屏蔽。
- 只改一条：在 Config 当前启用配置的
[Rule]段加入一条精确 DOMAIN 规则，置于可能覆盖它的宽泛规则与 FINAL 之前，保存并确认配置生效。 - 重建连接：重新连接后再次打开目标页面，必要时关闭旧标签并用新会话测试。分别记录是否命中 REJECT，以及登录、图片、视频等功能是否受影响。
- 执行撤销对照：暂时移除刚添加的规则，再重建连接并复测。若异常随规则出现、随撤销消失，应优先视为该规则造成的误伤。
- 保留最小范围：验证有效且没有影响所需功能后，再保留该条规则。需要覆盖更多子域名时逐步扩展，不直接拒绝整个共享域名或地址段。
订阅中的服务器信息与当前 Config 中的分流规则不是同一项内容。订阅更新后出现行为变化，应分别核对所选连接与当前配置，而不是假定更新一定覆盖或保留了本地规则。通过远程地址更新配置文件时，也要确认本地修改是否仍在；回退副本用于恢复，不应在未核对差异时反复覆盖。
六、常见现象与处理顺序
已经看到 REJECT，为什么页面上还有图片？
先核对图片实际使用的主机名是否就是被拒绝的目标，再关闭旧页面，用新会话复测。图片可能来自缓存、其他域名或页面响应内嵌内容。不要为了消除一张仍显示的图片，直接把整个站点的根域名加入 REJECT。
加规则后登录按钮失效，该改哪里？
先撤销最近增加的拒绝规则并重建连接，确认登录是否恢复。若恢复，检查认证接口是否共用了被拒绝的域名；将宽泛 DOMAIN-SUFFIX 缩小为已验证的 DOMAIN。无法按域名分离正常与目标请求时，保留正常功能，不继续扩大拒绝范围。
规则完全没反应，是不是要换协议？
先检查 Home → Global Routing → Config，再到 Config 确认启用文件、规则顺序及保存结果。Shadowsocks、VMess、VLESS、Trojan 等出站协议与“是否先命中 REJECT”不是同一个问题；不要先更换协议来处理规则匹配错误。
开启 On Demand 就能让屏蔽一直有效吗？
Settings → On Demand 用于配置按条件建立或断开连接，不会替代 Global Routing 的选择，也不会替你修正规则顺序。先手动验证 Config 下的拒绝规则，再检查 On Demand 条件是否让测试网络处于预期连接状态。
最终保留规则的标准应是：目标新连接确实命中 REJECT，所需功能仍可使用，并且可以通过撤销恢复原行为。REJECT 适合做边界明确的请求拒绝；页面级内容清理、响应内容筛选与布局整理不属于这些域名规则能够保证的结果。更多基础操作可查阅使用说明，规则术语可查阅名词解释。