On Demand 的三类触发条件分别匹配什么、在 Settings → On Demand 里怎么加规则、Action 选 Connect 还是 Disconnect,以及规则不生效时按什么顺序排查。适合已经能在 Shadowrocket 里手动连接、想让它在切换网络时自动开关的读者。
On Demand 是什么:一个总开关加一组规则
Shadowrocket(小火箭)的 On Demand 是「按需连接」:条件满足时由系统自动建立隧道,条件消失时自动断开,不必每次回到 Home 页去点连接开关。入口在 Settings → On Demand,页面结构只有两部分——顶部的总开关决定这套机制是否启用,下方的规则列表决定「在什么条件下连接、在什么条件下断开」。
这些规则最终写进 iOS 的 VPN 配置,由系统在网络状态变化时执行。所以 Shadowrocket 不必保持在前台,进程被系统回收后规则照样生效。反过来也要留意:配置一旦写入系统,卸载应用不会自动清掉它,「设置 → 通用 → VPN 与设备管理 → VPN」里可能还留着条目,需要在那里手动删除。
从条件命中到流量出站,中间隔着四步。前三步由系统与 Shadowrocket 自动完成;第四步走哪条线路、哪些域名直连,仍然由 Home 页的 Global Routing 与 Config 里的规则决定。On Demand 只管「连不连」,不管「怎么分流」,排查时不要把这两件事混在一起。
On Demand 只决定连接时机,不提供线路。订阅链接与节点请从你的服务商处获取;客户端买断 ≠ 线路套餐。
Wi-Fi 触发:用 SSID 决定连接还是断开
Wi-Fi 触发匹配的是当前连接的网络名称,也就是 SSID。添加路径是固定的:Settings → On Demand → 打开总开关 → 点规则列表右上角的 + → Type 选 Wi-Fi → 填 SSID → 选 Action。三个字段各管一件事:Type 决定看什么,Value 决定匹配值,Action 决定命中后做什么。
Action 只有 Connect 与 Disconnect 两种取值。家用 Wi-Fi 通常设 Disconnect:在家里走宽带直连,不需要隧道;公司 Wi-Fi、酒店与咖啡店的 Wi-Fi 设 Connect。省事的做法是只给「需要代理的网络」写 Connect 规则,其余网络不写,保持手动控制。
Wi-Fi 触发规则
- 入口
- Settings → On Demand → +
- Type
- Wi-Fi
- Value
- SSID,与系统显示逐字符一致
- Action
- Connect / Disconnect
- 建议
- 家用 Wi-Fi 设 Disconnect
路由器改名或换设备后,规则里的 SSID 需要同步修改。
蜂窝与域名触发规则
- 入口
- Settings → On Demand → +
- Type
- Cellular
- Type
- Domain
- Value
- example.com,只写主机名
- Action
- Connect
域名触发在系统准备访问该域名时拉起隧道。
SSID 的匹配是逐字符的:大小写不同、末尾多一个空格、混入全角字符,规则都会安静地不命中,界面上不会有任何报错。核对方法也很直接——在系统「设置 → 无线局域网」里看当前网络的名称,把它和规则里的 Value 对齐。
结论:先核对字符串,再怀疑机制
Wi-Fi 规则不生效时,先把 SSID 与系统里显示的字符串逐字符对一遍;字符串不一致是这类失效里最常见的一种,改完保存即可重新生效,不需要重装应用或重启设备。
蜂窝与域名触发:两个不依赖当前 SSID 的条件
蜂窝(Cellular)触发看的是当前承载流量的网络类型:没有连接 Wi-Fi、由蜂窝数据提供网络时命中。典型组合是「Wi-Fi 规则负责在家断开,蜂窝规则负责出门连接」,从家门走出去的瞬间隧道自动建立,不需要手动切换。
域名(Domain)触发看的是请求目标:系统准备访问某个域名时把隧道拉起来。写法只填主机名本身,例如 example.com,不要带 https://、不要带路径与端口,也不要写成 IP 地址。它适合「只有访问某个服务时才需要代理」的场景,比如公司内网域名,或者只在特定站点使用的线路。
域名触发有一个需要预期到的现象:规则在系统解析该域名、准备发起连接时生效,首个请求有时已经先发出去了,表现为第一次打开页面失败、刷新一次就正常。这是时序问题,不是规则写错了。
三类触发条件对照与常见误配
三类条件可以同时存在,系统按实际网络状态与请求目标各自判断。真正容易出错的不是规则本身,而是几条规则互相打架,或者规则与 Home 页的 Global Routing 姿态对不上。
| 触发类型 | 匹配对象 | 典型用法与容易踩的点 |
|---|---|---|
| Wi-Fi | 当前连接的 SSID | 家里设 Disconnect、公司设 Connect;SSID 逐字符匹配,路由器改名后旧规则失效 |
| Cellular | 当前是否由蜂窝数据承载 | 离开 Wi-Fi 后自动连接;与 Wi-Fi 互斥,同一时刻只有一个网络在承载流量 |
| Domain | 请求访问的主机名 | 访问 example.com 时自动连接;只写主机名,首个请求可能先走直连 |
结论:先用一条规则验证机制,再补齐其余条件
只给家里 Wi-Fi 写一条 Disconnect,在 Wi-Fi 与蜂窝之间来回切换,看状态栏的 VPN 标记是否按预期出现与消失。机制跑通后再加蜂窝与域名规则:从一条加到三条,排查成本不会翻倍;一次写满五条,出问题时要逐条二分。
开了 On Demand,连上家里 Wi-Fi 反而上不了网?
先看规则列表里针对家用 Wi-Fi 的那条是不是写成了 Connect。家里本来只需要直连,隧道被拉起后如果线路本身不可用,就会表现为打不开页面;把 Action 改成 Disconnect,再重新连一次 Wi-Fi。
换了路由器,原来的 Wi-Fi 规则没反应了?
SSID 变了。回到 Settings → On Demand 点开那条规则,把 Value 改成新网络的名字,大小写与空格都要一致;旧值不会命中,与其留着不如删掉这条再新建。
蜂窝下频繁自动断开又重连?
多半是同一场景里同时存在 Connect 与 Disconnect 两类规则,或者移动过程中网络类型反复变化。先把规则收敛成「一个网络一条动作」,观察是否还抖动,再决定要不要保留蜂窝规则。
域名规则要写完整网址吗?
不用。只写主机名,例如 example.com,不要带 https://、路径、端口或查询参数。带路径的写法不会命中,因为触发判断发生在解析目标主机名这一步。
关掉 Shadowrocket 后台,On Demand 还生效吗?
生效。规则写在系统 VPN 配置里,由系统在网络状态变化时拉起隧道;前提是这套配置已经成功建立过一次并在系统弹窗里获得授权,而且没有在系统设置里被删除。
验证与排查:按需连接没按预期工作时怎么办
按固定顺序排查,比反复重装应用有效。下面五步覆盖了绝大多数情况,每一步都能在设备上直接看到结果。
-
确认总开关Settings → On Demand 顶部的开关处于打开状态,规则列表里至少有一条规则。
-
核对规则三要素Type、Value、Action 逐项确认;SSID 与系统「设置 → 无线局域网」里显示的字符串一致。
-
确认系统 VPN 配置iOS「设置 → 通用 → VPN 与设备管理 → VPN」里能看到对应配置;状态栏出现 VPN 标记,表示隧道已经建立。
-
确认分流姿态Home 页的 Global Routing 停在 Config,按规则分流;停在 Direct 时,即使隧道建立也不会按预期走代理。
-
重建配置在 Home 页把连接开关关掉再打开,让 Shadowrocket 重新写入 VPN 配置;仍不正常,就在系统 VPN 列表里删除旧配置后重新连接一次。
五步走完仍不生效,通常说明规则之间在互相干扰。把 On Demand 列表精简到当前真正需要的两三条,再逐条加回来,比一次性写十条规则更容易定位问题。规则本身只描述「何时连接」;连接之后能不能通,还要回到订阅是否更新、线路是否可用这些环节去查。