· 进阶配置 · 约 9 分钟

Shadowrocket REJECT 规则怎么写：屏蔽原理、匹配顺序与局限

解释 REJECT 策略如何在规则匹配阶段拦下请求，常见写法有哪些，规则顺序对结果有什么影响，以及按域名屏蔽在哪些情况下无法生效。

本文速览

本文面向已经在 Shadowrocket（小火箭）中使用自己已有配置、希望添加少量屏蔽规则的用户。先区分规则条件与 REJECT 策略，再按“备份配置、添加精确规则、检查顺序、验证新请求”的步骤操作。示例使用保留域名与文档地址，重点是说明语法，不是一份可以直接替换现有配置的屏蔽清单。

一、REJECT 是策略，不是域名匹配条件

一条规则通常由匹配类型、匹配内容和处理策略组成。例如 DOMAIN-SUFFIX,ads.example.com,REJECT 中，DOMAIN-SUFFIX 决定如何匹配，ads.example.com 是待匹配的域名后缀，REJECT 才是命中后的处理策略。仅写一个 REJECT，并不能表达要拦截哪个域名。

当请求进入 Shadowrocket 的处理范围，并按当前配置进行规则匹配时，命中 REJECT 的连接会被拒绝，而不是继续按该请求原本可能采用的 DIRECT 或代理策略转发。它不等于删除网页元素，也不负责把页面中的空白区域重新排版；应用可能显示加载失败、占位区域或重试提示。

应用发起请求 进入处理范围 配置规则匹配 命中拒绝策略 本次连接拒绝

规则匹配发生在连接处理过程中，但不要据此推断“命中 REJECT 就绝不产生 DNS 查询”。域名解析、缓存以及为 IP 类规则取得地址的过程会影响实际行为。REJECT 的作用是拒绝匹配连接，不是一个独立的 DNS 隐私开关。

二、常见写法：精确域名、后缀与 IP 网段

先从精确域名开始，只有确认整个子域树都应拒绝时，再扩大到 DOMAIN-SUFFIX。规则中的域名不要带 https://、路径、查询参数或末尾的斜杠。下面几行用于分别解释语法，不要求全部加入同一份配置。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
IP-CIDR6,2001:db8::/32,REJECT,no-resolve
规则类型匹配范围使用注意
DOMAIN指定的完整域名。适合只拒绝一个已确认的主机名。
DOMAIN-SUFFIX指定域名及其子域名。metrics.example.com 也覆盖 a.metrics.example.com，不覆盖 othermetrics.example.com。
IP-CIDRIPv4 地址网段。共享地址可能同时承载正常业务，不能把一个域名解析出的地址直接视为专用地址。
IP-CIDR6IPv6 地址网段。只写 IPv4 规则不能覆盖 IPv6 目标地址。

no-resolve 用于避免为了这条 IP 类规则主动把域名解析成 IP；它不表示关闭所有 DNS 解析，也不阻止已经以 IP 为目标的请求参与匹配。示例中的 192.0.2.0/24 与 2001:db8::/32 是文档地址，不能据此期待某个真实服务被屏蔽。

4 类
上表区分两类域名匹配与两类 IP 网段匹配。
/32
IPv4 的单地址前缀长度，例如 192.0.2.8/32。
/128
IPv6 的单地址前缀长度，例如 2001:db8::8/128。

判断：先缩小匹配范围，再扩大屏蔽范围

只观察到一个主机名发起不需要的请求时，先添加 DOMAIN 规则；只有逐项确认其子域名用途后，才改为 DOMAIN-SUFFIX，不要先封整个共享网段。

三、规则顺序：例外在前，FINAL 在后

在常规规则列表中，请求按顺序匹配，先命中的规则决定处理策略。把 REJECT 放在列表末尾，并不意味着它会覆盖前面的放行规则；同样，前面已经命中的宽泛屏蔽规则，也不会再由后面的例外规则撤销。

[Rule]
DOMAIN,assets.ads.example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

这段示例中，assets.ads.example.com 先命中精确例外；video.ads.example.com 则命中下一条后缀屏蔽。GEOIP 按目标 IP 的地理归属参与匹配，并不识别内容用途；若把它放在屏蔽规则前，符合其条件的请求可能提前走 DIRECT。FINAL 是前序规则都未命中时的兜底项，应放在规则列表末尾。

精确例外

类型
DOMAIN
目标
assets.ads.example.com
策略
DIRECT
位置
放在覆盖它的后缀屏蔽规则之前。

