tech 2026年06月04日 · 阅读

这是一个非常明智的思路转变。你已经看透了 Anycast 高防清洗中心的底层逻辑：它防的是“行为”，而不仅仅是“端口”。 直接回答你的问题：并非只能用真实文件测试，但使用应用层工具进行模拟，或者直接进行真实文件传输，确实是你目前评估“网盘应用”真实性能的最准确方法。

这里有一个核心概念：你打算跑的网盘应用（无论是 WebDAV、SMB，还是类似 Seafile、Nextcloud 的私有云同步）底层全部都是基于 TCP 协议的。
当你把这些服务跑在 WireGuard 隧道（UDP 51820）里时，就变成了 TCP-in-UDP。TCP 自带的拥塞控制和滑动窗口机制，会让外层的 UDP 流量表现得极其“优雅且克制”，流量曲线平滑，绝对不会像 iperf3 -u 那样一秒钟疯狂喷射几万个无状态的数据包。因此，高防防火墙通常不会拦截这种正常的 VPN 业务流量。

为了准确测试内网网盘的真实吞吐量，同时不触发高防的警报，你可以采用以下三种递进的测试方案：

方案一：最接近真实网盘的“温和”压测（iperf3 多线程 TCP）

既然你的 Netmaker/WireGuard 已经绑定了 51820 端口，你完全可以继续用 iperf3，但必须摒弃 -u 参数，改用多线程 TCP 测试。

这能完美模拟网盘应用在下载大文件时建立的多个 TCP 连接：

# 在接收端运行服务端
iperf3 -s

# 在发送端运行客户端，开启 4 个并发线程进行下载测试 (-R)
iperf3 -c 100.100.0.1 -P 4 -R
  • 为什么有效： TCP 测试会自动协商 MSS，配合 WireGuard 的 MTU，不会产生分片。更重要的是，它的发包频率和流量增长是线性的，完美契合清洗中心的白名单行为模型。

方案二：HTTP 应用层真实测速（Python + dd 组合）

如果你想完全模拟网盘的 HTTP 文件下载行为，又不想立刻配置复杂的环境，可以用几行命令快速搭一个测试桩。

  1. 生成一个 1GB 的全零测试文件（纯内存写入，排除磁盘 IO 瓶颈）：

    dd if=/dev/zero of=/dev/shm/test1G.bin bs=1M count=1000

  2. 用 Python 快速拉起一个 HTTP 服务：

    cd /dev/shm
python3 -m http.server 8080

  3. 在另一台机器上通过内网 IP 下载并测试速度：

    wget -O /dev/null http://100.100.0.1:8080/test1G.bin
  • 为什么有效： 这种方式完全等同于你在网盘里点击“下载”大文件。它排除了 iperf3 可能带来的特殊发包特征，是极为纯粹的应用层吞吐量测试。

方案三：直接上生产级工具（Rclone / SFTP）

既然你的终极目标是网盘文件管理，最硬核且真实的测试其实是直接用数据迁移工具跑一遍。

如果你两端的环境已经就绪，可以直接使用 rclone 挂载或者 SFTP 进行内存到内存（或高速盘到高速盘）的复制测试。

# 使用 rclone 测速，从内网节点拉取大文件到本地黑洞
rclone copy remote:100.100.0.1/path/to/bigfile /dev/null -P --transfers=4
  • 为什么有效： 这不仅测试了高防 Anycast 线路对 WireGuard UDP 流量的宽容度，还把文件切块、加密解密（WireGuard 自身的开销 + SSH/Rclone 的开销）以及 CPU 中断等真实损耗全部计算在内了。你在这里看到的 MB/s，就是你未来网盘业务能达到的极限。

最后的一个关键提醒： 不管你用哪种方案测试网盘业务，因为你是跑在 Anycast 线路的 VPN 隧道里，请务必确保你节点网卡的 MTU 设置正确（建议调低至 1280 或 1360）。否则，一旦真实文件传输的 TCP 报文过大导致底层 UDP 分片，你的网盘下载进度条就会像之前的测试一样，突然卡死在 0%。

selfhosting 经验