Shadowrocket On Demand 规则设置:按 Wi-Fi、蜂窝网络与域名自动连接

先区分 On Demand、Global Routing 与 Config

Shadowrocket（小火箭）的 On Demand 是系统按需连接机制的配置入口。网络环境变化或符合特定按需评估条件时，由系统判断是否建立连接。它不是“每个请求都先问一次是否打开代理”的开关，也不等于让应用持续停留在前台。

Home 中的 Global Routing 则控制连接后的流量处理姿态。Proxy、Direct、Config、Scene 与 On Demand 所处层次不同：前者处理流量如何走，后者处理隧道何时连接。排查时应分别记录两项，避免看到 VPN 已连接就认定某个域名一定经过代理。

• Settings → On Demand：配置按需连接条件与动作，并核对系统中对应 VPN 配置的按需连接状态。
• Home → Global Routing：核对当前姿态。使用 Config 规则进行验证时，选择 Config，而不是停留在 Proxy 或 Direct。
• Config：管理流量分流规则，例如 DOMAIN-SUFFIX、IP-CIDR 与 FINAL。

设置前先建立可复现的连接基线

先让同一份配置在手动连接下正常工作，再开启自动化。On Demand 不会修正错误的服务器地址、认证参数或失效配置。若手动连接已经失败，叠加自动重连只会增加现象，无法帮助定位原始问题。

1. 在 Home 选中自己已有的可用配置，记录当前 Global Routing 姿态；需要检查分流时使用 Config。
2. 暂时关闭 Settings → On Demand 中的按需连接，手动连接并访问一个平时可以正常打开的页面，确认基础连接可用。
3. 记录测试用 Wi-Fi 的准确 SSID。以系统 Wi-Fi 列表中的名称为准，不使用路由器型号或自己给网络起的备注代替。
4. 进入 Settings → On Demand，先建立最少的网络条件；每次只改一条，再保存并切换网络验证。
5. 在系统“设置 → 通用 → VPN 与设备管理 → VPN”中查看对应配置。系统界面名称可能有差异，重点是确认查看的确实是 Shadowrocket 使用的那份配置。

按 Wi-Fi 名称与蜂窝网络设置条件

常见目标是“指定 Wi-Fi 不自动连接，其他网络自动连接”。实现重点不是把所有 Wi-Fi 名称逐个列出，而是先放准确的例外，再放较宽的网络条件。下面的 Home-WiFi 是示意名称，实际设置时应填写设备当前看到的 SSID。

SSID 条件识别的是网络名称，不是对路由器身份的认证。不同地点可以出现同名 Wi-Fi，因此不要把名称命中视为可信网络证明。相同名称的不同频段也可能被同一条规则覆盖；如果名称不同，则需要分别考虑。

• 若还有“其他 Wi-Fi 使用 Connect”的规则，将它放在指定 SSID 的 Disconnect 之后。
• 仅在确实需要时增加不限定网络类型的兜底规则。过早放置宽泛 Connect，会遮住后面的具体条件。
• 检查 Wi-Fi 名称读取所需的系统授权；读不到 SSID 时，不要假设指定名称的例外已经命中。
• 公共 Wi-Fi 可能需要先完成网络登录。网络尚不能正常联网时，Connect 只表示尝试连接，不表示一定成功。

多条规则同时命中时，先看外层顺序

系统的外层 On Demand 规则按列表顺序评估，使用首条匹配规则的动作，而不是把所有命中的动作叠加。单条外层规则若同时规定接口类型与 SSID，就需要同时满足；一个 SSID 列表中的多个名称则用于匹配其中之一。域名评估属于另一层，不能直接套用为普通网络条件。

Connect 表示在条件满足时发起连接；Disconnect 表示断开并在该条件下不按此机制建立连接。Ignore 的含义是本次按需评估不改变连接状态，不等于 Disconnect，也不是“跳过这一条继续找下一条”。若希望某个网络明确保持断开，应选择符合目标的动作，而不是依靠 Ignore。

1. 将明确的例外放在宽泛条件之前，保存后重新进入页面核对顺序。
2. 通过实际加入与离开网络触发评估，不只在原网络内反复刷新网页。
3. 分别记录“命中后没有发起连接”和“发起连接但失败”，后者还需要检查基础网络与已有配置。

域名自动连接：区分按需评估与分流匹配

“访问某个域名就连接”有两种不同需求：一种是在隧道未建立时按域名评估是否需要连接；另一种是在隧道已经建立后让特定域名走 PROXY。前者属于系统 On Demand 的 EvaluateConnection 机制，后者属于 Config 规则。只添加 DOMAIN-SUFFIX 不会自动产生前者的能力。

在系统规则语义中，EvaluateConnection 可以包含域名评估项。ConnectIfNeeded 会结合域名解析与可达性条件判断是否需要建立隧道，不是看到任意网页地址就无条件连接。NeverConnect 则表示该域名评估项不触发连接；它不等于流量规则中的 DIRECT，也不负责断开已经存在的连接。

• 先核对入口：在 Settings → On Demand 查看当前界面是否提供域名评估相关选项。若只有 Wi-Fi、Cellular 等网络条件，不要把域名填进 SSID，也不要假设粘贴分流规则就能增加系统功能。
• 填写域名而非 URL：域名条件使用类似 example.com 的名称，不写 https://、路径 /account 或端口 :443。具体匹配范围以该字段说明为准，不随意添加通配符。
• 留意首条外层命中：如果前面已经有任意 Wi-Fi 的 Connect，后面的 EvaluateConnection 就没有机会被选中。需要域名按需评估时，应重新设计相应网络下的动作。
• 考虑 DNS 缓存：已有解析结果、应用自己的解析方式以及直接访问 IP，都可能让测试不出现新的域名评估。只按网页刷新键不能证明规则未生效。

如果目标只是“example.com 走代理，其余流量直连”，可在现有 Config 中按实际策略名称设置分流。以下仅展示规则语法，假定当前配置中 PROXY 策略有效；它不是 On Demand 配置，也不包含任何连接服务。

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

使用这段规则时，需要先有可工作的隧道，再让 Global Routing 采用 Config。若原配置已有其他规则，不要直接用两行示例覆盖全文；应检查前方是否存在更早命中的条件，并保留原有必要设置。

用固定测试步骤排查自动连接异常

测试时保持同一份已有配置，只切换一个条件。每次记录当前网络、预期动作、实际 VPN 状态和网页结果四项。网页能打开只说明这次访问成功，不能单独证明 On Demand 命中，也不能证明流量走了 PROXY。

1. 测试指定 Wi-Fi：加入配置中的 SSID，等待网络完成连接，再检查 VPN 状态。若目标为 Disconnect，应确认没有其他自动化重新建立连接。
2. 测试其他 Wi-Fi：换到一个名称不同且可以正常联网的网络，核对宽泛 Connect 是否发起连接；不要把网络登录页未完成误判为配置错误。
3. 测试 Cellular：关闭 Wi-Fi 并确认蜂窝数据可用，再观察隧道状态。测试期间保持相同 Global Routing 姿态。
4. 测试域名：仅在实际配置了域名评估时进行。先确认隧道未连接，再发起新的域名访问，并结合连接状态与可用日志判断，不只看页面是否加载。
5. 恢复基线：出现反复重连时，关闭 On Demand 后手动测试；手动也失败，就先处理网络或已有配置问题。