Shadowrocket REJECT 规则写法与屏蔽边界：能拦什么、拦不住什么

本文速览

Shadowrocket（小火箭）的 REJECT 是连接处理策略，不是页面元素过滤器。本文面向已能正常连接、准备自行调整 Config 的用户，先解释域名与 IP 规则的匹配范围，再给出局部修改、验证命中和恢复配置的步骤，最后区分规则未生效与资源本来就无法单独屏蔽这两类问题。

REJECT 的作用对象：连接，不是页面中的某一块内容

一条规则包含匹配条件和处理策略。客户端在能够取得目标域名或 IP 等信息时，按当前配置判断连接应当如何处理；命中使用 REJECT 的规则后，对应连接被拒绝。它不会先读取网页、判断某张图片是否属于推广内容，再只删除那张图片。因此，规则是否适合使用，首先取决于目标资源能否在连接层面与必要资源分开。

例如，页面主体来自 www.example.com，附加资源来自独立的 metrics.example.com，就可以针对后者建立域名规则。若登录、正文和附加资源全部来自同一个域名，仅路径不同，拒绝该域名通常会一起影响这些功能。

3 个字段

常见域名规则：类型、匹配值、策略

TCP 443

HTTPS 常用端口，不等于资源类别

UDP 443

HTTP/3 常用端口，不等于独立域名

端口只是连接信息的一部分。不能因为某条连接使用 443，就判断它一定是需要屏蔽的资源；拒绝所有相关端口会影响大量正常访问。下面使用的域名和 IP 均为文档示例，不能当作实际屏蔽清单。

常见写法：先用 DOMAIN，再考虑 DOMAIN-SUFFIX 与 IP-CIDR

以下是可以放入配置 [Rule] 段的局部示例。每一行独立表达一个条件；不要把这几行直接替换成完整配置，也不要为了照抄示例而删除已有策略组和兜底规则。

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve

规则类型	示例范围	使用前检查
`DOMAIN`	只匹配 `metrics.example.com` 这一域名。	适合先验证单个主机，确认它不承担必要功能。
`DOMAIN-SUFFIX`	匹配 `telemetry.example.com` 及其子域名。	包括 `a.telemetry.example.com`，范围比精确匹配大。
`IP-CIDR`	`192.0.2.0/24` 表示一个 IPv4 网段。	同一网段可能承载多个域名，不宜用来猜测内容用途。

DOMAIN-SUFFIX,example.com,REJECT 会连同主域名及其子域名一起匹配，不能理解为“只屏蔽这个网站的某类附加资源”。域名字段不写 https://，不写路径，也不写查询参数；DOMAIN 与 DOMAIN-SUFFIX 不负责匹配 URL 中的 /banner/ 等路径。

no-resolve 表示不为这一 IP 规则额外触发域名解析，并不代表这条规则一定无法命中域名连接：若客户端已掌握对应 IP，仍需结合实际连接信息判断。只有 IPv4 网段规则也不等于覆盖了同一服务的 IPv6 地址；若目标走 IPv6，应检查实际地址，而不是随意扩大 IPv4 网段。

结论：从一个明确域名开始

先用一条 DOMAIN 规则验证目标和副作用；只有确认同一子域树都应拒绝时，再扩大到 DOMAIN-SUFFIX。不要因为某次观察到一个 IP，就直接拒绝整段共享地址。

规则顺序与 Global Routing：写对语法还不够

在 Config 按规则处理的路径中，规则通常按顺序匹配，先命中的规则决定策略。若前面已经有覆盖目标的放行规则，后面的 REJECT 就没有机会处理该连接。FINAL 是前面规则都未命中时的兜底，不应放在仍需参与匹配的普通规则之前。

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

上例先拒绝一个精确域名，再让同一主域名下的其他连接走 DIRECT。若调换前两行，metrics.example.com 会先命中范围更大的 DIRECT 规则。末尾 FINAL,DIRECT 仅用于演示匹配顺序；实际配置应保留自己需要的兜底策略，不要据此更改所有未命中流量的去向。

Config

Proxy

以代理路径处理流量，不按 Config 的普通分流规则逐条决定去向。切换到这里后，不能继续用网页是否被拒绝来验证刚编辑的 Config 规则。

适合：临时检查代理连通性，隔离普通分流规则的影响。

Direct

以直连路径处理流量，同样不适合作为自定义 Config 规则的命中测试环境。直连能打开网页，不代表 REJECT 的语法有问题。

适合：对照直连访问情况，检查网络环境差异。

如果正在使用 Scene，还需要先核对场景最终采用的配置和处理方式。排查时暂时固定为 Config，可以减少场景切换带来的变量。这里比较的是三个常用测试姿态，并非 Global Routing 的全部可选项清单。

局部修改与验证：一次只增加一条规则

以下步骤以已有可用配置为前提。Home 中的服务器条目、Config 中的配置文件，以及 Settings 中的通用设置用途不同；编辑了一个未启用的配置，不会自动改变当前连接的处理规则。

保留原配置

进入 Config，确认当前启用的配置，先保留副本或导出备份。记录原有 Global Routing 姿态，确保能够回到修改前的状态。
固定处理方式

