先别怪 VPN，用 iperf3 测一测路径

两个站点之间的文件复制感觉像网络测试，但每一次都是混合结果：协议开销、两端的存储、端点处理和路径。仅凭这个数字就责怪 VPN 属于猜测。在同一对端点之间跑一段短促且受控的流，能得到第二个观测值，而正是对比才看得出哪一部分值得关注。下面的做法不会编造结果。

文件复制是工作负载，不是测量

带宽只是路径的一项属性，而文件复制同时测量了好几项。大量小文件对逐文件操作的压迫远大于单个大流。任一侧存储慢，无论隧道如何都会给复制封顶。加密和分帧会增加开销，而计算校验和或扫描病毒的文件服务器同样会增加开销。只有把端点和方向固定住的对比，才能把这些贡献分开。

公共测速测的是到附近测试服务器的路径，那不是通往你私有文件服务器的路径。它们回答的是另一个问题。

每个方向各跑一次单次流

当两端都由你管理时，在获批的时间窗口内安排一次简短的 iperf3 运行。尽量把文件服务器作为远端端点；若改用替身主机，要记录下来。

iperf3 -s -1 -B 10.77.0.20

服务器绑定到一个私有地址，并在退出前只接受一个客户端。一次性监听器在没有客户端到来时不会自行过期，所以要在获批窗口关闭时把它停掉。

iperf3 -c 10.77.0.20 -t 10

默认情况下客户端通过 TCP 5201 发往服务器，十秒的窗口让测试保持简短。在防火墙里把监听器限制为预期的私有源和目的地址，而不是把它暴露在公网。

iperf3 -c 10.77.0.20 -t 10 -R

反向参数让服务器成为发送方，这很重要，因为上行和下行路径常常不同。绑定地址并不能证明客户端选择了预期的路由，所以要记录实际测试的路径。把 VPN 状态、方向、时长和端点负载连同结果一起留下，然后移除临时访问。

拿同类跟同类比

在类似条件下重跑一次有代表性的文件操作，服务端点相同，中间不夹带无关的配置变更。记录它是上传还是下载、一个大文件还是许多小文件、任一侧的存储是否繁忙。短时突发不是整个复制的持续速率，两种观测也不该悄悄互换身份。如果流和复制在同一方向上都很慢，就去看它们共用的路径和端点限制。

当流是健康的而复制不是，差值就是工作负载额外加上的那部分，下一次排查就该落在那里。

下结论前先看清单位

每秒兆比特和每秒兆字节相差八倍，支持论坛却常把它们当成同一个单位来比。偏低的 iperf3 结果也可能来自测试主机本身：CPU 饱和、接口较慢或磁盘繁忙，都可能先于网络把进程卡住。所以单个数字并不是判决，既不能据此断定 ISP 有问题，也不能据此断定协议有问题。基线之所以有用，是因为它来自观测而非假设，并把问题收窄到一个方向和一个端点。

把两次观测的端点、方向、时长和速率都写下来。这四项让对比站得住脚，代价也远低于凭感觉更换软件。