Shadowrocket（小火箭）的 REJECT 是连接处理策略，不是页面元素过滤器。本文适合已经在使用自己的配置、需要核对域名拒绝规则的用户：先确认 Global Routing 使用 Config，再检查规则顺序、域名可见性与新连接记录；只有确定不需要访问整个目标域名时，才扩大 DOMAIN-SUFFIX 的拒绝范围。
REJECT 的位置：规则决定匹配对象，策略决定处理方式
一条规则通常包含规则类型、匹配内容与处理策略。以 DOMAIN-SUFFIX,example.com,REJECT 为例，DOMAIN-SUFFIX 表示按域名后缀匹配，example.com 是匹配内容，REJECT 才是命中后拒绝连接的策略。不能把 REJECT 当作一个域名列表，也不能仅凭配置中出现这个词就判断目标连接一定会被拒绝。
在通常的规则分流流程里，规则从上往下检查，命中后采用对应策略。因此，放在前面的宽泛放行规则，可能让后面的拒绝规则没有机会生效。FINAL 是此前规则均未命中时的兜底项，应放在规则列表末尾；它不是补充检查，也不会在连接已经命中前面的规则后再次覆盖结果。
DIRECT：对匹配连接使用直连处理。REJECT：对匹配连接执行拒绝处理，应用端可能显示失败、重试或等待超时，具体表现取决于应用自身。- 代理策略或策略组：让匹配连接使用配置中对应的出站。策略名称必须在当前配置中有效，不能随意填写一个未定义名称。
规则是否参与判断，还取决于当前运行姿态。在 Home → Global Routing 核对当前选择；本文的排查前提是使用 Config。Proxy 与 Direct 不能作为验证配置规则是否命中的同等测试条件；使用 Scene 时，应先确认场景当前实际采用的分流设置。
DOMAIN-SUFFIX 的范围：整个域名后缀，而非网页路径
DOMAIN-SUFFIX,example.com,REJECT 会匹配 example.com 以及 img.example.com 等子域名，不会因为文字相似就匹配 notexample.com。如果仅想处理一个确定的主机名，可以考虑使用 DOMAIN 精确匹配，避免把同一后缀下的其他业务一起拒绝。
| 规则或目标 | 匹配结果 | 核对重点 |
|---|---|---|
example.com | 后缀规则命中 | 根域名也在范围内 |
img.example.com | 后缀规则命中 | 子域名在范围内 |
notexample.com | 该后缀规则不命中 | 域名标签边界不同 |
example.com/assets/banner.jpg | 不能按路径区别处理 | 后缀匹配不检查 URL 路径 |
以下是规则片段，用于说明“精确例外在前、后缀拒绝在后、兜底最后”的顺序。示例域名只用于语法说明，不是要屏蔽的实际业务，也不是完整的可替换配置。应用到已有配置前，应先确认其中的直连例外是否符合实际需求。
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT这里 keep.example.com 会先命中精确直连规则；其他属于 example.com 的目标才会继续落入拒绝规则。若把两条规则对调，例外就会被前面的后缀规则覆盖。不要为了解决一个页面问题直接拒绝整个公共域名后缀，应从最小的已确认目标开始。
开始验证：固定运行姿态与当前配置
排查时每轮只改一个条件。先保存当前配置副本，记录测试前后的规则顺序，再确认所编辑的文件确实是当前正在使用的配置。只修改 Config 列表里的另一个文件，而没有切换使用，不能用来证明规则语法有问题。
运行条件
- 分流入口
- Home → Global Routing
- 测试姿态
- Config
- 配置核对
- Config 中确认当前使用的文件
- 连接前提
- 确认 VPN 已连接，再发起新请求
先固定运行条件，再判断规则是否参与匹配。
规则条件
- 精确匹配
DOMAIN,ads.example.com,REJECT- 后缀匹配
DOMAIN-SUFFIX,example.com,REJECT- 兜底位置
FINAL放在规则末尾- 记录字段
- 目标主机、目标 IP、命中规则与处理策略
结合应用内实际显示的记录字段核对，不用页面外观代替命中证据。
- 选定一个自己能够确认用途的目标域名，先用精确规则测试，避免扩大影响面。
- 把测试规则放到可能提前命中的宽泛规则之前，保存配置并确认当前使用状态。
- 结束旧请求，再重新打开目标页面或触发目标功能，让应用建立新连接。
- 查看连接记录，核对测试时刻、目标信息与命中策略；必要时在保留配置的情况下重新连接 VPN 后再测。
- 撤回测试规则，再重复相同操作，对比新连接结果，确认影响是否来自这条规则。
On Demand 管理的是自动连接条件，不是域名拒绝规则的另一个优先级。若测试过程中 VPN 会自动连接或断开，可到 Settings → On Demand 核对相关条件，避免把隧道状态变化误认为 REJECT 间歇性失效。
同域名内容的边界：能拒绝连接，不能只删除页面中的一块
当正文、图片、登录接口和待处理内容都来自同一个主机名时，域名规则无法仅凭请求的业务用途区分它们。HTTPS 请求的路径、响应正文和页面元素也不属于 DOMAIN-SUFFIX 的匹配字段。拒绝这个域名可能同时影响登录、验证码、图片加载或播放功能。
HTTP/3 通常使用 UDP 443，常见 HTTPS 连接也可能使用 TCP 443。只看见端口 443，不能判断这条连接是正文、统计还是视频请求；更不能据此承诺一条拒绝规则只影响某一种内容。同样，连接被拒绝后，应用可能改用另一个域名、备用接口或已有缓存，看起来仍然显示原来的内容。
结论：无法区分业务时，先缩小匹配范围
若加入后缀拒绝规则后登录或正文也失败，先撤回该规则；只有连接记录能确认存在独立目标主机时，再用 DOMAIN 对该主机单独验证，不继续扩大域名或 IP 范围。
- 页面出现空白区域：可能只是资源连接失败，REJECT 不负责重新排版页面。
- 内容依然出现：先排除本地缓存、已有长连接与备用域名，不能直接断言规则未命中。
- 页面整体打不开：检查是否误拒绝了主站、认证接口或公共资源域名。
加密 DNS 与 IP 规则：关键是匹配时有哪些目标信息
域名规则需要在匹配时取得可用的域名信息。DNS 解析方式、缓存、应用是否直接连接 IP，以及配置中的 DNS 处理方式，都会影响记录里能够看到什么。不能把“使用加密 DNS”直接等同于“所有域名规则失效”，也不能假定每条 IP 连接都能被可靠还原为原始域名。
使用 DoH 的应用，可能通过 HTTPS 与解析端点通信；这一请求并不等于直接暴露了它后续查询的全部域名。若后续业务连接只呈现 IP，且没有可用的域名关联信息，域名规则就可能无法匹配。反过来，如果 Shadowrocket 已有可用的域名映射或其他目标信息，仍可能按域名处理，应以该次连接记录为准。
| 记录或现象 | 优先核对 | 不宜直接采取的操作 |
|---|---|---|
| 可见目标域名，但命中其他策略 | 规则顺序、当前配置与拼写 | 立即更换 DNS 来碰运气 |
| 仅见目标 IP | 解析路径、域名关联与应用连接方式 | 假定域名规则必然能命中 |
| 拒绝 IP 后多个功能异常 | 共享 IP、CDN 与其他业务连接 | 继续扩大拒绝网段 |
IP-CIDR 匹配地址或网段，GEOIP 按 IP 地理数据库分类，两者都不是按页面内容分类。语法示例 IP-CIDR,192.0.2.1/32,REJECT,no-resolve 使用文档保留地址；其中 /32 表示单个 IPv4 地址，no-resolve 表示不为这条 IP 规则主动触发域名解析。它不是用来补齐所有缺失域名信息的选项，也不应原样用于实际屏蔽。
排查结论：以新连接的命中记录为依据
判断一条 REJECT 规则是否有效，至少要把“配置已启用”“目标已匹配”和“结果符合预期”分开核对。仅看到页面内容还在，不能证明拒绝没有发生；仅看到某条连接失败，也不能证明是 REJECT 导致。记录中的目标、时刻、命中规则与应用行为需要对应起来。
- 未命中 REJECT：检查 Home → Global Routing 是否为 Config，再确认当前配置、规则位置、域名边界与可用目标信息。
- 已命中但内容仍在：重新发起请求，排除缓存、旧连接和备用域名，记录真正承载内容的连接。
- 已命中且功能异常：撤回该规则，再用更小范围验证；若业务共用同一域名，不继续尝试用后缀规则区分页面内容。
- 需要保留长期规则：记录目标用途、加入原因与回退方法。更新配置后复查规则是否仍存在、顺序是否改变。
已有订阅通常用于更新连接资料，Config 承载的规则配置是另一项需要核对的对象。一次订阅更新不等于已更新拒绝规则；配置文件更新也可能改变本地修改。若用户已有自己的服务商与订阅，排查时应分别确认连接资料和规则文件的状态，不需要为测试 REJECT 更换连接服务。