· 规则进阶 · 约 9 分钟

Shadowrocket REJECT 策略原理:规则拦截请求能做到什么、做不到什么

讲清 REJECT 与 DOMAIN-SUFFIX 等规则配合拦截请求的工作方式,以及规则匹配的边界和容易误伤正常功能的情况。

本文速览

REJECT 是请求的处理策略，不是网页元素过滤器。本文适合已在 Shadowrocket 中使用自己的配置、服务商与订阅，准备添加拦截规则或排查误伤的用户。先确认 Global Routing 使用 Config，再核对命中的规则、目标范围与回退方式；读完可以区分“规则没有匹配”“匹配后被拒绝”和“页面内容不在规则能力范围内”这三类情况。

REJECT 在哪里生效

Shadowrocket（小火箭）通过配置中的规则决定流量怎样处理。REJECT 表示拒绝匹配到的请求；它与 DIRECT、PROXY 一样，是规则末尾可以指定的策略，但处理结果不同。规则负责选择目标，策略负责决定怎样处理，不能把两者混为一谈。

请求发起 流量接管 规则匹配 命中拒绝 请求失败

以上流程只描述进入 Shadowrocket 处理范围、并最终匹配到 REJECT 的请求。应用开关已打开，不代表当前一定按配置规则分流。先在 Home 查看 Global Routing；需要验证当前配置中的拒绝规则时，应使用 Config，并在 Config 中确认选中的是刚刚编辑的配置。

若使用 Global Routing 中的 Scene，也应先核对当前 Scene 的实际设置，而不是仅凭开关状态推断规则路径。排错时将测试条件固定在 Config，能减少自动切换和不同姿态造成的干扰。

规则怎样选择请求

一条基本规则由匹配类型、匹配内容和策略组成。例如 DOMAIN-SUFFIX,example.com,REJECT：匹配类型是 DOMAIN-SUFFIX，目标是 example.com 这个域名后缀，处理策略是 REJECT。这里的 example.com 仅作保留示例域名，不代表应当拦截的真实业务。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,PROXY

这段示例用于说明顺序，不能整段替换现有配置。配置规则按顺序参与匹配：对能够识别为 login.example.com 的请求，前面的精确规则先决定处理方式；其他匹配 example.com 后缀的域名会被拒绝；未被前面规则处理的请求才交给 FINAL。DIRECT 只是演示例外策略，真实环境应保留该业务原本可用的策略。

域名匹配范围

DOMAIN
DOMAIN,ads.example.com,REJECT，仅匹配这个完整域名。
DOMAIN-SUFFIX
DOMAIN-SUFFIX,example.com,REJECT，包含根域名及其子域名。
不匹配的名字
notexample.com 不属于 example.com 的子域名。

目标只有一个主机时，先使用 DOMAIN，避免扩大拒绝范围。

地址与兜底规则

IP-CIDR
IP-CIDR,192.0.2.0/24,REJECT，按目标 IPv4 网段匹配。
GEOIP
GEOIP,CN,DIRECT，依据地址归属数据库匹配。
FINAL
FINAL,PROXY，处理此前未命中的请求。

192.0.2.0/24 是文档示例网段；地址规则不是域名规则的等价替代。

域名规则需要可用于匹配的域名信息，地址规则则依据目标地址；解析过程、DNS 缓存和应用是否直接使用 IP，都可能影响观察到的信息。不能只看浏览器地址栏，就断言每个相关连接都带着同一个域名进入规则匹配。

能拦截什么内容

REJECT 的有效边界是请求，而不是屏幕上的某一块内容。一个页面可能同时请求主文档、图片、字体、统计接口和登录接口；如果其中某个独立域名被准确匹配，该目标的请求可以被拒绝。其余页面是否仍然正常，取决于页面是否依赖这个目标。

具体场景REJECT 的边界验证重点
附加资源使用独立域名可拒绝该域名的请求，但不保证页面自动收起空白区域。确认实际资源域名，而不是只看页面名称。
正文与附加内容共用同一域名DOMAIN-SUFFIX 不能按 URL 路径区分两者。拒绝整个域名可能同时破坏正文、图片或交互。
内容已在本地缓存新增拒绝规则不会清除应用已经保存的内容。确认是否真的发起了新请求，避免把旧内容当成规则失效。
内容直接嵌入主响应域名拒绝策略不能只删除响应中的某一段文字或布局。区分独立网络请求与同一响应内的内容。
目标直接使用 IP 地址不能假定 DOMAIN-SUFFIX 一定有可匹配的域名。核对连接记录中的实际目标地址与命中规则。

HTTPS 常见使用 TCP 443，HTTP/3 常见使用 UDP 443，但端口号不能说明请求的业务用途。同一域名上的正常接口和其他资源可能都使用 443。DOMAIN-SUFFIX 本身也没有端口筛选条件，不会因为目标换了端口就变成另一种业务识别机制。

结论：先找独立目标，再写拒绝规则

