Linux FTP 测网速慢的原因分析：磁盘、网卡、限速与链路排查

很多用户在 Linux 上用 FTP 下载或上传文件来测网速，但结果常常和预期不一致：有时速度忽高忽低，有时明显低于带宽上限，甚至本地测速正常、FTP 却很慢。问题通常不只在“网络”，还可能来自磁盘、CPU、协议和服务器策略。

先判断：你测到的是网络，还是 FTP 传输性能

FTP 速度包含网络、磁盘、CPU、会话控制和服务端策略等多个环节。如果你用单个大文件测试，看到的可能是磁盘读写瓶颈，而不是纯带宽。

判断方法是先做对照测试：再用在线测速或 iperf3 看基础带宽，然后对比 FTP 上传和下载的结果。如果两者都低，通常是网络或服务器侧问题；如果只有单方向慢，多半是磁盘、权限或服务端策略导致。

Linux 客户端在下载时需要持续写盘，上传时需要持续读盘。机械硬盘、忙碌的 SSD、RAID 同步或文件系统压力，都会让 FTP 速度看起来偏低。

判断方法是传输时观察 iostat、top 或 vmstat。如果磁盘等待时间高、CPU 却不高，而 FTP 速度上不去，通常是存储瓶颈，而不是网络带宽不足。

如果网卡只协商到 100M、半双工，或者驱动和固件不稳定，FTP 速率会明显低于预期。Linux 上这类问题常见于老旧网卡、USB 网卡和虚拟机环境。

判断方法是检查链路速率、双工模式和错误计数。若链路状态不稳定、丢包或重传持续增加，就应先修复网卡协商和驱动问题，再继续测网速。

FTP 需要建立控制连接和数据连接，还会受被动/主动模式、字符集和服务端实现影响。单线程 FTP 测速往往低估真实带宽，尤其在高延迟网络中更明显。

判断方法是和多线程下载工具或 iperf3 进行对照。如果 FTP 明显低于其他工具，而其他测试已经接近带宽上限，问题更可能在协议效率，而不是网络本身。

很多 FTP 服务会配置每用户限速、匿名用户限速、连接数上限，或者启用安全模块带来额外开销。客户端看起来在测网速，实际上是被服务器策略限制。

判断方法是查看 FTP 服务配置、日志和会话状态，确认是否存在限速、带宽整形、并发上限或防火墙策略。如果服务端忙碌，客户端速度通常会稳定卡在某个上限附近。

当链路存在丢包、抖动或 MTU 不一致时，FTP 的长连接吞吐会明显下降，尤其在跨网段、VPN、PPPoE 或云主机场景中更常见。

判断方法是先用 ping 观察丢包和时延波动，再用 mtr 或 traceroute 排查路径；如果重传明显增多，优先处理链路质量，而不是继续调整 FTP 参数。

如果目标是测网络能力，建议把“文件传输速度”和“纯带宽测试”分开看。iperf3 更适合测吞吐，FTP 更适合验证实际业务传输体验。

如果必须用 FTP 测速，建议选择大文件、关闭不必要的后台任务，并让客户端和服务器都使用性能更稳定的 SSD。测试前先确认网卡协商、磁盘余量和服务器限速，可以减少误判。