DIRECT 仅表示直连；真实例外应沿用该业务需要的可用策略。

后缀屏蔽

类型
DOMAIN-SUFFIX
目标
ads.example.com
策略
REJECT
位置
位于精确例外之后、宽泛放行与 FINAL 之前。

本文 FINAL,DIRECT 仅用于解释兜底，不代表应替换原有分流策略。

合并规则时应在现有 [Rule] 分节中插入对应行，不要重复粘贴整个分节，也不要直接删除原有代理策略、规则引用或兜底设置。配置中若还有外部规则引用，应结合引用所在位置检查整体顺序，不能只看刚添加的几行。

四、在 Config 中修改并验证生效

规则保存在配置中，已有节点订阅主要提供连接信息；更新订阅不能代替编辑规则。操作前先保留一份当前可用配置，再进入 Config，确认正在编辑和正在使用的是同一份配置。远程配置更新可能替换本地改动，应保留自定义规则副本。

  1. 记录原状态。记下 Home → Global Routing 当前选项以及 Config 中启用的配置，保留原文件，便于恢复。
  2. 只增加一条测试规则。在 Config 中打开目标配置的编辑入口，在 [Rule] 内添加已确认目标的 DOMAIN 规则，放在可能提前命中的宽泛规则之前，保存并启用该配置。
  3. 使用规则模式。在 Home → Global Routing 选择 Config。Proxy 与 Direct 是不同的全局处理姿态，不能用来验证同一份 Config 规则是否正常命中；若使用 Scene，应先确认场景实际选用的配置和路由状态。
  4. 重新发起请求。确认连接开关已开启，关闭目标页面后重新打开。必要时断开再连接以建立新连接；仅刷新已有长连接中的界面，可能看不到规则变化。
  5. 核对记录。查看连接或日志记录中的目标域名、目标地址、匹配规则与处理策略。以新请求命中 REJECT 为证据，不以页面某个区域暂时消失作为唯一判断。

五、按域名屏蔽的边界与误伤来源

DOMAIN 与 DOMAIN-SUFFIX 处理的是主机名，不是页面内的某一段内容。HTTPS 请求中同一主机的不同路径，例如 https://example.com/news 与 https://example.com/promo，不能仅靠这两种域名规则区分；直接拒绝 example.com 会同时影响这两个路径对应的连接。

按域名拒绝通常不需要为此开启 HTTPS 解密。增加证书或修改其他无关设置，不能解决“同一域名承载多种内容”的匹配粒度问题。对无法独立区分的资源，应保留功能边界，不承诺通过一条 REJECT 规则完整移除某类页面内容。

六、常见问题：未命中、误伤与更新回退

加了 REJECT，页面怎么还是能打开？

先确认目标是整个页面主机还是页面中的一个资源主机。回到 Home → Global Routing 检查 Config，再到 Config 核对启用文件。重新发起请求后查看记录；如果实际请求使用了另一个主机名，应根据记录添加精确规则，而不是反复重复同一行。

规则命中后，正常图片也不见了怎么办？

先恢复备份或移除最近添加的屏蔽行，确认图片恢复。随后把 DOMAIN-SUFFIX 缩小为已确认的 DOMAIN；确有独立正常主机时，把它的精确例外放到屏蔽行之前。若图片和待拒绝内容共用同一主机，单靠域名规则不能分开。

更新已有订阅后，为什么规则没有变化？

先区分更新的是 Home 中的节点订阅，还是 Config 中的远程配置。前者并不等同于更新规则；后者则可能覆盖本地编辑。回到 Config 检查实际文件中的 [Rule] 内容，把自行维护的规则与原始配置分别备份，更新后逐项核对。

把 FINAL 改成 REJECT，能省去逐条屏蔽吗？

FINAL,REJECT 会拒绝所有没有被前序规则匹配的连接，作用远大于屏蔽一个域名。除非正在维护明确的允许列表，否则不要这样替代定向规则。先恢复原来的 FINAL 策略，再添加范围明确的 DOMAIN 或 DOMAIN-SUFFIX。

七、保存前的最小检查清单

一份可维护的 REJECT 配置，应能回答“拒绝哪个目标、为何使用这种匹配、例外在哪里、如何恢复”四个问题。每次只改变一个匹配条件，并保留修改前后记录，比一次导入大量未经确认的规则更容易定位故障。

App Store 正版核验 →