迁移后带宽不达预期，逻辑其实不复杂：先确认物理链路没缩水，再排查迁移配置是否丢参数，最后用iperf3和curl交叉验证，就能定位瓶颈在哪一层。
服务器迁移后带宽变慢？先分清到底是哪条链路在扯后腿
很多朋友遇到的情况是这样的：机房搬迁完成，业务也上线了，但压力测试一跑，带宽就是上不去，查了云厂商控制台，带宽规格没变，安全组也没拦，但监控面板上的流量曲线就是平的。
这时候别急着怀疑上游服务商,按下面的顺序捋一遍。
检查物理链路的基本功：光模块是千兆还是万兆，网线是Cat5e还是Cat6，交换机端口有没有因为协商失败降级到百兆，前阵子就有个用户迁移后带宽跑不满，最后发现是施工队把万兆光模块插进了千兆端口，这种低级错误在迁移场景中占比不小。
重点看路由路径：迁移到新机房后，运营商接入的BGP线路可能跟原来不同，用mtr -rwz -c 100 <目标IP>跑一下，如果看到中间跳数超过了十五到二十跳，或者延迟数值忽高忽低，那大概率是网络路径绕了远路，国内跨运营商访问尤其明显，一个华东访问华北的业务，理论上该走骨干网直达，但如果被导到了公网出口，带宽损耗直接一半起步。
云服务器迁移带宽跑不动？先看虚拟化层驱动
这是迁移场景里最典型的坑,从VMware迁到KVM，或者从物理机迁到OpenStack，网卡虚拟化类型变了，驱动往往还是老的。
在Linux服务器上执行ethtool -i eth0，看一下driver那一栏，如果是e1000或e1000e，而宿主机的虚拟化平台是KVM，那带宽上限就很尴尬了，行业共识认为，e1000模拟网卡的PPS吞吐能力比virtio-net低一个量级，万兆环境下甚至达不到2Gbps。
解决办法不复杂：替换内核模块，把网卡驱动切到virtio-net，然后重新加载网络配置，具体命令大致是：
modprobe virtio_net
但改驱动之前,建议先确认新平台的模块支持情况，免得改了之后网卡失效又要折腾。
迁移配置排查：TCP参数和网卡队列是隐形杀手
TCP窗口与缓冲区的默认设置
很多Linux发行版的默认TCP参数是偏向低延迟场景的,带宽跑满需要较大的拥塞窗口，迁移后如果没启用cubic或bbr，或者rmem和wmem缓冲区不够大，高速传输时就会看到典型的锯齿形速率波动。
举个例子,跨地域专线迁移到新机房后，测出来的带宽如果远低于标称值，先把下面这几个参数拉起来再看：
net.core.rmem_max提高到 16777216net.core.wmem_max提高到 16777216net.ipv4.tcp_congestion_control切换为bbr（内核版本支持的话）
这里有个容易忽略的点：TCP BBR算法对丢包很敏感，如果链路本身有丢包，开不开BBR差别很大，可以直接用ping -c 100 -i 0.2观察丢包率，如果超过1%，先解决物理链路再调参数，业内专家指出，迁移前后的TCP参数调优不建议一次性改完，每改一个参数压测一次，这样能精确定位到底是哪条配置起了作用。
网卡多队列与CPU绑核
单队列网卡在中断处理上会撞车,多核CPU如果只有一个核处理中断，吞吐量到2-3Gbps就上不去了，迁移之后到/proc/interrupts看一眼，如果所有中断都落在同一个CPU上，那就需要打开网卡的RSS或RPS。
不开RPS的代价挺直接：买了10Gbps的带宽，但实际跑起来只有3Gbps，而且CPU占用率还特别高，开启RPS的路径在/sys/class/net/<接口名>/queues/下面，具体配置因发行版而异，但原理都是把网卡中断分散到多个核上。
带宽测试iperf和curl哪个准？工具选对比测对更关键
这是排查案例里被问得最多的问题,直接给结论：两者测的不是一回事。
| 工具 | 测的维度 | 适合场景 | 常见误区 |
|---|---|---|---|
| iperf3 | 纯TCP/UDP吞吐 | 点对点链路评估 | 没跑满可能因为单线程瓶颈 |
| curl 下载 | HTTP层单连接速度 | 业务下载体验参考 | 被服务器端带宽限速干扰 |
| Speedtest | 多连接聚合 | 终端用户感知 | 节点选择不同结果差异大 |
| scp/rsync | 磁盘+网络叠加 | 文件迁移估算 | 磁盘I/O瓶颈被误判为带宽 |
iperf3测出来是链路理论上限,curl测出来是实际业务可用带宽，如果iperf3能跑到7Gbps，但curl只有800Mbps，问题出在Web服务端或TCP单连接限速，跟链路本身无关。
实操建议：先用iperf3加-P 8参数跑8条并发流，如果聚合吞吐正常，说明物理链路没问题，接着转向排查应用层，如果并发流也跑不满，那大概率链路路径或接口协商有问题，回到前面的路由和驱动排查。
企业专线迁移后带宽验证的完整路径
跨地域节点对比测试怎么设计才客观
这阵子接触到的案例都比较典型,某企业把机房从张江迁到金桥，专线带宽标称200Mbps，但业务方反馈下载速度只有几十M，排查路径是这样的：
先在源和目的各部署一台iperf3服务端,分别从华东、华北两个地域的测试节点发起测试，如果华东节点测出来接近200Mbps，华北节点测出来只有50Mbps，那问题就锁定在跨地域链路或运营商互联质量上，而不是迁移本身。
另外有个细节值得留意：专线跟公网是两套边界，迁移后如果业务走的是专线，但测试工具走了公网，那测出来的数据就没有参考意义，务必确认测试流量走的是专线网段。
迁移后带宽不达预期的操作清单
- 确认新机房接入设备的端口协商速率与光模块规格一致
- 检查服务器网卡驱动是否适配新虚拟化平台
- 对比迁移前后的
route -n输出，确认路由出口没变化 - 用mtr同时跑TCP 80端口和ICMP的探针，对比丢包差异
- 调完TCP参数后重启网络服务,别一边压测一边改参数
这套清单走完,相当一部分“迁移后带宽不达预期”的情况都能被定位，剩下的少数场景，比如运营商侧限速或跨城链路问题，就需要联系服务商做上联侧测试了。
迁移带宽排查不是玄学，是一层层剥洋葱
带宽跑不满的根因,绝大多数集中在物理链路协商、虚拟化驱动和路由路径这三处，先跑mtr和ethtool，再用iperf3和curl交叉验证，基本能圈定范围，如果两条工具的测试结果能对得上，那说明链路没问题，重点去查服务端限速或TCP参数。
迁移后带宽不达预期排查相关问答
迁移后为什么上传带宽正常但下载带宽远低于标称值？
上传和下载走的是不同方向的链路,运营商在接入端的上下行配置也可能不同，先确认服务器网卡和交换机端口是否支持全双工，再分别用iperf3的-R参数测试双向吞吐，如果上传正常下载异常，大概率是运营商侧的下行限速策略或路由回程路径绕路，用traceroute对比两个方向的路径差异即可验证。
迁移后带宽测试结果不稳定的原因是什么？
最典型的原因是链路存在间歇性丢包,比如光模块触点氧化或尾纤弯折，其次是邻居干扰，物理机迁移到公有云后，宿主机上其他实例的突发流量会挤占物理网卡，建议连续跑多次iperf3取最小值，并观察测试过程中的延迟抖动，据统计，间歇性丢包导致带宽波动在迁移场景中占比较大，通过更换光模块或物理端口能解决多数情况。