· 规则分流 · 约 8 分钟

Shadowrocket REJECT 规则原理:按域名拦截请求能做到什么、做不到什么

解释 REJECT 策略在规则命中后如何拒绝连接,以及它对同域名内容、加密 DNS 和应用内嵌请求的局限,帮助合理预期拦截效果。

本文速览

REJECT 处理的是命中规则的连接，不是网页中的单个元素。本文适合已经在 Shadowrocket（小火箭）中使用自己已有配置的用户：先确认 Config 模式与规则顺序，再用精确域名验证拦截，最后区分域名不可见、连接复用和同域名内容这三类限制。

REJECT 的作用范围

REJECT 是规则的处理策略，不是匹配关键字。DOMAIN,ads.example.com,REJECT 可以拆成三部分：DOMAIN 指定匹配方式，ads.example.com 是匹配值，REJECT 表示命中后拒绝这条连接，而不是按 DIRECT 或代理策略继续转发。

应用请求 隧道接管 规则匹配 命中 REJECT 连接被拒

这条流程以请求已经进入 Shadowrocket 的处理范围为前提。连接开关关闭、没有启用预期配置，或者当前路由姿态不使用这组规则时，单独写入一行 REJECT 不等于已经生效。拒绝后应用可能显示空白、加载失败或继续重试；界面现象由应用自身的错误处理决定。

REJECT 也不等于擦除内容。页面已经下载的图片、本地缓存的数据和应用预置的推广画面，不会因为新增规则而立即消失。检查效果时，应关注新请求是否被拒绝，而不是只看屏幕上还剩下什么。

先核对 Config 与规则顺序

在 Home 中将 Global Routing 设为 Config，再到 Config 核对当前启用的配置。不要用 Proxy 或 Direct 姿态下的页面表现，验证某条 Config 分流规则。若原先使用 Scene，先记录场景设置，再切换到明确的 Config 测试条件，减少自动切换带来的干扰。

  1. 在 Config 中保留原配置副本，确认编辑的是当前准备启用的文件。
  2. 在该配置的 [Rule] 部分添加测试规则，放在可能先命中的宽泛规则与 FINAL 之前。
  3. 保存并启用配置，回到 Home 确认 Global Routing → Config，检查连接开关。
  4. 让目标应用建立新连接，再查看连接记录中的目标、命中规则与处理策略；不要仅凭一次页面刷新下结论。

常规规则按排列顺序检查，先命中的规则决定处理结果。下面只是演示结构，example.com 系列域名并非实际拦截清单；FINAL,DIRECT 也只是演示兜底，不应覆盖你已有配置中的最终策略。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,DIRECT

若将 DOMAIN-SUFFIX,example.com,DIRECT 放在第一行，发往 ads.example.com 的请求会先被它匹配，后面的精确拒绝规则就无法处理该请求。应把需要保留的精确例外、需要拒绝的具体目标与宽泛规则按实际优先级排列，而不是认为“最后添加的一条优先”。

精确域名与后缀匹配怎么选

排查单个目标时，从 DOMAIN 开始更容易控制范围。只有确认某个子域名分支整体承担同类用途，才考虑改为 DOMAIN-SUFFIX。不要因为一个子域名出现了不需要的请求，就直接拒绝整个主域名。

精确匹配

关键字
DOMAIN
匹配值
ads.example.com
策略
REJECT
范围
仅 ads.example.com

不会同时匹配 img.ads.example.com，适合先验证一个明确目标。

后缀匹配

关键字
DOMAIN-SUFFIX
匹配值
metrics.example.com
策略
REJECT
范围
该域名及其子域名

同时覆盖 metrics.example.com 与 api.metrics.example.com，应先核对用途。

DOMAIN-KEYWORD 按域名中的关键词匹配，范围比一个明确的后缀更难控制。例如仅以 ad 为关键词会涉及很多并非目标服务的域名。IP-CIDR 则按地址网段处理，GEOIP 按 IP 归属分类处理；它们都不能表达“这个网页中的某一块内容”。共享服务器或共享地址下，用 IP 拒绝连接可能连带影响其他域名。

结论：先缩小匹配值，再扩大范围

先用一条 DOMAIN 规则验证目标用途与命中结果；确认子域名分支都可以拒绝后，再调整为 DOMAIN-SUFFIX，不要把整个主域名作为第一轮测试对象。

同域名内容不能按页面位置拆分

