适合已经在 Shadowrocket（小火箭）中导入自己的可用配置、希望切换 Wi-Fi 与蜂窝网络时减少手动操作的读者。下文给出 Settings → On Demand 的设置顺序、Wi-Fi 名称与域名的填写边界，以及自动连接结果不符合预期时的逐项核对方法。
先区分按需连接与规则分流
On Demand 处理的是“什么时候连接”这一层：设备进入某种网络环境，或出现符合条件的域名请求时，由系统根据已保存的 VPN 配置尝试执行连接或断开动作。Home 中选中的配置、节点及 Global Routing 则处理连接建立之后的流量走向。把两个层次混在一起，容易出现“开关自动打开了，网页却没有按预期分流”的误判。
开始前，在 Home 手动连接一次，确认系统 VPN 权限已获允许，且用户已有的配置可以正常使用。再到 Settings → On Demand 查看按需连接设置。首次启用或修改条件后，回到系统 VPN 状态与 Shadowrocket 的 Home 交叉核对结果；不要仅凭应用页面上的一个开关推断所有请求都已通过同一出口。
按 Wi-Fi 名称设置连接与断开
Wi-Fi 条件针对设备当前连接的无线网络名称，即 SSID，而不是路由器的备注名，也不是网页地址。设置前先在设备的 Wi-Fi 设置中确认实际名称；同名的不同网络会增加判断难度。若家中与工作场所都使用同一个 SSID，只靠名称就无法清楚区分这两个地点。
- 先在设备 Wi-Fi 设置中记下要测试的 SSID，例如
Home-WiFi；同时确认设备确实连接到该网络。 - 进入 Shadowrocket 的 Settings → On Demand，启用按需连接，并在页面提供的 Wi-Fi 条件中填写或选择该名称。按照实际需要，为匹配与未匹配的网络分别检查 Connect、Disconnect 等动作；可见选项以应用内页面为准。
- 暂时只保留这组 Wi-Fi 条件。离开该 Wi-Fi 后重新接入，观察系统 VPN 状态与 Home 的连接状态，再换一个名称不同的 Wi-Fi 做反向验证。
例如，目标是“接入 Home-WiFi 时断开、离开后按其他条件连接”，就必须分别检查接入和离开的结果。SSID 的大小写、空格及末尾字符都值得核对；把显示名称抄错一个字符，通常就会使该条件无法匹配。设备虽靠近路由器但实际仍在使用蜂窝网络时，也不能把结果归因于 Wi-Fi 条件。
Wi-Fi 核对卡
- 入口
- Settings → On Demand
- 匹配对象
- 当前连接的 SSID
- 示例名称
- Home-WiFi
- 验证动作
- 离开并重新接入该网络
先用一个唯一的 SSID 测试，再增加其他网络名称。
状态核对卡
- Wi-Fi 状态
- 确认设备已接入目标网络
- VPN 状态
- 查看系统与 Home 的显示
- 反向测试
- 切到另一名称的网络
- 异常线索
- 同名 SSID 或名称录入错误
网络变化是测试起点，状态变化才是核对结果。
蜂窝网络条件怎样单独验证
蜂窝条件适合在设备从 Wi-Fi 离开、实际改用 Cellular 时触发相应动作。测试时先确认设备具有可用的蜂窝数据连接；仅关闭 Wi-Fi 而蜂窝数据不可用，不能证明 On Demand 的蜂窝条件工作与否。iPad 是否具备蜂窝网络能力，取决于具体设备。
- 先保持 Home 中同一份已验证可用的配置，进入 Settings → On Demand，只设置要测试的 Cellular 条件。
- 在设备设置中关闭 Wi-Fi，确认状态栏显示正在使用蜂窝网络，再观察系统 VPN 状态是否按所选动作变化。
- 重新打开 Wi-Fi，接入已知 SSID，记录第二次状态变化。若两次结果不同，分别记下网络类型、连接状态和测试时间，再添加其他条件。
“蜂窝网络时连接”并不等于“所有蜂窝请求都使用 PROXY”。连接建立后，若 Global Routing 选为 Direct，请求仍可能直连；若选为 Config，请求继续依照配置中的规则匹配。Proxy、Direct、Config、Scene 是 Global Routing 的不同姿态，应与 On Demand 的连接动作分开检查。需要定位问题时，先固定一种 Global Routing 姿态，避免一次改动多个变量。
判断：先证明网络已切换
蜂窝测试没有出现预期动作时，先确认设备已离开 Wi-Fi 且蜂窝数据可用，再检查 On Demand；不要先修改节点、规则和订阅，因为这些项目不能证明蜂窝触发条件是否匹配。
域名条件何时触发
域名条件用于指定名称相关的请求出现时尝试连接，并不是浏览器地址栏里每输入一次文字都必然触发。测试应使用可明确识别的域名，并观察实际发起的名称解析或连接行为。已有连接、缓存中的解析结果、应用直接访问 IP 地址等情况，都可能使一次页面操作不足以验证域名触发。
把测试域名写成 example.com 可以说明填写格式，但它只是示例值，不代表可用的触发测试服务。正式核对时，应选用自己有权访问、能稳定产生新请求的域名，按设置页支持的格式填写。域名条件与规则里的 DOMAIN-SUFFIX,example.com,PROXY 也不是一回事：前者用于判断是否尝试建立 VPN 连接，后者是在 Config 姿态下对已进入规则处理的请求选择策略。
- 只测域名时，先暂时移除容易同时命中的 Wi-Fi、Cellular 条件，记录 VPN 初始状态，再发起一次新的域名访问。
- 访问没有触发时，确认输入的是域名而非 IP 地址，并核对条件中填写的主机名、后缀及应用内提供的匹配选项。
- 连接已建立但访问结果不符预期时，转而检查 Home 的配置及 Global Routing；不要把规则命中问题当成域名触发失败。
例如，规则 FINAL,PROXY 是未命中前面规则时的兜底策略，并不能让 On Demand 自动识别一个尚未设置的域名条件。反过来，域名条件触发连接后，也不保证该域名一定使用 PROXY：在 Config 姿态下，具体策略仍取决于规则顺序和匹配结果。
多个条件同时存在，按什么顺序排查
不要假定 Wi-Fi、Cellular 和域名条件之间存在一条适用于所有场景的固定优先级。设备当前实际使用的网络、条件是否匹配、系统 VPN 状态、域名请求是否真正发生，都会影响观察到的结果。排查“冲突”更可靠的办法是依次确认前提，再逐个启用条件，而不是靠调整规则列表顺序猜测 On Demand 的动作。
先记录设备是接入目标 SSID、其他 Wi-Fi，还是 Cellular；接着核对对应条件的名称与动作。若连接状态已按预期改变，就继续核对 Home 的选中配置和 Global Routing。只有在需要诊断单个网站时，才检查域名触发及 Config 中的规则。这样可以把“没有触发连接”“连接后没有命中期望规则”“已有配置本身不可用”分为三类问题。
回到家里 Wi-Fi，为什么没有按预期断开？
在设备 Wi-Fi 设置里核对当前 SSID 与 On Demand 所填名称是否一致，再检查该条件选择的是 Connect 还是 Disconnect。先停用其他条件，只做离开与重新接入该 Wi-Fi 的测试。
关掉 Wi-Fi 后，为什么没有自动连接？
先确认设备确实切换到可用的 Cellular，而不是暂时没有网络；然后在 Settings → On Demand 单独核对蜂窝条件。手动连接也失败时，应先排查已有配置的可用性。
打开指定网站，为什么 VPN 状态没变化？
核对域名条件的填写内容，确认访问不是直接使用 IP 地址。换一次明确的新请求进行复测，并暂时移除可能同时生效的网络条件，避免把已有连接状态当作新触发结果。
VPN 已连接，为什么流量仍像是直连？
到 Home 查看 Global Routing 是否为 Direct。需要按配置规则分流时，检查 Config 姿态及对应规则；On Demand 只负责连接触发，不替规则选择 PROXY 或 DIRECT。
完成单项测试后，再逐个恢复条件，每次只改变一项，并分别在目标 Wi-Fi、其他 Wi-Fi 与 Cellular 下记录结果。如果某个组合无法稳定复现，保留最必要的触发条件通常比叠加更多条件更容易核对。修改后仍以系统实际显示的 VPN 状态和访问结果为准。
保存配置前的检查清单
- Home 中的配置已手动验证；On Demand 不会修复失效的连接配置。
- Wi-Fi 条件使用实际 SSID，且测试时设备确实接入该网络。
- Cellular 条件在蜂窝数据可用、Wi-Fi 已断开的情况下单独验证。
- 域名条件用新的域名请求验证，不用规则关键字代替触发条件。
- 连接状态与分流结果分别检查；需要按规则处理时，再核对 Global Routing 的 Config 姿态。
Shadowrocket 是 App Store 中的一次性买断客户端；客户端买断 ≠ 线路套餐。On Demand 所操作的是设备上的连接条件，仍需用户已有自己的可用配置。若还没有核验应用来源，可先查看本站的正版核验说明，再按使用教程完成基础连接。