Tailscale 网络中 WebRTC 连接失败的 ICE 候选诊断与平台差异排查

当 WebRTC 运行在 Tailscale 网络中时，开发者实际上要面对两层 NAT 穿透机制：WebRTC 自身的 ICE（Interactive Connectivity Establishment）框架负责在公网环境下建立点对点连接，而 Tailscale 基于 WireGuard 的 mesh VPN 则提供了私网内的直连能力。这两层机制的叠加会在 iPad 与 Mac 这类跨平台场景中暴露出微妙的兼容性问题，尤其是在 ICE 候选收集阶段。

问题背景：双 NAT 穿透的复杂度

WebRTC 的标准连接流程依赖 ICE 框架收集三类候选地址：host 候选（本地网卡 IP）、srflx 候选（通过 STUN 服务器反射后的公网地址）、relay 候选（通过 TURN 中继的地址）。Tailscale 为每个设备分配 100.x.x.x 网段的虚拟 IP，并尝试通过 NAT 穿透建立 WireGuard 隧道。当应用同时在 Tailscale 网络内运行 WebRTC 时，ICE 候选收集会同时看到 Tailscale 虚拟网卡和物理网卡的多组地址，这可能导致候选配对优先级混乱或连接超时。

ICE 候选收集诊断：三类候选的获取逻辑

排查 WebRTC 连接失败的第一步是确认双方是否成功收集到完整的 ICE 候选集合。在浏览器环境中，可通过 chrome://webrtc-internals 或 Safari 的 WebRTC 日志查看候选列表；在原生应用中，需监听 RTCPeerConnection.onicecandidate 事件并输出候选类型。

关键观察点：

• Host 候选：应包含 Tailscale 虚拟 IP（100.x.x.x）和本地物理 IP（192.168.x.x）。如果仅出现物理 IP，说明 Tailscale 接口未被 WebRTC 纳入候选范围，可能需要检查应用的网络权限或绑定接口配置。
• Srflx 候选：通过 STUN 服务器获取的反射地址。在 Tailscale 网络中，这部分候选可能指向 Tailscale 的 DERP 中继地址而非真实公网 IP，需结合 iceTransportPolicy 参数决定是否过滤。
• Relay 候选：TURN 服务器提供的中继地址。如果双方位于不同物理网络且 Tailscale 直连失败，TURN 候选将成为 fallback 选项。

iPad 与 Mac 的平台差异

iOS（iPad）和 macOS 在网络权限和 ICE 行为上存在显著差异，这往往是跨平台 WebRTC 连接失败的根源。

iOS 特有约束：

iOS 对后台网络活动和 UDP 端口访问有严格限制。蜂窝网络或企业 Wi-Fi 环境可能阻断非常用端口的 UDP 流量，导致 TURN 候选无法建立。建议将 TURN 服务器配置为同时监听 443（TCP/TLS）和 3478（UDP）端口，并在 ICE 配置中设置 iceTransportPolicy: 'all' 以允许 TCP 候选。

此外，iOS 的 WebRTC 实现（WKWebView 或 Safari）对候选收集的触发时机与 macOS 不同。iPad 可能在 RTCPeerConnection 创建后延迟触发 onicecandidate 事件，调试时需在信令交换阶段增加足够超时（建议 ≥5 秒）。

Mac 端诊断：

macOS 的 WebRTC 实现相对开放，但仍需注意防火墙和 Tailscale 路由的交互。通过终端执行 tailscale status 可确认对端设备的虚拟 IP 和连接状态（direct 或 relay）。如果显示为 DERP relay，说明 Tailscale 层面已无法建立直连，此时 WebRTC 的 host 候选（100.x.x.x）可能因路由不可达而失败，应优先依赖 srflx 或 relay 候选。

可落地的排查清单

基于上述分析，以下是针对 Tailscale + WebRTC 场景的系统性排查步骤：

1. Tailscale 连通性验证

   • 双方执行 tailscale status 确认虚拟 IP 可达
   • 检查 ACL 规则是否放行 WebRTC 所需端口（默认 UDP 1024-65535）

2. ICE 候选完整性检查

   • 确认双方收集到 host、srflx、relay 三类候选
   • 如果缺少 relay 候选，验证 TURN 服务器配置及凭据有效性

3. 平台特定配置

   • iPad：启用 443 端口 TURN 回退，增加候选收集超时
   • Mac：检查防火墙是否放行 Tailscale 接口的 WebRTC 流量

4. 连接状态监控

   • 监听 iceConnectionState 变化：new → checking → connected/completed
   • 如果卡在 checking 状态，说明候选配对失败，需对比双方候选列表的地址类型

5. 网络隔离测试

   • 临时关闭 Tailscale，测试纯公网 WebRTC 连接是否正常
   • 如果公网正常而 Tailscale 内失败，优先排查虚拟 IP 路由和候选优先级

总结

Tailscale 与 WebRTC 的结合为私网内的实时通信提供了便利，但也引入了双 NAT 穿透的调试复杂度。核心诊断思路是分层验证：先确认 Tailscale 层的虚拟网络连通性，再分析 WebRTC 层的 ICE 候选收集与配对逻辑，最后针对 iPad/iOS 的特殊限制调整 TURN 配置和超时参数。通过系统化的候选类型检查和平台差异排查，可显著缩短此类跨平台连接问题的定位时间。

资料来源

• WebRTC ICE 候选类型与收集机制：Perplexity 技术检索结果
• Tailscale 网络架构与 DERP 中继文档：Tailscale 官方文档

systems