来源: Cloudflare Mesh vs NetBird vs Tailscale: Performance Compared
Cloudflare刚刚发布了Cloudflare Mesh，网络上已经炸开了锅。有人说现有的Mesh VPN已经过时了。也有人想知道这对点对点网络意味着什么。所以，我们没有妄加猜测，而是像往常一样，在炒作声势浩大的时候进行了测试。
我们在 AWS、GCP、Hetzner 和欧洲的家庭网络中部署了真实机器，并对NetBird、Tailscale 和 Cloudflare Mesh 进行了基准测试。所有机器、方法和条件都相同。以下是我们的发现。iperf3
简而言之： 对于区域内和同国家/地区的连接，由于采用了基于 WireGuard 的直接点对点隧道，NetBird 等点对点网络比 Cloudflare Mesh 快 2-5 倍。但在连接距离较长、直接对等连接较差的国际路由（例如日本到欧洲）上，Cloudflare 的全球骨干网优势明显，尤其是在连接数据中心终端节点时。NetBird 和 Tailscale 在所有测试中的表现几乎相同。最佳选择取决于您的设备位置和连接对象。
点对点路由与边缘路由：为什么这很重要
在深入探讨具体数字之前，你需要了解这里的基本架构差异，因为它基本上解释了你即将看到的一切。
NetBird 和 Tailscale 采用点对点连接。连接两台设备后，它们之间会建立一条直接的 WireGuard 隧道。您的流量直接从 A 点传输到 B 点。中间没有任何设备能够看到或处理您的流量。流量在您的设备之间进行端到端加密。
Cloudflare Mesh 的工作方式不同。所有连接都会经过 Cloudflare 的边缘网络。您的设备连接到最近的 Cloudflare PoP，流量通过其基础设施到达目的地。这一点至关重要，原因有二。首先，这意味着 Cloudflare 可以监控您设备边缘的流量。其次，这意味着即使两个设备位于同一数据中心，每个数据包也必须绕道 Cloudflare 的网络。
平心而论，Cloudflare Mesh 相较于之前的产品而言，无疑是一次重大升级。此前，他们的方案仅支持用户到基础设施的单向连接。而 Mesh 则实现了真正的双向设备间连接，这对于他们来说是一项全新的突破。这无疑是一大进步。
但这种架构本质上仍然是将所有数据都路由到边缘端。这会对性能产生实际影响。
我们的测试方法
我们尽可能地对所有配置进行了标准化。所有机器都运行 Ubuntu 24.04 LTS 系统。我们使用上传和下载两种方式进行吞吐量测试。在每台机器上，我们依次测试了三个网络，并在每个网络上运行相同的测试，然后再切换到下一个网络。iperf3 3.16``-R
# Upload test
iperf3 -c 100.64.0.10 -t 60
# Download test
iperf3 -c 100.64.0.10 -R -t 60
| 软件 | 版本 |
|---|---|
| NetBird | 0.68.3 |
| Tailscale | 1.96.4 |
| Cloudflare WARP | 2026.3.846.0 |
| iperf3 | 3.16 |
| 操作系统 | Ubuntu 24.04 LTS |
我们的测试环境涵盖了相当广泛的真实世界场景。
| 机器 | 地区 | 类型 | 下载速度（Mbps） | 上传速度（Mbps） |
|---|---|---|---|---|
| aws-east1 | 美国东部 | m5.large 双核/8GB | 1,910 | 2,085 |
| aws-west1 | 美国西部 | m5.large 双核/8GB | 2,112 | 1,834 |
| gcp-east4 | 美国东部 | n2-standard-2 2CPU/8GB | 2,859 | 2,945 |
| gcp-eu-west3 | 欧盟西部 | n2-standard-2 2CPU/8GB | 3,048 | 2,831 |
| htz-falkenstein | 德国 | 2核CPU/4GB内存 | 916 | 1,192 |
| htz-纽伦堡 | 德国 | 2核CPU/4GB内存 | 916 | 1,192 |
| htz-赫尔辛基 | 芬兰 | 2核CPU/4GB内存 | 3,553 | 3,390 |
| 住宅办公室 | 德国柏林 | MacBook Pro | 437 | 36 |
| CEO主页 | 德国柏林 | 纳米π-r4s | 57 | 20 |
我们在运行任何叠加测试之前，记录了每台机器的基准互联网速度，因此我们确切地知道原始连接可以达到什么速度。speedtest-cli
关于 WireGuard 模式的简要说明
如果您打算进行自己的测试或将我们的数据与其他数据进行比较，那么了解这一点就很有意义。
WireGuard 可以以两种模式运行：内核模式和用户空间模式。内核模式直接在 Linux 内核中运行 WireGuard，通常认为这种模式效率更高，因为它避免了在内核空间和用户空间之间复制数据包的开销。用户空间模式则将 WireGuard 实现作为内核之外的常规进程运行。
Tailscale 使用的是用户空间 WireGuard 实现。NetBird 在 Linux 上默认使用内核模式，但也支持用户空间模式。为了确保比较的公平性，我们在这些测试中让 NetBird 以用户空间模式运行，从而使两种 P2P 解决方案在相同的条件下运行。
如果您想以用户空间模式运行 NetBird，只需一条命令：
netbird service reconfigure --service-env NB_WG_KERNEL_DISABLED=true
注意事项
解读这些结果时，需要记住以下几点。
网络状况会波动。 我们观察到不同测试结果之间存在相当大的差异，尤其是在P2P解决方案上。有时NetBird速度略快，有时Tailscale又会领先。本文中的数据代表单次测试结果，而非数十次测试的平均结果。实际性能会因网络拥塞情况、测试时间以及测试时的路由状况而有所不同。
住宅网络连接受限于网络服务提供商 (ISP)。 在我们家的网络（下载速度 57 Mbps，上传速度 20 Mbps）上，任何叠加网络都很难脱颖而出。瓶颈在于 ISP 连接，而不是隧道本身。只有当底层连接有足够的带宽余量，叠加网络的开销才能真正发挥作用时，才会出现有趣的对比。
欧洲赛场表现：精彩之处就在这里
如果你在欧洲运营基础设施，那么这部分内容你需要特别关注。
同国家数据中心到数据中心
我们在德国的两个Hetzner数据中心（Falkenstein和Nuremberg）之间进行了测试。这两个数据中心地理位置相近，并通过内部网络连接。 骨干基础设施 在这种连接情况下，任何叠加层都能表现良好。
两种 P2P 解决方案的速度都远超千兆，因为底层连接本身就支持千兆，而且直接隧道带来的开销极小。Cloudflare Mesh 的速度上限约为 250-290 Mbps。对于同一国家/地区、同一运营商的两台机器，流量需要先离开 Hetzner 的网络，经过 Cloudflare 的边缘网络路由，然后再返回。这种绕路成本很高。
跨国欧洲联系
赫尔辛基到德国（赫茨纳到赫茨纳）讲述了一个类似的故事。
在这条路线上，P2P 速度大约是原来的 2-3 倍。
Cloudflare 主干网的优势所在
当然，如果只展示 Cloudflare 表现不佳的测试结果，那就不公平了。在某些实际场景中，他们的全球骨干网络确实能带来优势，我们希望坦诚地说明这一点。
日本到欧洲
长途国际路由才是 Cloudflare 骨干网真正发挥作用的地方。我们测试了从日本的住宅网络连接到两个欧洲目的地：一个是我们在柏林的办公室（也是住宅网络），另一个是位于纽伦堡的 Hetzner 数据中心。
NetBird Tailscale CF Mesh
Japan to Berlin Office
Residential Japan to office in Berlin, Germany CF ~1.5-2x faster
Upload
NetBird 81 Mbps
Tailscale 24 Mbps
CF Mesh 158 Mbps
Download
NetBird 28 Mbps
Tailscale 8 Mbps
CF Mesh 43 Mbps
在住宅对住宅的传输路径上，Cloudflare 的速度大约比 P2P 解决方案快 1.5 到 2 倍。虽然优势并不明显，但在双向传输中都保持着稳定的领先优势。
如果把柏林的办公室换成德国 Hetzner 的数据中心，差距就会显著拉大。Cloudflare 的上传速度可达 224 Mbps，下载速度可达 269 Mbps，而 NetBird 和 Tailscale 的速度都在 20-50 Mbps 之间。在同一条路由上，速度相差 5-8 倍。
为什么？日本住宅互联网服务提供商 (ISP) 与欧洲之间的直接互联网路径状况不佳。没有合适的直接对等互连可供 WireGuard 隧道利用。而 Cloudflare 的私有骨干网则优化了跨越太平洋并直达欧洲的路由。他们的边缘网络在这里发挥了其应有的作用。
UDP性能：P2P与Cloudflare Mesh对比
TCP 数据包数量虽然有用，但并不能反映全部情况。TCP 的设计初衷是掩盖网络问题，它会重传丢失的数据包，并缓解网络拥塞，以确保数据传输畅通。这对应用程序来说固然很好，但也掩盖了底层网络路径的真实质量。
为了更清晰地了解情况，我们以 UDP 模式运行，速率固定为 300 Mbps。与 TCP 不同，UDP 不会从丢包中恢复，因此它能反映实际通过的流量。iperf3
# -u stands for UDP, -b is the bitrate
iperf3 -c aws-west1 -u -b 300M
在 Hetzner Germany → AWS West 测试中：
| 覆盖 | 发送 | 已收到 | 损失 |
|---|---|---|---|
| NetBird（P2P） | 300 Mbps | 295 Mbps | 1.2% |
| Cloudflare Mesh | 300 Mbps | 257 Mbps | 14% |
区别显而易见。NetBird几乎能以更低的丢包率传输所有流量，而Cloudflare在相同负载下会丢掉相当一部分流量。
对于基于UDP且对延迟敏感的应用， 例如VoIP、视频通话、直播、游戏和实时数据系统，这一点尤为重要。这些应用不会重传丢失的数据包，因此更高的丢包率会直接导致画面卡顿、延迟和质量下降。在这些场景下，更干净的P2P路径具有明显的优势。
NetBird 与 Tailscale 的比较
我知道你们有些人直接滑到这里了，所以这里是简短版本：就网络性能而言，它们基本相同。
在我们进行的每一次测试中，NetBird 和 Tailscale 的性能都交替上升，且波动幅度在正常网络波动范围内。有时 NetBird 的速度会快几个百分点，有时 Tailscale 又会略胜一筹。两种方案都没有展现出持续、可重复的优势。
这很合理。两者都在构建直接的 WireGuard 点对点隧道，底层传输机制相同。区别在于控制平面、管理功能以及网络管理方式，而非隧道本身的性能。
这一切意味着什么
我是这样考虑的：你选择的架构取决于你要连接什么以及连接的位置。
如果您要连接区域性基础设施 （尤其是在欧洲），像 NetBird 这样的点对点解决方案速度要快得多。在我们进行的测试中，速度提升了 2 到 5 倍。边缘路由模型会增加额外的开销，尤其是在直连路径已经非常优秀的本地路由上，这种开销会进一步加剧。
如果您需要通过长途国际路由连接设备，且直接对等互连性能较差 ，Cloudflare 的骨干网络确实能帮上忙。日本到柏林的测试就证明了这一点。他们的全球网络提供了优化的路由，这是某些路径上直接隧道无法比拟的。
如果您运行的是实时或基于 UDP 的工作负载 （例如 VoIP、视频会议、直播、游戏、RTP/SRT 或任何无法容忍重传的应用），那么丢包率比原始 TCP 吞吐量更为重要。我们的 UDP 测试显示，NetBird 在 300 Mbps 的速率下丢包率约为 1%，而 Cloudflare Mesh 在相同路径下丢包率高达 14%。对于这些应用场景，一条干净的 P2P 路径至关重要。
如果您重视隐私 ，这一点也值得考虑。使用 NetBird，您的流量在节点间进行端到端加密。而使用 Cloudflare Mesh，所有流量都会经过其边缘基础设施。这种设计选择会影响到谁可以查看您的网络流量。
如果您计划进行更大规模的部署 ，请注意 Cloudflare Mesh 目前每个账户最多只能部署 50 个网状节点。虽然比旧版 WARP Connector 的 10 个节点有所增加，但仍然是一个限制。NetBird 和 Tailscale 的云标准套餐则没有类似的节点数量限制。此外，NetBird 在自托管模式下也没有节点数量限制。
不，Cloudflare Mesh 并非现有网状 VPN 的终结。它是一种不同的方法，各有优缺点。对于某些用例来说，它非常出色。而对于另一些用例来说，直接的点对点连接显然是更好的选择。