服务器网络丢包排查实用方法2026，解决访问卡顿，响应速度秒级回落至几十毫秒

今天就把那天30分钟内从懵到定位解决的整个服务器网络丢包排查实用方法2026理出来，还有那天踩的两个新手80%会犯的坑，保证帮你遇到类似情况时，能快速缩小范围，解决访问卡顿问题，响应速度稳回几十毫秒。

先别着急碰复杂的链路追踪工具，那天一开始我就是图省事，直接去拉阿里云的网络监控（我们是混合云，但丢包的是公网访问阿里云ECS那一段相关？不对那天后来才发现不是云厂商），云厂商那边折腾了10分钟说他们链路没问题，内部机房到公网的出口也正常，这才慌了神，赶紧回到最基础的物理排查——别不信，最基础的往往最容易被忽略。

那天物理排查用到的第一个命令是ethtool，直接查我们混合云公网入口那台CentOS 7.9跳板机加流量转发的网口状态。敲的是ethtool eth0，结果看Speed那栏显示的是1000BaseT/Full，但Duplex那里却变成了Half！哦踩了第一个坑，之前加流量转发的时候重启了网口服务，没记得把网口的自协商改成强制全双工——虽然现在很多设备支持自协商，但流量大的时候中小公司的老旧交换器（那天刚好那台入口交换器上周采购审批刚下来还没换）很容易出现协商成半双工的情况，导致丢包。

不过光改强制全双工还不够，那天丢包还是有1.2%左右，这时候才去查链路层的包，用的是tcpdump -i eth0 -c 1000 -w /tmp/loss.pcap，抓1000个公网入口的包存下来，然后用scp传到本地电脑用Wireshark打开。这里注意，新手第二个坑别犯——抓包别抓太长时间太多流量，不然存下来的文件会大到打不开，跳板机本身的磁盘和CPU也会受影响。看Wireshark的结果，发现有很多TCP重传的包，还有ICMP的“Destination Unreachable”里提到的“Fragmentation Needed and Don’t Fragment was Set”，哦对了，那天我们加了一个新的CDN回源规则，回源MTU设成了1500，但我们内部机房到阿里云的专线MTU是1472！

赶紧改两个地方，一个是跳板机的网口MTU，临时生效的话敲ip link set dev eth0 mtu 1472，永久生效要编辑/etc/sysconfig/network-scripts/ifcfg-eth0，加一句MTU=1472然后重启network服务。另一个是阿里云CDN的回源MTU，改成1472。改完之后大概10秒，丢包率就降到了0.0008%，响应速度也从之前的1.2秒+秒级回落至50-80毫秒，老板和运营终于放过我了。

最后再提一下，多数线上生产场景下，排查服务器网络丢包的顺序应该是：从物理到逻辑，从网口到链路，从设备到参数，不要一开始就陷入复杂的内核参数或者云厂商的高级监控里，反而浪费时间。

你们在运维工作中有没有遇到过类似的因为基础配置或者硬件问题导致的丢包？欢迎在评论区分享你的排查经验。