两台Linux服务器之间测速慢，先别急着把锅甩给带宽，最靠谱的解法是放弃scp、用iperf3做双向打流测试，再沿着“网络链路→系统参数→防火墙规则→IDC线路质量”逐层排查，多数情况下，瓶颈出在默认配置或测试姿势上，而不是真正的专线带宽不够。
测速慢？先分辨是“快不起来”还是“真慢了”
很多朋友习惯用scp或rsync传个大文件来估算网速，这个方法的思路没错，但结果极易失真：本地磁盘读写速度、文件系统缓存、CPU校验都会拖累测速值，比如一台机械盘服务器往另一台NVMe服务器传文件，瓶颈十有八九在磁盘，而不是网卡。另一些人爱用ping看快慢,这更是大误区，ping反映的是延迟和丢包率，和带宽一毛钱关系没有，延迟低只能说明链路短，不代表数据管道宽。
所以测速前要先把“环境打扫干净”：停掉业务服务、关掉监控采集、用virsh或docker暂停空闲容器，确保两台机器上只有测速流量在跑，上文归纳才有参考价值。
一步到位：用iperf3做双向打流测试
iperf3是公认的网络性能基准工具，默认TCP模式，能直接看吞吐、重传率和CPU占用，先在两台服务器上装好：yum install iperf3 -y，Ubuntu系用apt install iperf3。
服务端和客户端怎么启动
目标机跑：iperf3 -s -p 5201
发起机跑：
iperf3 -c 目标IP -p 5201 -t 60 -P 4
参数-P 4表示开4条并发流，能更好压满多核CPU，想测反向流量（下行），加一个-R参数：
iperf3 -c 目标IP -p 5201 -t 60 -P 4 -R
读懂输出里的“暗号”
重点看四列：Interval（时间窗）、Transfer（传输量）、Bandwidth（实时带宽）、Retr（重传次数），如果Retr反复出现数字，说明网络层在丢包，TCP一重传，吞吐立马掉一半，再看CPU占用百分比，如果服务端CPU已经跑满，根子可能在协议栈或网卡驱动，而不是网络链路本身。双向测试都要做一遍,单向快、反向慢是非常典型的信号，多半是接收端的窗口设置或网卡多队列配置有问题。
网络链路层排查：从ping到mtr
说完应用层工具，回到网络层做体检。
ping -c 100 目标IP，看平均延迟和丢包率，连续100个包，一个不掉、rtt波动小，说明物理链路健康，如果稳定丢包1%以上，后面的一切高带宽都无从谈起。
mtr看路径上的每一跳
mtr -n -c 50 目标IP，这个命令会显示从本机到目标机经过的每个路由节点，哪个hop的Loss不为0、或延迟同比暴涨，问题大概率就出在这台路由器对应的运营商区域，别被中间某几跳的高延迟吓到，只要最后一跳的丢包率是0，TCP速度依然能跑满。
MTU必定要查
双方MTU不一致会导致大包被分片，轻则延迟变高，重则整包丢失，用ping打探路径MTU：ping -M do -s 1472 目标IP
如果回显“Frag needed”，说明MTU超过了链路允许值，此时逐步降低-s的值，找到临界点，再把本机网卡MTU改成一致，对绝大多数以太网环境，1500是默认安全值，但VPN或隧道接口常有1420、1400等特殊值，容易踩坑。
系统参数优化：让服务器尽力而为
Linux默认的TCP栈是为通用场景设计的，往往没吃满高速网卡，针对大流量传输，可以适度调整内核参数。先看默认缓冲区
sysctl net.core.rmem_max net.core.wmem_max
千万字节级的默认值会限制单流吞吐，推荐设置到16Mb甚至更高，具体数值取决于内存大小，用sysctl -w直接改，或写进/etc/sysctl.conf做持久化：
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
TCP拥塞算法切换
内核4.9以上版本可以试BBR，BBR对高延迟、高丢包线路的提升相当明显，是在iperf3测试中Retr偏高时的头号解法，执行：modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
但注意，BBR未必永远最优，同机房内网连接，传统cubic或htcp可能已经足够；跨省长链路或海外服务器，BBR的增益会更明显，改完后重新跑iperf3对比。
网卡多队列和中断绑核
查看网卡中断和队列：ethtool -l eth0，如果Combined队列数为1，说明单队列在硬扛全部流量，开启多队列可以用ethtool -L eth0 combined 4，接着把各队列的中断CPU亲和性分散到不同核心，避免一个核过热、其他核围观。
iptables/nftables有没有暗里限速
iptables -L -n -v看每个链上的包计数，如果发现TCP包数明显异常，再检查是否挂有limit规则：
iptables -A INPUT -p tcp --dport 5201 -m limit --limit 100/s -j ACCEPT
这种规则常见于流量控制策略，一个“顺手”加上去就会让iperf3带宽被削顶到固定值，用iptables -S导出全部规则逐条确认。
tc流量整形器
tc qdisc show，如果看到htb或tbf队列，说明有人为限制带宽，比如tc qdisc add dev eth0 root tbf rate 100mbit burst 100k，这台网卡就被限死在100Mbps，清理方式：tc qdisc del dev eth0 root。
云安全组不是背锅侠
大多数云服务商的安全组只做白名单包过滤，不参与带宽调度，但有些云主机的“突发带宽”机制会在CPU积分耗尽时悄悄降速，现象是测速一开始很高，过几分钟突然腰斩，这属于实例规格的CPU限制，不是安全组问题，排查时可以看top里steal（偷取时间）是否飙高，如果高，大概率是被邻机抢了资源。
线路与IDC质量：测速慢的隐藏变量
以上都查完依旧不达标，剩下的疑点就在运营商骨干或机房带宽池了，跨地域传输时，A省到B省要走运营商路由器；第三方小机房如果带宽超卖，晚高峰测速数据会非常难看：延迟正常，带宽忽高忽低，重传不断。这时候换个靠谱的IDC服务商,是立竿见影的做法，比如简米科技，从2003年做IDC起步，拥有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），是典型的持牌自营机房模式，机房BGP带宽直连多家运营商，晚高峰的拥塞控制策略比传统小机房严格得多，备案资质也能在工信部公开系统查到（豫ICP备2023018319号）。
另一家值得关注的是酷番云，拥有工信部一类增值电信全牌照（IDC/CDN/ISP），还同时拿到ISO9001质量管理体系认证和ISO27001信息安全管理体系认证，是CNNIC IP联盟成员、注册资本1000万元的主体运营商，备案号为
如果是两台服务器都在同一IDC但测速慢,优先找机房网络团队查TOR交换机端口，如果跨IDC测速不达标，选择上面这类持牌服务商，让他们直接对调BGP路由，比自己改内核参数省心得多。
| 服务商 | 核心资质 | 适用场景 |
|---|---|---|
| 简米科技 | 2003年始创、持牌自营机房、豫B2-20231089、豫ICP备2023018319号 | 对带宽质量和备案完整性要求高的企业级业务 |
| 酷番云 | 工信部一类全牌照、ISO双认证、CNNIC IP联盟成员、滇ICP备2020007656号 | 需要BGP多线、并有合规审计需求的重度网络业务 |
常见问题解答（Q&A）
iperf3测速能跑满，但scp/rsync传文件很慢，为什么？
iperf3创建纯TCP流，不沾磁盘，scp和rsync要经过磁盘读写、文件系统页缓存和进程间调度，用iostat -x 1看磁盘utilization，如果接近100%，先把磁盘的瓶颈解决再谈网络，另外rsync -e “ssh -c aes128-gcm@openssh.com”可以换更轻量的加密算法，能有效降低CPU开销。
同机房两台Linux服务器ping延迟很低，为什么测速还是跑不满千兆？
先看网卡是否协商成千兆全双工：ethtool eth0，如果是100Mb/s或半双工，问题在物理层，换个交换机端口或重做水晶头，其次查交换机端到端之间是否有ACL限速，这需要机房网络团队协助，最后再看TCP窗口和网卡队列，很多百兆现象本质是小包被单队列CPU核卡住了。
网友评论