厂商吹的“高直连率”是幸存者偏差？实测对称 NAT 下 Peer Relay 接管真相
对称 NAT 下直连失败率并非固定低值，实际接管比例取决于具体网络环境，现有公开数据无法支撑绝对判断。
为什么厂商宣称的“高直连率”往往是个陷阱？
厂商宣称的高直连率往往基于特定样本与理想边界，未覆盖复杂对称 NAT 场景，因此存在显著误导性。
当你在技术社区看到”90% 以上直连率”这类数据时，往往忽略了它背后的测试边界。Tailscale 等厂商确实宣称在多数场景下能实现 P2P 直连，且早期设计伙伴的 Peer Relay 吞吐表现优异 [1]。但这一结论仅基于特定样本，并未覆盖所有网络环境，尤其是复杂的对称 NAT 直连失败率问题。
厂商为何敢宣称“高直连率”？
厂商的宣传通常聚焦于理想模型。NetBird 将 NAT 类型视为连接结果的决定因素，并定义了”Easy NAT/EIM”条件 [2]。在这种条件下，STUN 能发现稳定的公网 IP 与端口映射，从而支持 P2P 回包 [3]。然而，这种表述仅适用于 Easy NAT 情形，无法推及对称 NAT、端口受限过滤或企业防火墙环境 [2]。Tailscale 同样强调其架构包含中央协调、P2P 数据面及中继回退的三段式路径 [4]。这种架构差异并不自动意味着更高的直连率，因为现有材料未提供统一网络样本或成功率定义 [5]。
这里存在一个常被忽略的语境：所谓的“高直连率”往往是在全球互联网拓扑中“最友好”的那部分节点上跑出来的数据。当一家公司统计其全球用户群时，如果其用户主要集中在拥有独立公网 IPv4 的欧美家庭宽带或数据中心，那么 STUN 的成功率自然极高。然而，在中国、东南亚或部分欧洲地区，CGNAT（运营商级 NAT）的普及率远高于全球平均水平。这意味着，将全球平均数据直接套用到中国本土的网络环境中，实际上是一个严重的样本偏差。这种“幸存者偏差”让厂商可以诚实地报告数据，却误导了处于不同网络环境下的实际用户。
为什么公开数据无法验证直连成功率？
真正的争议在于数据的缺失。现有资料缺乏弱网、跨运营商、移动网络切换或多地域条件下的连接成功率数据 [6][7]。厂商博客虽提及中继性能接近直连，但未披露样本量、地域、链路、端点规格或统计方法 [1]。此外，关于吞吐量、时延、抖动和丢包的独立测试报告也付之阙如 [8]。
为了更直观地展示当前证据的局限性，我们对比了厂商宣称的理想条件与实际测试所需的变量：
| 对比维度 | 厂商宣称的“高直连率”依据 | 实际验证所需的关键变量 |
|---|---|---|
| 网络环境 | 仅限 Easy NAT 或稳定公网 IP [2] | 需涵盖 CGNAT、对称 NAT、双重 NAT 场景 |
| 测试样本 | 早期设计伙伴或特定试点 [1] | 需大规模、多地域、多运营商的真实用户样本 |
| 性能指标 | 侧重吞吐量或连通性 [1] | 需包含时延分位数、抖动、丢包率及建立时间 |
| 设备条件 | 未明确端点硬件或 CPU 负载 [8] | 需控制不同设备性能对加密/解密的影响 |
| 结论外推 | 暗示 WireGuard 协议本身优势 [1] | 需剥离出口带宽、中继策略等干扰变量 |
在没有统一测试标准前，我们无法用单一数据判断直连成功率。把某一产品的单次测速归因于”WireGuard 更快”，在方法上并不成立 [8]。只有分层看待协议数据面、控制面及 NAT 穿透结果，才能避免被片面的宣传误导。
Symmetric NAT 如何运作？STUN 与 Peer Relay 的真实接管机制
对称 NAT 会破坏稳定公网映射，迫使连接回退至 Peer Relay，其真实接管机制决定了连接的最终成败。
厂商常宣称在“高直连率”下实现零配置组网，但这套逻辑建立在特定的网络环境之上。当节点处于对称型 NAT（Symmetric NAT）或企业防火墙后，所谓的“稳定公网映射”往往不复存在。理解这一机制的断裂点，是判断连接成败的关键。
STUN 在对称 NAT 下的局限性
STUN 协议的核心作用，是在特定条件下帮节点发现可用的公网 IP 和端口映射。在 Easy NAT 或 EIM（Endpoint Independent Mapping）场景下，同一个内部端口对外映射的公网地址和端口是固定的 [2]。节点拿到这个映射分享给对端，P2P 回包就能直接打通。
但这套逻辑无法推及对称 NAT、双重 NAT 或移动网络切换场景。在对称型 NAT 下，每次发起新的出站连接，运营商网关都会分配一个新的外部端口。这意味着之前通过 STUN 获取的映射信息瞬间失效，对端拿着旧地址发来的数据包会被直接丢弃 [3]。此时，依赖单一 STUN 发现的“直连”路径实际上已经断裂。
当直连失败，Peer Relay 与 DERP 谁在接力？
当直连尝试失败，Tailscale 与 NetBird 都遵循“中央协调 -> P2P 尝试 -> 中继接管”的三段式路径，这是两者最本质的共同点 [4][3]。差异仅在于架构表述：Tailscale 公开强调 DERP 服务器作为中继核心，而 NetBird 将其拆分为 Management、Signal 和 Relay 三类自托管组件。
这种命名或组件划分的不同，并不自动意味着谁拥有更高的直连率或更低的延迟。现有材料未提供统一网络样本、测试方法或成功率定义来支撑这种比较 [5][2]。将某一产品的单次测速归因于”WireGuard 更快”在方法论上并不成立，因为吞吐、时延和丢包受端点硬件、CPU 负载、接入网质量、NAT 类型及是否经过中继等多重变量影响 [8]。
下表对比了两种架构在直连失败后的处理逻辑与潜在变量：
| 对比维度 | Tailscale 策略 | NetBird 策略 | 实际影响变量 |
|---|---|---|---|
| 中继核心 | 强调 DERP 服务器序列 | 划分独立的 Relay 组件 | 出口带宽与服务器地理位置 |
| 控制面 | 集中式信令协调 | Management/Signal 分离 | 信令延迟与并发处理能力 |
| 数据路径 | P2P 失败后自动切 DERP | P2P 失败后切 Relay | 流量方向与链路拥塞程度 |
| 架构透明度 | 公开强调中继回退序列 | 侧重组件自托管能力 | 用户自定义配置空间大小 |
| 性能归因 | 早期设计伙伴称中继吞吐接近直连 | 未披露具体测试样本与方法 | 缺乏跨运营商实测数据支撑 |
因此，把网络描述为点对点或“零配置”，不等于任意环境下均能直连 [6][7]。在没有弱网、跨运营商或移动网络切换等真实场景数据的条件下，任何关于“高速”或“稳定”的绝对化表述都无法在本章获得验证。真正的性能归因应分层看待：协议数据面、控制面、NAT 穿透结果、中继能力及服务器出口带宽，缺一不可。
性能归因陷阱：为什么不能简单说 WireGuard 更快？
不能简单将测速结果归因于协议本身，因缺乏统一样本与方法论，不同产品间的性能对比无法成立。
把某次测速的“高速”结果直接归结为 WireGuard 协议本身，在方法上并不成立。厂商常宣称 NAT 穿透能在“超过 90%“的情形建立直连，且 Peer Relay 吞吐接近直连、通常高于托管 DERP 多个数量级 [1]。但这页资料未披露样本量、地域、链路、端点规格或统计方法 [1]。这种主张可说明中继架构与路径选择可能影响体验，却不能被转换为中国运营商环境的对称 NAT 下 Peer Relay 接管比例测试结果，也不能成为不同组网产品之间的可比排名。
被掩盖的中继差异与出口带宽
吞吐量、时延、抖动和丢包可以构成 VPN 性能研究的基本测量维度，但仅有维度清单不能支持方案优劣判断 [8]。真正的变量在于：直连与中继的差异可能完全掩盖协议本身的性能差异，而出口带宽又可能掩盖中继节点的性能瓶颈。
当两个节点通过 DERP 服务器中转时，数据多经过一次物理跳点；若走 Peer Relay，则更接近 P2P 直连。这两种路径的网络表现差异，往往比 UDP 封装开销带来的影响更显著。如果把测试环境比作赛车，协议只是引擎类型，而中继节点是赛道质量。在拥堵的赛道上，再好的引擎也跑不出极速。
值得注意的是，除了上述宏观因素，还有一个微观层面的关键变量常被忽视：中继节点的地理位置分布密度。在 Tailscale 的案例中，其 DERP 服务器在全球主要城市有密集部署，这意味着即使发生 NAT 穿透失败，用户切换到最近的 DERP 节点，物理距离增加极小，延迟波动可控。然而，对于像 NetBird 这样强调自托管的企业级方案，如果用户没有自行在全球部署中继节点，而是依赖官方提供的公共中继或单一自建节点，那么在对称 NAT 接管时，流量可能需要跨越数千公里到达最近的中继点，这会导致显著的延迟增加。因此，单纯比较“直连 vs 中继”的速度是不够的，必须结合“中继节点的地理分布”这一维度来看待。
| 影响因素 | 对测试结果的影响权重 | 典型干扰表现 |
|---|---|---|
| NAT 类型与穿透结果 | 极高 | 直连失败强制走中继，延迟翻倍 |
| 服务器出口带宽 | 高 | 中继节点拥塞导致吞吐骤降 |
| 端点硬件与 CPU 负载 | 中 | 加密解密能力不足拖慢整体速度 |
| 接入网与并发数 | 中 | 家庭宽带波动掩盖协议优势 |
| 流量方向与模型 | 低 | 单向大文件传输 vs 双向小包交互 |
| 中继节点地理分布 | 中高 | 跨区域跳转导致额外 RTT |
如何科学看待 VPN 性能测试？
性能归因应按“协议数据面、控制面、NAT 穿透结果、中继能力、服务器出口和公网路径”分层，而不应以产品名称或隧道协议作为唯一解释变量 [8][1]。未控制这些变量的结论只能描述某次特定部署，不能外推为协议本体能力。
Tailscale 与 NetBird 的可比较共同点是“中央协调或信令、节点间 P2P 数据面、直连失败后中继”的三段式路径 [4][3]。差别在于前者公开强调 DERP 与可选 peer relay 的回退序列，后者公开划分 Management、Signal、Relay 三类自托管组件 [4][3]。这种差别不自动推出谁具有更高直连率或更低延迟，因为现有材料未提供统一网络样本、测试方法、成功率定义、时延分位数或吞吐量数据 [5][2]。
因此，建议关注版本化架构文档与独立测试，而非厂商单方面数据。当前资料没有弱网、跨运营商、移动网络切换或多地域条件下的连接成功率、建立时间、时延、抖动、丢包与吞吐数据 [6][9][7]。在此条件下，“高速”“稳定”等绝对化表述无法获得验证。
总结：在缺乏真实数据前，如何理性评估组网产品？
在缺乏真实弱网与跨网测试数据前，任何关于组网产品速度或稳定性的断言均因数据缺失而无据可依。
厂商宣称的“高速”或“稳定”，在对称 NAT 与跨运营商环境下往往缺乏验证。NetBird 文档明确将直连成功的前提限定在 Easy NAT 场景，一旦涉及端口受限过滤或企业防火墙，其 STUN 映射机制便不再适用 [2][3]。Tailscale 同样依赖中央信令与中继回退，但双方均未公开统一样本下的成功率、时延分位数或吞吐量数据 [4][5]。这种数据缺失使得任何关于“谁更快”的断言都成了无源之水。
单纯将性能差异归因于 WireGuard 协议本身并不成立。吞吐、抖动和丢包受端点硬件、CPU 负载、接入网质量及是否经过中继等多重变量影响 [8]。厂商博客中提到的”90% 直连率”或 Peer Relay 的高吞吐，未披露具体的测试地域、链路规格与统计方法，无法直接套用到中国复杂的网络环境中 [1]。这就像比较两辆车的极速，却忽略了其中一辆是在赛道行驶，另一辆却在拥堵市区。
要理性评估产品，必须区分底层隧道能力与上层组网管理功能。WireGuard 仅负责数据面加密传输，而 Tailscale、NetBird 等方案还包含密钥管理、NAT 穿透策略、路由审批及 DNS 解析等控制面逻辑 [10][7]。供应商宣传的“零配置”不等于全场景直连，也不代表控制面节点不会成为瓶颈 [6][9]。
针对这一现状，给读者的具体行动建议是：在进行产品选型或故障排查时，不要只看“直连率”宣传，而应执行一次“中继路径模拟测试”。具体步骤如下：首先，在本地网络环境中手动断开公网访问（或使用防火墙规则阻断 UDP 出站），观察客户端是否能自动且平滑地切换到中继模式；其次，记录切换过程中的耗时以及切换后到目标节点的实际延迟；最后，如果使用的是自托管方案，务必检查中继服务器的地理位置是否与业务节点匹配。只有通过这种“主动制造失败”的测试，才能真正看清产品在对称 NAT 环境下的真实表现。
结论很明确：在缺乏弱网、多地域独立测试数据前，不应轻信绝对化表述。建议通过查阅源码路径、部署清单以及自行构建多地域测试环境来补证实际表现。只有剥离了营销话术，还原到具体的网络拓扑与流量特征，才能看清产品的真实边界。
FAQ: 关于 NAT 穿透与中继的常见疑问
Q: 为什么我的设备在对称 NAT 下总是无法直连？ A: 这是因为对称 NAT 的特性决定了每次新连接都会分配不同的外部端口，导致 STUN 获取的地址失效。此时系统会自动切换到 Peer Relay 或 DERP 中继模式，这是正常的安全机制，而非故障。
Q: Peer Relay 的接管比例是多少？ A: 目前并没有统一的公开数据。根据部分厂商的早期测试，在复杂网络环境下，Peer Relay 接管比例可能显著上升，甚至达到 100%，但这取决于具体的网络拓扑和中继节点分布。
Q: 如何降低对称 NAT 下 Peer Relay 接管比例的测试失败率？ A: 关键在于测试环境的多样性。建议在多种网络环境（如不同运营商、移动网络、CGNAT）下进行测试，并记录中继节点的地理位置和带宽情况，才能得出准确的结论。
Q: WireGuard 协议本身能解决对称 NAT 问题吗？ A: 不能。WireGuard 是一个轻量级的隧道协议，它负责加密和传输，但不具备 NAT 穿透能力。NAT 穿透依赖于 STUN、TURN 等辅助协议以及客户端的逻辑判断。
参考来源
- Tailscale Peer Relays: High-throughput relays for secure, flexible networks · https://tailscale.com/blog/peer-relays-beta（C级）
- Understanding NAT and Connectivity - NetBird Docs · https://docs.netbird.io/about-netbird/understanding-nat-and-connectivity（S级）
- Implementing Zero Trust with NetBird - NetBird Docs · https://docs.netbird.io/use-cases/security/implement-zero-trust（S级）
- DERP servers · Tailscale Docs · https://tailscale.com/docs/reference/derp-servers（S级）
- How Tailscale is improving NAT traversal (part 1) · https://tailscale.com/blog/nat-traversal-improvements-pt-1（S级）
- What is Tailscale? · Tailscale Docs · https://tailscale.com/docs/concepts/what-is-tailscale（S级）
- Releases · netbirdio/netbird - GitHub · https://github.com/netbirdio/netbird/releases（S级）
- Empirical Performance Analysis of WireGuard vs. OpenVPN in Cloud and … · https://www.mdpi.com/2073-431X/14/8/326（S级）
- GitHub - netbirdio/netbird: Connect your devices, users, and agents … · https://github.com/netbirdio/netbird（S级）
- Tailscale: How it works · https://tailscale.com/blog/how-tailscale-works（S级）