小火箭 On Demand 设置:按 Wi-Fi、蜂窝网络与域名触发连接

先区分自动连接与请求分流

On Demand 决定系统是否按条件建立 VPN 隧道；Global Routing 决定连接建立后如何处理请求。这是两个独立层次。自动连接成功，不代表每个请求都使用代理出站；某个请求命中 DIRECT，也不意味着系统应当断开 VPN。

在 Home 核对 Global Routing：Proxy 是全局代理姿态，Direct 是全局直连姿态，Config 按配置文件规则处理，Scene 按已设置的场景切换相关设置。测试规则分流时使用 Config，并确认 Config 中启用的是预期配置。Scene 不是 On Demand 的另一种名称，不能把场景切换与系统自动连接混为一谈。

Settings → On Demand：建立可核对的初始设置

开始前保存当前配置，并记下 On Demand 原有条件。Home 用于核对当前连接和服务器，Config 用于检查配置文件，Settings → On Demand 用于管理按需连接。不同系统与界面语言下，条件编辑项的排布可能不同，操作时应核对条件类型和动作含义，而不是只按某个开关的位置判断。

1. 记录基线。在 Home 记下当前服务器、Global Routing 姿态及手动连接结果；如果启用了 Scene，先排除场景自动变化对测试的影响。
2. 进入条件设置。打开 Settings → On Demand，核对启用状态、已有网络条件与动作。先只保留一个需要验证的条件，避免多条条件同时改动。
3. 允许系统保存 VPN 配置。首次配置时，如系统要求添加 VPN 配置，应核对提示后授权。系统设置中的 VPN 条目名称和位置随系统版本变化，以设备实际显示为准。
4. 保存后制造条件变化。完成编辑并返回后，切换一次 Wi-Fi 或蜂窝网络。不要仅停留在编辑页面等待，也不要把尚未保存的内容当作已生效规则。
5. 分别记录状态与访问结果。记录当前网络、VPN 是否连接、网页是否可访问。三项分开记录，才能区分触发失败与连接后分流失败。

On Demand 由系统网络机制执行，不要求持续把 Shadowrocket 留在前台。后台是否触发仍取决于系统是否收到符合条件的网络变化或连接请求；反复强制退出应用不是验证自动连接的必要步骤。

按 Wi-Fi 名称与蜂窝网络设置动作

Wi-Fi 条件中的名称是 SSID，不是路由器管理地址，也不是 Wi-Fi 密码。录入时保留原有大小写、空格与符号，不要自行在名称两侧加引号。双频网络若分别使用两个名称，应分别纳入需要匹配的条件；若共用同一名称，SSID 条件本身不能区分频段。

下面两张卡是条件设计示例，不是可以直接导入的配置文本。HomeNet 与 OfficeNet 是演示名称，实际填写时换成设备 Wi-Fi 列表中显示的真实 SSID。Connect 表示请求建立连接，Disconnect 表示在该条件下断开连接；具体动作选项以应用界面显示为准。

需要“HomeNet 断开，其余 Wi-Fi 连接”时，还必须明确处理其他 Wi-Fi 的条件，不能仅添加一条蜂窝网络 Connect 就认为已经覆盖。较具体的 SSID 条件应先于宽泛的网络条件；检查实际保存后的顺序，避免前面的宽泛匹配使后面的特定条件没有机会生效。

• 先测试 HomeNet 与蜂窝网络两种状态，再加入“其他 Wi-Fi”这一层，避免一次引入三个变量。
• 同名 Wi-Fi 可以出现在不同地点。仅凭 SSID 自动 Disconnect，不适合作为网络安全认证手段。
• 带网页登录验证的 Wi-Fi，应先完成网络登录，再判断服务器是否可达。已连上 Wi-Fi 不等于已经可以访问互联网。

域名触发：先理解 EvaluateConnection 的条件边界

系统按需 VPN 的域名机制属于连接评估，而不是在浏览器打开任意网址时执行一条开关命令。网络层面的 Connect 或 Disconnect 可以直接决定该网络条件下的动作；域名评估则通常通过 EvaluateConnection 及其域名动作，判断某次域名解析是否需要连接。仅当当前界面提供相应域名评估选项时，才按该方式配置，不要把域名填进 Wi-Fi 名称字段。

其中 ConnectIfNeeded 的重点是“需要时”：它可以结合 DNS 解析失败、指定 DNS 服务器或探测结果评估是否需要建立 VPN。域名已经在当前网络成功解析时，不应预期它必然拉起连接。NeverConnect 的含义是该域名不触发建立连接，也不是“访问这个域名便立即断开已经建立的 VPN”。

测试域名条件时，应使用确实由用户管理、且解析行为已知的测试域名，并排除 DNS 缓存影响。已打开的网页、复用中的连接、直接访问 IP 地址，以及应用自行使用加密 DNS，都可能使测试不产生预期的系统域名解析事件。示例域名 example.com 仅用于说明规则格式，不适合作为“必定解析失败并触发连接”的测试目标。

连接建立后，用 Config 规则决定域名走向

如果实际需求是“指定域名使用代理，其余请求直连”，通常应让网络条件负责建立连接，再由 Config 中的 Rule 负责请求分流。下面是规则片段示意，PROXY 需要对应当前配置中实际可用的策略名；不要在未核对策略定义时直接覆盖现有配置。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX,example.com,PROXY 匹配 example.com 及其子域名，作用是选择出站策略，不是创建 On Demand 域名条件。
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 按目标 IP 网段处理；no-resolve 表示不为了这条 IP 规则额外触发域名解析。
• GEOIP,CN,DIRECT 依赖目标 IP 与本地数据库的归属判断，不能代替精确域名规则，也不等于按网页语言分类。
• FINAL,PROXY 是前面规则均未命中时的兜底，应放在规则末尾。示例的兜底是代理，并非“其余全部直连”；如需后者，核对业务需求后将兜底改为 DIRECT。

验证时分两步：先确认 On Demand 已建立连接，再确认 Global Routing 为 Config，并检查请求实际命中的规则。如果使用 Proxy 姿态，不能根据结果判断上述分流片段是否生效；如果使用 Direct 姿态，也不能把网页可访问直接当作代理链路正常的证据。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等连接参数属于服务器协议层，和“什么条件下连接”不是同一个设置。已有服务的地址、端口或认证信息失效时，应先修复该层；增加 On Demand 条件不会改变协议配置的有效性。

用四种状态验证组合，而不是只看一次开关

每轮只改一项，保存后重新进入对应网络状态，并发起新的网络请求。下面列出的结果是前述示例组合的验收目标，不是对任何设备的实测承诺。网络切换期间存在连接重建过程，不应以刚切换那一瞬间的图标作为唯一依据。

若观察到“手动关闭后又连接”，先检查 On Demand 是否仍启用，以及当前网络是否持续满足 Connect 条件。系统再次按条件连接，并不等于应用忽略操作。需要临时保持断开时，先停用 On Demand，再关闭 Home 的连接；恢复时按原记录重新启用。

常见问题：自动重连、域名不触发与局部失败