REJECT 是拒绝匹配连接的策略，不是网页元素过滤器。本文适合已经使用 Config、准备添加屏蔽规则的用户：先确认连接是否经过规则判断，再用单条精确规则测试，最后根据请求记录定位误拦并恢复原配置。示例仅用于解释语法，不是可直接套用的屏蔽清单。
REJECT 的作用：拒绝连接，不是删除页面内容
Shadowrocket（小火箭）中的规则由匹配条件和处理策略组成。条件回答“哪些连接符合要求”，策略回答“命中后怎样处理”。例如 DOMAIN,blocked.example.com,REJECT 表示：当规则判断得到的目标域名与该名称一致时，对这条连接采用 REJECT，而不是继续按后面的规则选择出站。
这条流程的前提是相关流量进入 Shadowrocket 的处理范围，且当前路由姿态使用相应规则。它不等于对设备上一切通信的全局保证，也不意味着网页里所有不想看到的内容都会消失。应用可能保留加载占位、显示错误提示，或者在请求失败后继续重试。
PROXY：把匹配连接交给相应代理出站处理；实际出口还取决于当前选择和配置。DIRECT：让匹配连接直接连接目标，不等于拒绝请求。REJECT：拒绝匹配连接，不是把连接改为直接访问。
因此，判断规则是否生效应看连接是否命中并被拒绝，而不能只看页面上是否留下空白区域。空白、转圈和错误提示都可能是资源获取失败后的页面表现；它们不是 REJECT 自动完成了页面排版调整的证据。
先核对 Global Routing，再检查规则顺序
在 Home 查看 Global Routing。验证当前配置中的规则时，先使用 Config，并在 Config 确认启用的是刚刚编辑的配置。Proxy 与 Direct 是全局处理姿态，不能拿它们的结果直接判断当前配置里的 REJECT 是否正确；使用 Scene 时，还要确认场景实际采用的配置和路由设置。
判断：先证明配置生效，再扩大匹配范围
如果无法确认当前启用的配置，就先停止添加规则；确认 Config 与请求记录对应后，再测试单个目标域名，避免把路由姿态问题误判为语法问题。
规则按顺序判断，命中后采用对应策略，不会为了寻找“更具体”的写法而自动跳到后面。因此，精确例外应放在宽泛规则之前，FINAL 放在最后。下面是一段独立的语法示例，所有示例域名均为说明用途；不要据此改变已有配置的整体出站策略。
[Rule]
DOMAIN,allowed.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY在这个顺序下，allowed.example.com 先命中第一行，不会被第二行拒绝；blocked.example.com 则可命中第二行。若把第一行移到第二行之后，精确例外便失去作用。GEOIP 按目标 IP 的地区信息判断，并不表示页面语言或网站经营者所在地。
选用 DOMAIN、DOMAIN-SUFFIX 与 IP-CIDR 的边界
已知单个问题域名时，优先用 DOMAIN 做最小范围测试。确认整组子域都应该拒绝之后，才考虑 DOMAIN-SUFFIX。后者会覆盖指定域名及其子域，不是仅匹配名称中偶然包含某个字符串的域名；把主站域名写进去，可能同时影响登录、图片和接口请求。
域名范围示例
- 精确匹配
DOMAIN,blocked.example.com,REJECT- 后缀匹配
DOMAIN-SUFFIX,example.com,REJECT- 精确例外
DOMAIN,allowed.example.com,DIRECT
例外放在宽泛规则前；DIRECT 只是语法示意，实际应保持该目标原本所需的策略。
IP 范围示例
- 单个 IPv4
IP-CIDR,192.0.2.8/32,REJECT- 一段 IPv4
IP-CIDR,192.0.2.0/24,REJECT- 地址用途
- 192.0.2.0/24 为文档示例地址段
这里只展示语法；实际地址必须依据用户自己的连接记录核对，不能照抄为有效屏蔽目标。
域名规则依赖可供规则判断使用的目标域名信息。应用直接连接 IP、域名关联不完整或实际请求换了目标时，原有域名规则可能不匹配。此时应先看连接记录中的真实目标，不要因为“域名没拦住”就直接拒绝一个大网段。
/32在 IPv4 中指向单个地址；/24覆盖一个地址段，影响范围明显不同。- 共享 IP 或 CDN 地址可能同时承载多个站点，拒绝 IP 容易连带影响其他正常请求。
- 域名解析结果可能变化，仅封锁当时看到的一个 IP 不等于持续覆盖该域名。
- 不要把
https://、网页路径或查询参数写进DOMAIN的域名字段。
哪些内容能拦，哪些不能只靠 REJECT 处理
当不需要的资源来自独立域名，而且该域名不承担必要功能时，域名级拒绝较容易限定范围。相反，如果同一个域名同时提供正文、登录验证和其他资源，域名级规则无法仅凭 URL 路径区分这些用途。HTTPS 连接中的具体页面内容也不会因为写了一条 DOMAIN 规则就自动成为匹配依据。
| 请求情况 | REJECT 的边界 | 核对方法 |
|---|---|---|
| 独立资源域名 | 可拒绝发往该域名的匹配连接 | 确认该域名没有同时承担登录或业务接口 |
| 同域名下不同路径 | DOMAIN 无法只拒绝其中一个路径 | 比较异常请求与必要请求的主机名是否相同 |
| 已缓存内容 | 没有新网络请求时，不触发新的规则判断 | 重新加载并核对是否出现新连接记录 |
| 已有长连接 | 修改规则不代表旧连接立即重新匹配 | 保存配置后重建连接，再复现同一操作 |
| 共享服务地址 | 拒绝地址可能连带影响其他业务 | 优先确认域名及其用途，避免扩大到整段 IP |
网页上仍然显示某个区域，可能是内容已经嵌入主文档，也可能是应用本地缓存；请求被拒绝后，界面还可能保留固定高度的容器。不要为了消除这类视觉残留，继续添加覆盖主站和静态资源域名的规则。规则层解决连接去向，不负责页面元素隐藏。
从添加到验证：一次只测试一条规则
修改前先在 Config 保留一份可恢复的原配置，并记下原来的 Global Routing、所选出站和测试页面。若配置来自远程管理或更新源，还要确认本地修改是否会被后续更新覆盖。用户已有的服务与订阅负责其自身内容，本文仅说明本地规则的测试方法。
- 记录基线。先不添加 REJECT，打开目标页面，记录正常的登录、图片和接口表现；已有故障不要算到新规则上。
- 修改配置。在 Config 打开当前使用的配置进行编辑，在规则部分添加一条精确的
DOMAIN规则，位置放在可能提前匹配的宽泛规则之前。 - 确认启用。保存修改，核对当前配置，再回 Home 确认
Global Routing → Config。不要只保存了一个未启用的副本。 - 重建连接。必要时关闭再打开 Home 的连接开关，然后让目标应用重新发起请求。此操作会暂时中断当前连接，应避开正在进行的任务。
- 核对证据。查看应用内可用的连接或请求记录，查找同一时间的目标域名与处理策略；若详情提供命中规则信息，一并记录。没有目标请求记录时，不应直接下结论。
- 复测功能。测试正常页面、登录、搜索、图片加载等相关功能。只有目标被拒绝且必要功能仍正常，才保留这条规则。
不要把响应速度变快当作唯一证据，也不要把一次超时等同于规则命中。相同页面的资源会受缓存、登录状态和服务端返回影响。可靠的判断需要同时核对目标请求、实际策略和撤销规则后的对照结果。
页面异常时，按最小范围回退
误拦常见于登录验证域名、图片服务、共享接口以及应用启动所需的配置请求。表面现象可能只是按钮无反应、内容一直加载或登录反复跳转，真正被拒绝的却是后台依赖连接。先撤销最近新增的规则，比继续添加“修复规则”更容易确认因果。
加完规则后登录一直转圈，先改哪里？
在 Config 撤销最近新增的 REJECT，保存并重建连接，再重复登录。如果恢复正常，核对登录时的目标域名；把过宽的 DOMAIN-SUFFIX 缩小为已确认的单个 DOMAIN，而不是直接放行所有请求。
规则写了，但目标仍然能打开？
依次检查 Home 的 Global Routing 是否为 Config、Config 中启用的文件是否正确、前面是否已有 DIRECT 或 PROXY 规则先命中。然后重新加载目标，排除缓存与旧连接，再看实际请求是否换了域名。
请求已被拒绝，为什么页面还有空白块？
空白块可能是页面原本的布局容器。核对连接记录确认 REJECT 后即可停止扩大屏蔽范围；不要把主页面域名一并拒绝，否则可能连正常正文也无法加载。
能把 FINAL 改成 REJECT，省去逐条填写吗？
FINAL,REJECT 会拒绝前面所有未命中的连接，不只是某类不需要的资源。除非正在维护经过完整验证的允许清单，否则保留原有 FINAL；排查时恢复原配置比临时更改兜底策略更稳妥。
如果撤销后仍然异常，恢复修改前保留的整份配置，再确认当前启用文件、连接状态以及目标服务本身是否可用。若只在某条规则存在时稳定复现，才继续缩小该条规则的范围。需要例外时，把精确规则放在宽泛 REJECT 前，并使用该目标原本所需的 DIRECT 或 PROXY，不要默认一律改成 DIRECT。
- 保留记录：写下新增规则、复现操作、目标域名、命中策略与回退结果，避免下一次重复扩大范围。
- 避免批量改动：一次同时修改规则顺序、DNS 和出站选择，会让故障来源难以区分。
- 保护隐私：对外提供排查信息前，隐藏账号、订阅地址中的令牌和其他认证内容。