iPad 上的 Tailscale：一次 WebRTC 调试故事

背景

在 P2P 通信应用 p2claw 的开发与维护过程中，作者遇到了一个极其棘手且难以复现的 Bug。当作者在 iPad 上打开 p2claw 应用时，页面呈现空白状态；然而，相同的 URL 在 Mac、Linux 机器以及手机上均能正常工作。这些设备处于同一 Wi-Fi 网络下，使用相同的浏览器引擎（WebKit），网络连接环境也完全一致。

这是一个典型的“海森堡 Bug”（Heisenbug）：如果疯狂刷新页面，页面有时又能正常加载。这种不确定性使得传统的调试手段失效。经过两周的排查，作者发现这并非单一原因导致，而是两个 Bug 共同作用的结果：一个是 webrtc-rs（Rust 实现的 WebRTC 栈）中的硬编码常量问题，另一个是 Tailscale（一种 VPN 服务）中的一项单行设计决策。尽管当天就提供了变通方案，但彻底理解并修复这两个 Bug 的核心原因花费了额外的两周时间。

核心内容

1. 故障现象与初步排查

应用加载了足够的 HTML 以显示加载状态，随后挂起。控制台没有相关错误，Service Worker 注册成功，WebRTC 握手完成，数据通道（Data Channel）状态显示为 open，但浏览器通过数据通道发送第一个 GET / 请求后，永远等待不到响应。

另一端的“Box Agent”（服务器端代理）认为一切正常，它已经发送了响应并将字节推送到通道，但这些数据从未到达 iPad。

为了定位问题，作者采取了以下关键步骤：

• 日志对齐：记录连接两端的日志，并按时钟时间对齐。这展示了 Box 发送的每个数据块、浏览器接收的每个数据块，以及 Box 出站缓冲区中等待确认送达的数据量。
• 排除法：
  • 消息大小限制：WebRTC 在交换数据前会协商最大消息块大小。iPad 报告的 maxMessageSize 为 64kb，远高于实际发送的 7-8kb 数据块，因此排除此因素。
  • Wi-Fi 稳定性：使用 ifstat 和 tcpdump 检查，Box 端数据正常，且同一网络下的手机未出现相同问题，排除无线信号丢失。

2. 数据流的异常模式

仪器数据显示，Box 发送了三个数据块：220 字节的头部、7,874 字节的内容体和 199 字节的尾部。Box 的出站缓冲区增长到约 8kb 后停止，因为它“发送”了内容体但从未收到到达确认。

在 iPad 的浏览器控制台中，只收到了一个数据块（220 字节的头部），随后没有任何数据。由于 WebRTC 数据通道在不可靠的 UDP 之上保证有序交付，缺失一个数据块会阻塞后续消息。

3. 错误的假设：WebKit 与 Tailscale 的混淆

作者最初怀疑是 WebKit（iOS Safari 的内核）的问题，因为所有 iOS 浏览器都基于 WebKit。理论是：Tailscale 作为 VPN 会封装流量，减少每个数据包的有效载荷空间，导致大响应被切分成更多更小的片段。WebKit 在用户空间实现数据通道并负责重组，作者假设 WebKit 在重组大消息时存在 Bug。

为了验证，作者将 Box 的消息限制在 800 字节以内，确保每个消息仅占用一个数据包。结果 iPad 立即加载成功，无论是否启用 Tailscale。这看似证明了“数据包重组”理论，但实际上是一个误导。

4. 僵局与转折点

在接下来的两周里，作者试图通过 JavaScript 发送器和基于 webrtc-rs 的 Rust 发送器复现该 Bug，但均告失败。无论是 Linux 还是 iPad，无论是否启用 Tailscale，数据都能完整送达。

直到作者重新审视原始调试会话的 JSONL 日志（借助 Anthropic 发布的 Fable 工具挖掘），才发现了决定性证据。

5. 真相：getStats() 计数器与 MTU 冲突

通过 WebRTC 自带的 getStats() 计数器，作者发现 iPad 的候选对（candidate pair）接收字节数冻结在 2,144 字节（跨越 18 个数据包），而数据通道仅传递了一条消息（266 字节，即头部加帧信息）。Box 一直在重传那个大包。

如果 Safari 收到了数据包但未能重组，传输计数器应随每次重传增加一千多字节，但它纹丝不动。这意味着数据包根本没有到达 iPad。

根本原因找到了：

• webrtc-rs 的硬编码 MTU：Box 使用的 webrtc-rs 栈将出站数据通道消息切割为基于 INITIAL_MTU 的数据包，该值硬编码为 1228 字节，且不可配置。
• 网络开销叠加：1228 字节的载荷加上加密层（1,265 字节），再加上 UDP 和 IPv4 头部（28 字节），总包大小为 1,293 字节（IPv6 为 1,313 字节）。
• Tailscale 的限制：Tailscale 隧道最大承载 1,280 字节。

6. 为什么之前没发现？

数据包过大本身并非致命错误。当内核将大包路由到隧道时，IP 层会执行分片（Fragmentation），发送两个小于限制的部分，并在另一端重组。在健康的网络路径上，分片能正常重组，Bug 不可见，这也是为什么作者之前的独立复现测试一直通过的原因。

真正的故障点在于：分片在哪里丢失了？ 在 iPad 上，分片未能成功重组或送达，导致数据通道永久挂起。

关键要点

• 海森堡 Bug 的迷惑性：偶尔能复现的 Bug（如刷新后加载成功）往往掩盖了根本原因，导致调试方向偏离。
• 上下文膨胀（Context Bloat）的风险：在 AI 辅助调试时代，开发者容易陷入“确认偏误”。作者因 iPad 和 Mac 的差异仅在于 Tailscale，却固执地将其解释为 WebKit 的重组问题，而忽略了 Tailscale 本身的网络层影响。
• WebRTC 的 MTU 陷阱：webrtc-rs 等库中硬编码的 MTU 值（1228 字节）加上加密和协议头部，极易超过隧道网络（如 Tailscale 的 1280 字节限制）的承载能力。
• IP 分片的隐蔽性：IP 层分片通常能正常工作，但在特定网络环境或接收端实现中，分片丢失可能导致看似“连接正常但数据不通”的现象。
• 数据驱动调试：最终破局的关键在于深入分析 getStats() 的底层计数器，而非仅依赖应用层日志或表面现象。

意义与影响

• 对 WebRTC 开发者的警示：在使用 Rust 等语言实现 WebRTC 栈时，需特别注意 MTU 配置与网络隧道（如 VPN、WARP、Tailscale）的兼容性。硬编码的 MTU 值在生产环境中可能引发严重的连通性问题。
• 调试方法论的反思：本文展示了如何从“猜测”转向“证据”。通过精确的时间对齐日志和底层统计计数器，可以穿透表象，定位到网络层和传输层的细微差异。
• Tailscale 用户的参考：对于使用 Tailscale 进行 P2P 通信的用户，若遇到 WebRTC 连接挂起或数据丢失，应检查应用层的 MTU 设置是否适配隧道限制，或考虑调整数据包大小以避免 IP 分片。
• AI 辅助调试的局限性：尽管 AI 工具（如 Claude、Fable）能帮助整理日志和计算参数，但人类开发者仍需保持批判性思维，避免被错误的假设（如“一定是浏览器 Bug”）所束缚，应不断质疑现有理论并回归原始数据。