WebRTC 穿墙术：iPad 白屏真相
值得看指数 44.0 NO. 015 · 2026.06.11
发布2026/06/10Score50Comments24
为什么值得看
p2claw 作者排查 iPad 白屏问题，最终定位到 webrtc-rs 硬编码常量与 Tailscale 设计决策的叠加 bug。这类 P2P 网络在异构设备+VPN 环境下的边缘 case，正是生产环境最难复现的陷阱。
媒体预览
编辑判断
这个案例的价值不在 bug 本身，而在排查路径：同一 WiFi、同浏览器引擎、却设备表现不同——这种"看似不可能"的差异往往指向网络层而非应用层。webrtc-rs 把 STUN 超时硬编码为 5 秒，而 Tailscale 的 MTU 处理让特定路径的 ICE 协商刚好踩线失败，这种跨库耦合问题单测永远覆盖不到。
做实时音视频或 P2P 产品的团队应该警惕：你的测试矩阵里有没有"公司设备+个人 VPN+不同操作系统"的组合？这往往是用户真实环境，却是开发环境最难复现的。建议把 Tailscale/WireGuard 加入 CI 的兼容性测试，而不是只在干净网络里跑通就上线。
社区反馈
意见分歧 24 条评论
核心争论：P2P网络硬编码MTU与VPN包过滤的叠加缺陷是否属于罕见边缘案例还是设计债务
Author here. This started as a blank page on one device and ended two weeks later at the intersection of two bugs: webrtc-rs hardcodes INITIAL_MTU=1228 [never updated, no path probing, retransmits at the same size forever], and Tailscale's packet filter classifies any IPv6 packet with a Fragment hea
just wait till you try to send a data packet in webrtc that's too large in the browser. https://stackoverflow.com/questions/35381237/webrtc-data-cha... last I checked, all browsers silently fail if it's too big.
Yes! that's the "other reconstruct" I mention on the post. maxMessageSize at least appears in SDP and getStats. We ended up patching both at our client to be safe [800 bytes and 16kb respectively].