只有确认目标与正常功能可以分离，才添加最窄范围的 DOMAIN 规则；如果它们共用一个域名，不要仅凭路径名称扩大为整个后缀的 REJECT。

误伤为什么发生

常见误伤不是语法出错，而是匹配范围比预想更大。将 DOMAIN-SUFFIX,example.com,REJECT 放进配置后，login.example.com、static.example.com 和 api.example.com 都在范围内。登录页能打开但提交失败、正文能显示但图片不加载，都可能来自不同子域名承担了不同功能。

  1. 根域名范围过宽：原本只想拒绝 ads.example.com，却写成 example.com，连带影响账户、图片和接口。
  2. 共享地址被整体拒绝：多个域名可能使用同一个托管或分发地址。把一次观察到的 IP 扩成 IP-CIDR 网段，可能拒绝无关业务。
  3. 正常依赖被当作附加资源：验证码、账户验证、支付跳转和媒体授权可能依赖另一个域名，页面表面仍在，关键操作却无法完成。
  4. 例外规则顺序错误：精确允许规则写在较宽的拒绝规则之后，前面的匹配已经决定处理结果，后面的例外不能补救。
  5. 编辑与生效对象不同：修改了 Config 中的一份文件，实际选用的却是另一份配置，导致排查方向偏离。

遇到“偶尔能用”的现象，也不要立即判断 REJECT 随机失效。应用可能复用已有连接、读取缓存，或者切换到其他服务域名。应固定同一个操作，重新发起请求，并结合当次记录确认目标；不能把两次不同页面、不同账户状态的结果直接作对照。

按单一变量排查

验证拒绝规则时，先保留一份可恢复的配置，再只修改一个目标。不要同时切换策略、调整 DNS、更新订阅并加入多条规则，否则即使功能恢复，也无法判断是哪一项产生了影响。以下步骤不需要更改现有服务商，只核对本地规则与实际请求。

  1. 记录基线：写下失败操作，例如“打开登录页后提交表单”，以及发生时间。确认该操作在修改前是否正常。
  2. 固定姿态：在 Home → Global Routing 选择 Config，到 Config 确认当前配置。若测试期间连接被自动改变，再核对 Settings → On Demand 的条件。
  3. 重现一次：重新触发相同操作，在应用内可用的连接记录或日志中查找对应时间的目标域名、IP、命中规则与策略；记录能显示的字段，不凭空补全。
  4. 缩小规则：若命中宽泛的 DOMAIN-SUFFIX，先在测试副本中移除这一条，再视实际目标改成 DOMAIN。其他规则与原本的兜底策略保持不变。
  5. 应用并复测：保存配置，确认修改已经应用；必要时在可中断网络任务的时机重新连接，再执行同一操作，避免沿用已有连接。
  6. 做回退对照：若移除该规则后恢复、恢复该规则后又失败，才有较强依据把问题归因到它。若没有这个对照，继续检查其他规则和目标，而不是连续扩大允许范围。

日志只看到连接失败，不等于已经证明命中 REJECT。DNS 解析失败、连接超时、远端返回错误也会表现为“打不开”。应优先找策略与规则字段；记录没有提供足够信息时，只能保留为待确认原因。分享排查材料前，遮盖订阅地址中的凭据、账户信息和不必要的访问记录。

结论：恢复功能后再收紧规则

先回退已确认造成故障的单条拒绝规则，恢复原有可用策略，再逐个验证更精确的目标；不要用永久放行整个父域名来掩盖尚未定位的误伤。

常见问题与处理

规则加了，为什么页面里的内容还在？

先到 Home → Global Routing 确认 Config，再到 Config 核对当前文件。随后重新请求页面并查看实际目标；若内容来自缓存、主响应或其他域名，新增的那条 DOMAIN-SUFFIX 并不一定覆盖它。REJECT 也不会负责移除页面留下的占位区域。

一拦截就不能登录，应该放行什么？

先在测试副本中撤销最近添加的拒绝规则，重复登录操作。若恢复，再根据记录确认登录所需的完整域名，用 DOMAIN 写在宽泛拒绝规则之前，并采用该业务原本可用的策略；不要直接把所有相关父域名都改为 DIRECT。

把域名换成 IP-CIDR，会不会拦得更准？

不一定。地址可能变化，也可能被多个业务共用。只有明确要处理某个目标地址或网段时才使用 IP-CIDR；不要把某次解析得到的地址当成该业务永久且独占的标识。先保留域名级测试，再核对地址规则是否扩大影响。

更新自己的订阅后，需要重写 REJECT 吗？

先检查实际变化的是连接条目还是配置文件。订阅更新本身不能证明本地规则已变化；若当前配置也发生远程更新，比较规则内容、顺序和选中状态。仅在确认改动丢失或目标变化后调整，不要每次更新都重复追加相同规则。

日常维护可以保留三项记录：拒绝的完整目标、添加原因、撤销方法。每次出现正常功能异常，先核对最近变更，再按单一变量复测。规则数量不是效果指标；范围清楚、能解释命中结果、能够及时回退，才便于长期维护。

App Store 正版核对