这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 VPN 可能添加默认路由、阻止本地 LAN 或只代理 TCP。ICE 会看到多个接口，但候选是否可用取决于系统路由和 VPN policy，而非地址长相。
网络诊断必须区分观察事实与推断结论。候选类型、选中路径和阶段耗时可以证明连接过程，完整 IP 或一次探测结果既不必要，也不足以代表真实可达性。
先把实现决策说清楚
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 网络变化时触发有版本的 ICE restart，比较 selected pair networkType 与 relay；提供“允许本地网络”和 UDP 被禁的诊断提示。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“VPN 对 WebRTC 的影响：分流路由、虚拟网卡与候选泄漏”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- VPN 开关后继续使用旧 candidate pair 会单向黑洞；为了直连绕过 VPN 可能违反用户或企业明确的泄漏保护。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 没有背压或配额时，慢消费者会把内存、队列长度与尾延迟一起推高，最后拖累无关用户。
上线前怎样验证
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 覆盖连接前开 VPN、连接后开关、全隧道、分流、禁 LAN 和 TCP-only，验证路径、隐私意图、恢复时间与用户提示。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。