在 Home → Global Routing → Config 选择按配置处理。检查 Home 的连接开关处于开启状态，避免在客户端未接管连接时测试规则。
插入精确规则

在 Config 中打开当前配置的编辑入口，定位 [Rule] 段。在覆盖目标的宽泛规则与 FINAL 之前，加入一条针对已确认目标的 DOMAIN 规则，然后保存。
建立新连接

确认修改后的配置仍被启用，必要时重新连接。关闭目标页面或应用后重新打开，再查看客户端的连接记录中该域名对应的策略与命中信息。
检查并回退

分别测试登录、正文、图片和播放等必要功能。出现异常时先移除刚增加的那一行并保存，再重新建立连接；不要同时更换 DNS、服务器和多组规则。

验证需要观察“目标连接是否命中 REJECT”和“必要功能是否仍然可用”两个结果。页面中某个区域消失，只能作为现象，不能单独证明规则正确；服务器临时异常、应用缓存和资源加载超时也会造成相似表现。反过来，页面仍显示旧图片，也可能只是本地缓存未失效，并不说明新请求已成功通过。

屏蔽边界：同域内容、加密路径与内嵌资源

普通域名与 IP 规则并不需要读取完整网页正文，但也因此无法按正文内容作选择。HTTPS 会加密请求路径、查询参数及正文等信息；不能把域名规则当作能够识别完整加密 URL 的过滤条件。客户端能否获得目标域名，还取决于连接方式、解析路径及可用的连接元数据。

同域不同路径：example.com/article 与 example.com/promo 使用相同主机时，DOMAIN 无法只拒绝后一条路径。扩大到 IP 规则也不会获得路径识别能力。
同一连接复用：HTTP/2、HTTP/3 可以在连接中承载多个请求。REJECT 不是在同一连接里挑选某个页面模块的工具，拒绝连接可能影响一起传输的正常资源。
应用包内资源：已经随应用保存的图片、界面或文字不需要新建远程连接，网络规则无法把这些本地内容移除。
服务端合并内容：正文与其他内容若由同一个接口一次返回，拒绝接口可能让正文一起消失，不能保证只保留其中一部分。
共享基础设施：多个服务可能共用 CDN 或 IP。按地址范围拒绝后出现其他站点打不开，应先缩小或撤销地址规则，而不是继续扩大屏蔽范围。

即使命中 REJECT，应用也可能展示预留空位、错误提示、缓存内容，或者换一个域名重试。连接被拒绝与界面被重新排版是两件事。若目标与支付、账户验证或媒体接口共用基础设施，应优先保留必要功能，不宜追求把所有异常请求都归零。

常见排查：规则没命中，还是目标无法单独处理

写了 REJECT，为什么还是能打开？

先确认 Home → Global Routing → Config，再在 Config 核对实际启用的文件。检查规则是否位于覆盖目标的 DIRECT、策略组规则或 FINAL 之后。重新建立连接后查看记录；不要只用仍在屏幕上的缓存内容判断。

能不能只屏蔽一个 URL，不影响同域其他页面？

DOMAIN 与 DOMAIN-SUFFIX 只按域名匹配，不能把完整 URL 粘进域名字段来实现路径过滤。先确认资源是否有独立主机；若只有路径不同，应停止扩大域名规则，避免把同域正常访问一起拒绝。

加完规则后，登录和图片一起坏了怎么办？

先撤回最后一条规则并重新连接，确认功能恢复。若使用的是 DOMAIN-SUFFIX 或 IP-CIDR，检查是否覆盖了共享主机或地址；只有能从连接记录中确认独立目标时，才改为更窄的 DOMAIN 规则。

更新订阅后，本地规则会自动跟着更新吗？

Home 中的 Subscribe 服务器订阅与 Config 配置文件不是同一对象。服务器列表刷新不等于本地规则被更新；远程配置更新则可能覆盖手动修改。分别核对更新对象与当前启用配置，并为本地调整保留副本。

也不要用 Settings → On Demand 判断规则是否命中。On Demand 处理的是符合条件时何时请求建立连接；REJECT 处理的是连接进入规则判断后采用什么策略。排查期间如果连接状态自行变化，应同时确认 On Demand 条件，但不要把按需连接设置当成屏蔽规则编辑入口。

保留规则的标准：命中明确、副作用可接受、能够恢复

规则维护不是条目越多越好。每条新增规则都应有明确目标、可复现现象和撤回方式。对于来源不明的大范围规则，尤其是整段 IP 或宽泛主域名拒绝，无法解释其用途时不应直接并入日常配置。

保留修改前的配置，并注明新增规则处理的目标域名和原因。
新增后检查新连接记录，再测试账户、支付、播放及其他实际使用的功能。
应用或网站改变资源域名后重新验证，不把过去一次有效当作长期保证。
需要更新远程配置时，先检查是否会覆盖本地调整，更新后再次核对启用状态。

Shadowrocket 是通过 App Store 获取的闭源商业应用，以 iPhone、iPad 使用为主，开发者为 Shadow Launch Technology Limited。客户端一次性买断 ≠ 线路套餐；本文不提供连接服务，已有订阅链接从你的服务商处获取。价格、系统要求及购买适用范围以 App Store 页面标注为准。