Shadowrocket REJECT 策略:屏蔽原理与拦截边界

REJECT 在规则里是什么:一条出站策略

Shadowrocket 的规则行是类型,值,策略的三段式写法,策略段只有三种取值:PROXY(交给当前选中的服务器出站)、DIRECT(本地直连,不进代理)、REJECT(在本地拒绝或丢弃这条连接)。REJECT 不是 Settings 里的一个总开关,它只是某一条规则的动作,只有命中这条规则的连接才会被拦下来。

一条最小可用的屏蔽规则长这样:

DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-KEYWORD,metrics,REJECT
IP-CIDR,203.0.113.0/24,REJECT,no-resolve
FINAL,PROXY

规则写在当前 Config 文件里(Home → 当前配置 → 编辑),也可以在 Home 的规则列表中直接增删。改动后需要重新选中该 Config 才会参与匹配;更新订阅会重新拉取配置文件,本地手改的规则可能被覆盖,更新完建议复查一遍。

命中顺序:REJECT 什么时候才轮得到

每个新连接只做一次规则匹配:从列表第一行开始逐条比对,第一条匹配成功的规则决定这条连接的走向,后面的规则不再参与。REJECT 能不能生效,取决于它前面有没有更宽泛的规则先把这条连接领走。

顺序问题出在宽窄关系上。DOMAIN-KEYWORD,ads,REJECT 写在 DOMAIN-SUFFIX,ads.example.com,PROXY 前面,那么 ads.example.com 会先被 keyword 规则拦掉;反过来写,窄规则先命中,后面的 keyword 规则对这条连接就没有机会了。窄规则在前、宽规则在后,是规则列表的基本排法。

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,metrics,REJECT
IP-CIDR,198.51.100.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

这六行是一副可用骨架:精确域名 → 域名后缀 → 关键字 → IP 段 → 地理归属 → 兜底,越具体的越靠前。

FINAL 是兜底规则,匹配所有未被前面命中的连接,必须放在最后一行;把它写在中间,等于给它后面的所有规则判了死刑。IP 类规则还有两个细节:带 no-resolve 表示这条规则不触发 DNS 解析,只在目标本身就是 IP 字面量时匹配;不带 no-resolve 的 IP-CIDR 会先把域名解析成 IP 再比对,解析结果不同就可能出现时灵时不灵。

• FINAL 不在最后一行,排在它后面的规则全部失效。
• DOMAIN-KEYWORD 排在 DOMAIN 或 DOMAIN-SUFFIX 之前,把本该精确处理的域名一并拦掉。
• GEOIP,CN,DIRECT 排在具体域名规则之前,国内域名全部直连,后面的规则轮不到。
• 订阅自带的规则压在自己新增的规则前面,自建规则永远匹配不到。

拦截边界:HTTPS、应用内请求与域名前置

REJECT 生效在连接建立阶段:它在本地拒绝或丢弃连接,不参与 TLS 握手之后的数据交换。这决定了它的能力上限——它管的是「这条连接能不能通」,不是「页面里显示什么」。

边界一:HTTPS 只拦到连接层

对 https://ads.example.com/x.js 这样的请求,REJECT 拦掉的是到 ads.example.com:443 的连接,脚本自然拿不到。但如果推广内容与正文来自同一个域名(例如 example.com 下的一个接口),REJECT 就无能为力:拦掉整个域名,正文也会一起打不开。规则里没有按 URL 路径匹配的关键字,客户端看不到 HTTPS 请求的路径。

边界二:应用内请求与硬编码 IP

很多应用把上报地址写成 IP 字面量,或者从接口动态下发域名。前者域名规则匹配不到,需要 IP-CIDR 兜底;后者要等实际域名出现之后再补规则。按 IP 拦的代价是容易误伤——同一网段上往往还有正常服务,共享 CDN 的 IP 尤其如此。域名规则与 IP 规则是两条互补入口,分别对应下面两种发起方式:

DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,203.0.113.0/24,REJECT,no-resolve

另一个细节是 QUIC。走 UDP 443 的连接同样会经过规则匹配,但如果你写的是带 no-resolve 的 IP-CIDR,而应用是以域名形式发起连接的,这条规则不会触发解析,也就匹配不到。

边界三:域名前置

域名前置(domain fronting)的做法是:TLS 握手里的 SNI 与请求实际指向的 Host 不一致,SNI 通常是一个「干净」的域名。Shadowrocket 按连接的目标域名(即 SNI)匹配规则,DOMAIN-SUFFIX 拦的是 SNI 上的那个域名。按 SNI 拦会连带影响同一入口上的正常服务;按 Host 拦截则不在客户端规则的处理范围内。

规则写了却不生效:按这个顺序排查

规则不生效,原因大多落在「当前生效的配置」和「匹配顺序」这两件事上。按下面的顺序逐项确认,比反复重写规则更快。

1. 确认当前生效的 Config

   回 Home 看顶部显示的配置名。规则写在 A 配置里、当前选中的是 B,规则自然不会参与匹配。

2. 检查规则在列表中的位置

   看有没有更靠前的宽规则先命中,尤其是 DOMAIN-KEYWORD 排在 DOMAIN-SUFFIX 之前的情况。

3. 确认连接是域名还是 IP 发起

   域名规则匹配不到 IP 直连;带 no-resolve 的 IP-CIDR 也不会为域名连接触发解析。

4. 确认 Global Routing 姿态

   停在 Proxy 或 Direct 时,规则列表不参与分流决策;回到 Config 才会按规则逐条匹配。

5. 更新订阅后复查规则

   订阅更新会重新拉取配置,本地手改的规则可能被覆盖;更新完回 Home 确认规则还在。

关于 REJECT 的五个常见问题