NAT 穿透失败？P2P 连接问题排查

English version: NAT Traversal Failed? Diagnosing P2P Connection Problems

你的 P2P 远程桌面工具转半天，最后说"连接失败"。本文按通常该检查的顺序，讲清楚最常见的五种原因。

快速排查树

两台机器都在线？  ──否──► 检查两边互联网。
       │
       是
       │
信令服务器能通？  ──否──► 出站 HTTPS 被挡？试试手机热点。
       │
       是
       │
UDP 直连能跑？  ──否──► UDP 被挡。工具应回退 TURN。
       │
       是
       │
两边都对称 NAT？  ──是──► 用 TURN 中转。
       │
       否（至少一边正常）
       │
按理能跑。拉日志。

原因 1：有一边其实不在线

最简单的。远端机器睡眠了、Wi-Fi 掉了、无人值守服务崩了。

诊断： 从一个已知正常的网络能 ping 通远端机器吗？无人值守工具控制台显示"在线"吗？

修复：

• 唤醒机器（手动或 Wake on LAN）。
• 重启远程桌面服务。
• 检查机器的睡眠 / 休眠设置，允许远程唤醒。

原因 2：信令服务器不通

两端连握手都开始不了，因为找不到约会点。

诊断： 看工具的连接日志。如果一直停在"正在连接信令服务器"，就是这条。

修复：

• 检查出站 HTTPS（443）是否放行。用手机热点试一下排除企业网络。
• 如果公司屏蔽厂商信令域名，申请例外。
• 可自托管的工具让你把信令跑在自己网络里。

原因 3：UDP 被挡

P2P 要 UDP。某些网络（极严格企业防火墙、捕获门户、个别蜂窝 APN）会丢 UDP 或限速。

诊断： 日志显示握手完成但没有媒体帧流动。或两端都"在线"但会话超时。

修复：

• 工具应自动回退到 TCP/TLS 上的 TURN。不回退就是工具问题。
• 用 5G 热点测。能跑就是你的网络在挡 UDP。
• 跟 IT 协调放行出站 UDP 到 STUN/TURN 端口。

原因 4：两边都是对称 NAT

最难穿透的 NAT 类型。蜂窝运营商爱用，部分企业防火墙也用。

诊断： 跑一次 STUN 测试（网页版或 Chrome 的 webrtc-internals）。每次查询返回的公网端口不一样，就是对称 NAT。

修复：

• 用工具的 TURN 回退。会话能跑，只是延迟高一点。
• 你能控制网络的话：把路由器换成"全锥型"NAT。
• 蜂窝场景：换运营商或回 Wi-Fi。

原因 5：出站代理破坏连接

会"检查"TLS 流量的企业代理会破坏 WebRTC 的 DTLS 握手。工具建立不了加密通道。

诊断： 家里 / 热点能跑，办公室跑不了。其它 WebRTC 工具（Google Meet、Whereby）也跑不了。

修复：

• 把远程桌面工具的域名加进代理 bypass 名单。
• 启用 SSL 检查的代理：装一个 TCP 上的 TURN bypass。
• 跟 IT 确认 DTLS / SCTP 流量没被改。

给支持团队发什么

按上面排查完仍然搞不定，把这些发给工具的支持团队：

1. 会话 ID（在错误信息或日志里）
2. UTC 时间戳
3. 两端各跑一次 STUN 测试的结果（显示 NAT 类型）
4. 是否能在手机热点上复现
5. 两端到信令域名的 traceroute 输出

剩下 95% 的 case 不用来回拉扯就能定位。

什么时候放弃直连

有些网络（严格锁定的企业、部分政府、个别有偏执捕获门户的酒店）就是不允许 P2P。别较劲 —— 用 TURN，接受多出来的延迟，继续干活。120ms 的稳定会话好过没有会话。

接下来读什么

• 背景：《P2P 与中转架构远程桌面的技术深度对比》
• 这套技术为什么存在：《不用端口转发也能跨 NAT / 防火墙远程》
• 避免大部分问题的初始配置：《给团队搭建远程桌面访问》