Shadowrocket（小火箭）的 On Demand（按需连接）决定系统何时启动或断开 VPN 连接，不负责替代连接后的分流规则。本文面向已有可用连接与配置的用户，先设置指定 Wi-Fi 与蜂窝网络的动作，再解释域名条件为何不等于“打开某个网页就一定连接”，最后用逐项验证的方法排查规则顺序与自动重连问题。
一、先区分 On Demand 与连接后的规则分流
配置前先给出结论：按网络环境自动连接，检查 Settings → On Demand；已经连接但某个网站的去向不对，检查 Home → Global Routing 与 Config 中当前启用的配置。两者处于不同阶段，把域名分流规则写进配置，并不等于创建了系统的按需连接触发条件。
On Demand 依赖 Apple 系统的 VPN 按需机制。系统根据当前网络及已保存的条件评估是否连接；连接成功后，Shadowrocket 才按选定的路由方式处理流量。网络切换、名称解析需求等事件可以参与评估，但这不是一个不断扫描前台网页内容的功能，也不是按 App 打开与关闭来计时的开关。
Proxy（代理）：使用代理路由姿态，不等同于按配置逐条分流。Direct（直连）：使用直连路由姿态。VPN 显示连接，不代表业务请求一定经过代理出站。Config（配置）：按照当前启用配置中的规则决定请求去向，适合验证域名分流。Scene（场景）：用于场景化路由选择，应同时核对当前场景的设置；它不是 On Demand 的连接动作。
例如，配置中的 DOMAIN-SUFFIX,example.com,DIRECT 表示域名后缀命中后直连；FINAL,DIRECT 是前面规则未命中时的最终去向。这些规则不会自行启动系统 VPN。GEOIP（按 IP 地理归属匹配）与 IP-CIDR（按 IP 网段匹配）也属于流量处理层，不能替代 Wi-Fi 或蜂窝网络条件。
二、配置前核对入口、连接与恢复方式
先手动连接成功，再开启自动化。本文以 iPhone 与 iPad 的设置过程为主，系统要求以 App Store 页面标注为准。不同系统与应用界面的可选字段可能存在差异，实际可保存的条件以 Settings → On Demand 当前页面为准，不要把系统动作名称当成每个界面都必然出现的按钮。
- 在
Home（首页）选择用户已有的可用连接，手动打开连接开关。首次出现添加 VPN 配置的系统提示时，核对应用后按系统流程确认。 - 打开一个平时能够访问的页面，确认网络本身正常。若手动连接都失败，先处理连接参数、网络可达性或配置问题。
- 记录当前
Global Routing的姿态，以及Config中正在启用的配置，避免测试时顺手切换后忘记恢复。 - 进入
Settings → On Demand，先记录已有条件及排列顺序。只调整本次需要验证的一项，不同时更新订阅或更换连接。 - 记住系统
设置 → 通用 → VPN 与设备管理 → VPN中对应的 VPN 配置位置。系统显示“按需连接”相关选项时，应一并核对它的状态。
结论：先得到一个手动可用的基线
同一网络下先手动连通，再只改 On Demand 条件。这样出现异常时，可以直接判断是触发没有发生，还是触发后连接本身没有成功。
三、按 Wi-Fi 名称设置连接或断开
Wi-Fi 名称条件通常对应 SSID（无线网络名称）。它识别的是网络名称，不是路由器品牌，也不是网站域名。以下使用虚构名称 Home-WiFi 演示“指定 Wi-Fi 断开、蜂窝网络连接”的配置目标；是否适合让某个网络断开，应由实际访问需求决定，不能仅凭网络叫“家庭”就判断其可信。
- 在系统 Wi-Fi 设置中核对当前接入的完整名称，保留名称中的空格、符号与大小写，不使用“家里网络”之类的备注替代真实 SSID。
- 进入
Settings → On Demand，编辑 Wi-Fi 条件，将需要匹配的网络名称填为实际 SSID。本例的Home-WiFi只用于说明。 - 如果目标是该网络下不保持此 VPN 连接，将匹配后的动作设为
Disconnect（断开）；如果该网络下需要连接，则使用Connect（连接）。按当前界面提供的方式保存。 - 检查是否还有覆盖全部 Wi-Fi 的宽泛条件。特定 SSID 的例外应先于可能覆盖它的通用条件。
- 离开该 Wi-Fi，再重新接入，观察 VPN 状态；不要只在原网络上保存后立即用一次网页加载结果判断成功。
指定 Wi-Fi 的配置目标
- 入口
- Settings → On Demand
- 网络类型
- Wi-Fi
- SSID
- Home-WiFi（虚构示例）
- 动作
- Disconnect：该网络下断开
这是填写目标的说明，不是可直接导入的配置文本；实际名称须换成当前网络的 SSID。
蜂窝网络的配置目标
- 入口
- Settings → On Demand
- 网络类型
- Cellular：蜂窝网络
- SSID
- 不适用，SSID 属于 Wi-Fi 条件
- 动作
- Connect：该网络下连接
仅在支持并已启用蜂窝数据的设备上测试；连接成功仍取决于已有连接能否正常使用。
Disconnect 的含义是断开此 VPN，不是关闭设备的 Wi-Fi，也不是拦截全部网络流量。若只是希望家中某个域名直连，通常应保留连接并在 Config 内配置分流，而不是把整个家庭 Wi-Fi 都设成断开。两种做法的影响范围不同。
四、蜂窝网络自动连接与规则先后顺序
在支持蜂窝数据的设备上，可以让 Cellular（蜂窝网络）条件使用 Connect。离开指定 Wi-Fi 后，系统切换到蜂窝数据，再评估相应条件。切换期间仍要经过网络可用、VPN 建立与后续请求等过程，不能把按需连接理解成所有已有连接都会无缝保留。
| 评估顺序 | 条件 | 动作 | 核对重点 |
|---|---|---|---|
| 优先例外 | Wi-Fi，SSID 为 Home-WiFi | Disconnect | 名称与实际接入网络一致 |
| 网络类型 | Cellular | Connect | 设备当前确实使用蜂窝数据 |
| 末尾通用项 | 其余需要连接的网络 | Connect | 仅在界面支持且确有需要时添加 |
系统按需规则按顺序评估，先命中的适用规则决定相应动作。若最前面的通用连接条件已覆盖所有 Wi-Fi，后面的指定 SSID 断开条件就可能没有机会生效。Shadowrocket 界面可能将条件按网络类型组织，核对时既要看页面中的顺序，也要看条件覆盖范围，不能只看某个开关是否开启。
- 先放窄范围例外，再考虑宽范围默认条件，避免通用条件提前覆盖例外。
- 没有匹配条件时，不要假定系统一定会连接或断开；应明确配置所需的剩余网络行为并实际验证。
- 手动断开不等于取消自动连接。后续网络事件再次满足
Connect时，系统可能重新建立连接。 - 需要持续手动控制时，先关闭 On Demand 并核对系统中的按需状态，再操作连接开关。
没有蜂窝功能的 iPad 无法完成蜂窝切换测试。Wi-Fi 连接到另一台设备的个人热点时，本机使用的仍是 Wi-Fi 接口，应按本机所见的网络类型评估，而不是按照热点提供方的上网方式判断。
五、域名按需触发不是 DOMAIN-SUFFIX 分流
“访问域名时连接”需要单独理解。Apple 的按需机制中，EvaluateConnection（评估连接）可以结合域名及解析相关条件决定是否建立 VPN。它与连接后匹配 DOMAIN-SUFFIX 的机制不同，也不能笼统理解为监听浏览器地址栏。
系统域名评估中的 ConnectIfNeeded（需要时连接）通常与 DNS 解析失败、所需 DNS 服务器不可用等条件有关；NeverConnect（不为匹配域名启动连接）也不是一条网站封锁规则。这些是系统机制名称，只有当前 Shadowrocket 界面提供相应条件时，才能按页面支持的选项设置，不能直接当作配置文件关键字粘贴。
- 先确认需求：是“隧道未连接时，访问内部域名需要建立连接”，还是“隧道已连接时，某个网站需要走指定去向”。后者应在
Config处理。 - 在
Settings → On Demand中核对是否提供域名相关条件及其可选动作。若当前界面只提供网络类型条件，就按其实际能力配置，不自行编造字段。 - 如果界面支持域名条件，使用自己有权访问且确实需要该网络环境才能解析的域名测试。
internal.example.com仅是语法说明，不能用于验证真实连通性。 - 按照字段用途填写主机名或域名，不填完整 URL。
https://internal.example.com:443/path中的协议、端口与路径不属于域名本身。 - 先记录未连接时的 DNS 结果，再启用条件测试；如果域名在普通网络已经解析成功，不能期待“需要时连接”必定触发。
DNS 缓存、浏览器已有连接、App 自行使用的加密 DNS，都可能改变系统是否观察到一次新的解析需求。仅刷新已打开的页面，可能没有产生预期的评估事件。应同时观察 VPN 状态与实际解析结果，而不是把页面打开成功直接归因于 On Demand。
如果需求只是“example.com 直连，其他请求按现有配置处理”，应在活动配置中安排相应域名规则，并选择 Global Routing → Config。域名分流只决定去向；断开整条 VPN 则会影响其他应用的请求，不能互相替代。
六、用三个场景检查设置是否生效
每次只改一个变量：保留同一个已有连接、同一份活动配置与相同的测试页面。下面是验证时应记录的现象，不是固定耗时或实测性能承诺。系统评估与隧道建立并非瞬间完成，应等待状态稳定后再判断。
| 测试场景 | 操作 | 应核对的现象 | 异常时先查 |
|---|---|---|---|
| 接入指定 Wi-Fi | 重新加入已设例外的 SSID | VPN 是否按 Disconnect 目标断开 | SSID 与通用条件覆盖范围 |
| 切换到蜂窝数据 | 关闭 Wi-Fi，确认蜂窝数据可用 | VPN 是否开始连接并最终连通 | Cellular 条件、已有连接可用性 |
| 访问需内部解析的域名 | 在适用的域名条件下发起新解析 | 是否发生评估、连接后能否解析 | DNS 缓存、解析路径与域名条件 |
若状态显示已经连接而页面仍失败，问题已经进入连接后的处理阶段。此时检查 Global Routing、活动 Config、DNS 与目标可达性，不应反复修改 Wi-Fi 名称条件。若根本没有连接动作，则先检查按需开关、当前接口类型和规则优先级。
- 公共 Wi-Fi 需要网页认证时，先完成网络登录再测试。Wi-Fi 已连接不代表该网络已经能访问互联网。
- 暂时关闭 On Demand 后，在相同网络手动连接；若仍然失败，优先排查连接本身，而不是自动触发条件。
- 测试过程中不要同步更新订阅或更换节点，否则连接参数变化会干扰对触发结果的判断。
- 结束测试后恢复最终需要的路由姿态与条件，避免把临时的全局直连或通用连接条件留在日常配置中。
七、自动重连、名称匹配与电量常见问题
手动关掉连接，为什么又自己连上了？
先进入 Settings → On Demand 检查是否仍有匹配当前网络的 Connect 条件，再到系统 VPN 配置核对按需状态。需要暂停自动化时，关闭按需功能后再断开，不要只反复拨动 Home 的连接开关。
设置了家里 Wi-Fi 断开，回家后还是连接？
在系统 Wi-Fi 页面重新读取完整 SSID，检查是否实际接入了名称不同的另一频段网络。随后检查覆盖所有 Wi-Fi 的通用 Connect 条件是否先命中；不要仅凭路由器相同就认定 SSID 条件相同。
打开指定域名没有触发，是域名规则写错了吗？
先确认写的是 On Demand 域名条件，而不是 Config 内的 DOMAIN-SUFFIX。再检查该域名是否已被缓存、是否在普通网络就能解析，以及请求是否经过系统可评估的解析路径；“页面打开了”本身不能证明发生过新的触发。
按需连接一定比保持连接省电吗？
不能只凭开关判断。先在系统 设置 → 电池 对照相同使用时段的活动情况；如果频繁切换网络导致重复建立隧道，应减少不必要的条件切换。按实际连接需求设置，避免为了测试而不断断开重连。
最终检查顺序保持一致：先确认网络可用，再确认系统是否触发连接，最后检查连接后的路由与 DNS。按这三个阶段记录现象，比同时修改 On Demand、订阅和配置更容易找到原因。更多基础操作可从本站教程继续核对。