假设正文接口位于 api.example.com/content，推广接口位于 api.example.com/promo。二者共享同一个域名，普通 DOMAIN 与 DOMAIN-SUFFIX 规则不会按 URL 路径区分它们。拒绝 api.example.com 会同时影响这两类连接，而不是只去掉推广接口。

HTTPS 常见的目标端口是 443，但端口本身不说明请求用途。普通域名规则不会因此获得加密请求中的路径或正文。应用内嵌页面也不例外：关键在于目标连接是否独立、域名是否可用于匹配，而不是它显示在浏览器中还是应用内部。

加密 DNS 与域名可见性的边界

域名规则需要可用于匹配的域名信息。应用使用系统解析时，解析过程与连接之间可能建立关联；应用自行使用 DoH 或 DoT 时，DNS 查询内容被放进另一条加密连接，不能假定 Shadowrocket 仅凭目标 IP 就能还原其中查询的域名。其他连接元数据是否可用，也取决于实际流量与设置。

场景需要检查的事实不能直接得出的结论
常规 DNS解析关联、目标域名与实际命中规则看见一次 DNS 查询不代表后续连接一定命中 REJECT
应用内 DoH是否连接独立的解析端点，以及目标连接是否仍有域名信息DoH 常用 443，不代表所有 443 连接都是 DNS
应用内 DoT是否存在目标端口 853 的连接及其用途端口信息本身不能还原查询内容
直接连接 IP连接记录中是否只有地址、是否有其他域名关联不能假定 DOMAIN 规则一定能匹配到该连接

遇到这类情况，先核对 Settings 中的 DNS 设置与应用自身的解析选项，相关说明可见DNS 设置参考。拒绝一个已知解析端点，可能导致应用解析失败，也可能触发备用端点；这不等于已经完成针对目标内容的拦截。尤其不要用“拦截所有 443 连接”替代域名排查，这会影响普通 HTTPS 访问。

建立一次可复查的拦截测试

测试应只改一个变量。页面上的占位区域、加载时长和错误提示都是间接现象；更有用的证据是：目标是什么、哪条规则先命中、最终用了什么策略。下面的流程用于检查用户已有配置，不涉及获取任何连接服务。

  1. 记录基线：保存当前配置，记录 Global Routing 姿态、目标域名以及未加规则时的页面表现。
  2. 只加一条：将确认过的目标写成 DOMAIN,ads.example.com,REJECT 这样的完整规则；实际测试时使用自己记录到的域名，不要把示例域名当作有效清单。
  3. 重建连接：退出目标应用后重新打开，必要时重新建立 Shadowrocket 连接。已有长连接可能继续被复用，单次刷新未必触发新的规则判断。
  4. 核对命中：查看新连接的目标、规则与策略。若仍是 DIRECT 或代理策略，先检查配置是否启用，以及前面是否有更早命中的规则。
  5. 检查连带影响：依次验证登录、正文加载、图片与提交操作。出现异常时撤回新增规则，再重复同一操作进行对照。

自动连接状态也要纳入记录。Settings → On Demand 用于管理按条件连接的行为，不负责替换 REJECT 规则；测试期间如果连接状态随网络变化，就要先确认请求当时是否进入隧道。不要同时修改 On Demand、DNS 和规则列表，否则很难确定是哪项改动导致结果变化。

常见现象与修正方法

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

先重新打开目标应用，核对是否产生了命中 REJECT 的新连接。若记录已经拒绝，而画面仍存在，检查缓存、本地资源或同一响应携带内容的可能性，不要立即扩大到整个主域名。

为什么一拦截就不能登录？

先撤回新增规则并重新测试登录。若功能恢复，把 DOMAIN-SUFFIX 收窄到经过确认的 DOMAIN，再分别验证认证接口与附加请求；同一个域名承担多种用途时，应保留必要连接。

为什么记录里是 IP，没有看到域名？

核对应用是否直接连接 IP、是否自带加密 DNS，并查看 Settings 中的 DNS 配置。不要随意将该 IP 扩成整个网段拒绝；共享地址可能承载其他服务，应先确认目标与误伤范围。

配置更新后，手动加的规则怎么不见了？

到 Config 重新核对当前启用文件及其规则内容。远程配置更新与 Home 中已有订阅的服务器列表更新不是同一件事；替换配置前保留本地副本，更新后检查自定义规则是否仍在预期位置。

最终判断标准是“指定连接按预期被拒绝，必要功能仍可用”，而不是承诺所有应用都不再出现某类内容。REJECT 适合处理可独立识别的目标连接；当内容与必要业务共用域名、连接或响应时，应接受域名分流的边界，而不是不断扩大拒绝范围。

App Store 正版核验