Linux服务器网络不稳定，先在两端用 mtr 定位到具体跳数，再用 ip -s link 和 ethtool 看网卡错误计数，绝大部分问题在这两步就能分出是链路、网卡还是本机负载，剩下的才轮到内核参数。
网络时快时慢、SSH 偶尔卡顿、接口隔几分钟超时一次，这类问题最磨人，它不像宕机那样有明确信号，你登录上去看 CPU 内存都正常，top 一切平静，可业务就是断断续续，下面按“分清故障类型逐层定位长期加固”的顺序讲,都是能照着敲命令的路子。
先把故障类型分清楚：网络抖动、丢包和带宽打满不是一回事
很多运维上来就改内核参数，这是典型的药不对症,三种现象的处理方向差得很远：
- 网络抖动：延迟忽高忽低，ping 值在 5ms 到 200ms 之间跳，多见于链路拥塞、无线回传、云厂商跨可用区转发。
- 持续丢包：延迟稳定但丢包固定在某个比例，多为网卡错误、光模块老化、MTU 不匹配。
- 带宽打满：丢包伴随重传飙升，
sar -n DEV里 rxkB/s 贴着网卡上限跑。
用一张表对照更直观：
| 现象 | 典型原因 | 首个验证命令 |
|---|---|---|
| 延迟忽高忽低，偶发超时 | 链路拥塞、跨区转发、队列排队 | mtr -rwzc 200 目标IP |
| 丢包比例稳定 | 网卡错误、MTU 黑洞、光模块 | ip -s link show eth0 |
| 吞吐先高后崩 | 网卡速率协商、半双工 | ethtool eth0 |
| 连接建立慢但通 | SYN 队列溢出、连接数打满 | ss -lnt、nstat -az |
先把这张表对上号,再往下走。
Linux服务器丢包严重怎么排查：四层定位法
排查顺序建议从外到内,别一上来就翻内核源码。
第一层：确认丢在哪一跳
在服务器和客户端两边分别跑长 ping 和 mtr，样本量给足，200 个包起步：
ping -c 200 -i 0.2 目标IP
mtr -rwzc 200 目标IPmtr 的价值在于它把每一跳的丢包都列出来，看两个细节：丢包是从第几跳开始的，以及后续跳数是否恢复正常，如果某一跳丢 20% 但下一跳丢 0%，那通常是那一跳路由器对 ICMP 限速，不是真故障；如果从某跳开始一直丢到底,问题就锁定在那一段。
顺带用 ip route get 目标IP 确认出口网卡,多网卡机器上经常出现流量走了错误网卡的情况。
第二层：看网卡自己有没有在丢
ip -s link show eth0
ethtool -S eth0 | egrep -i 'err|drop|discard|fifo|miss'
ethtool eth0ip -s link 的 RX errors、RX dropped、TX errors 三个计数是核心，注意区分：errors 增长对应物理层或驱动问题，dropped 增长多半是本机缓冲不够或上层丢弃。
ethtool eth0 重点看 Speed 和 Duplex，千兆网卡被协商成 100M 半双工是经典事故，症状就是大流量时延迟飙升、小流量完全正常，这种情况换网线、换交换机端口、强制指定速率都能验证。
驱动层的问题看内核日志：dmesg -T | grep -iE 'eth|link|reset|timeout'，频繁出现 link up/down 或者 tx timeout，基本可以判定网卡、驱动或线缆有问题。
第三层：TCP 重传和连接队列
丢包在应用层最直观的表现是重传,查看方式：
nstat -az | grep -iE 'Retrans|Reset|Overflow'
ss -lntSend-Q 长期不为 0，说明应用写得慢、内核发不出去；Recv-Q 堆积则是应用读得慢，这和网络无关,但表现很像网络卡。
nstat 里 TcpExtListenOverflows 或 ListenDrops 有增长，说明 SYN 队列被打满，需要调 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog。
还有一个容易被忽略的点：NAT 场景下的 conntrack 表满，用 conntrack -C 对比 sysctl net.netfilter.nf_conntrack_max，接近上限时新连接会直接丢，日志里表现为 nf_conntrack: table full。
第四层：MTU 黑洞和流量整形
云上环境尤其注意 MTU，VXLAN 封装后有效 MTU 通常是 1450，GRE 更小,判断方法：
ping -M do -s 1472 -c 3 目标IP1472 加 28 字节头部正好 1500，如果大包不通小包通，就是典型的 MTU 黑洞，调小网卡 MTU 或开启 net.ipv4.tcp_mtu_probing=1。
如果本机配过 tc 限速，用 tc -s qdisc show dev eth0 看 backlog 和 drop 计数，限速策略写错导致的丢包,现象和链路故障几乎一样。
云服务器网络延迟高，是服务器问题还是运营商问题
这是用户问得最多的一类问题，云上排查和物理机不完全一样，因为你看不到物理链路,但可以看几处边界信号。
先做排除，再看边界：
- 在同一可用区内两台机器互 ping，延迟稳定在 1ms 以内,说明云内网络正常。
- 跨可用区或跨地域延迟升高，属于正常物理距离,看是否在厂商文档的参考区间内。
- 只有公网访问慢，内网互访正常,那多半是公网出口或运营商侧链路。
业内专家指出，云环境的网络问题有相当一部分最终定位到公网出口拥塞或运营商互联质量，而不是用户实例本身，这种情况下继续在服务器上改参数,属于无效努力。
具体判断路径：
- 用
mtr从服务器到客户端方向跑，再从客户端到服务器方向跑,对比丢包出现在哪一段。 - 换一个运营商线路的机器做对照测试,比如同时用电信和联通节点。
- 检查实例规格的网络收发包能力（PPS 上限）,小规格实例在突发流量下会先丢包。
如果是公网质量问题，处理方式是提工单、换弹性公网 IP、或者加 CDN 和转发层做兜底,而不是继续调内核。
网络恢复稳定之后：双网卡绑定与监控告警
定位完故障,接下来做的是让它别再复发。
双网卡 bond 怎么配
单点网卡和单点交换机是物理机环境最常见的隐患，Linux 双网卡绑定（bonding）有几种模式：
- mode=1 主备：配置简单，交换机不用配合,切换时有一次短断。
- mode=4 LACP：需要交换机侧做端口聚合,吞吐和冗余兼得。
- mode=0 轮询：不推荐生产使用,容易出现乱序。
配置文件在 /etc/sysconfig/network-scripts/ 下建 ifcfg-bond0,关键几行：
BONDING_OPTS="mode=4 miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4"注意：云服务器上的多网卡通常不支持 LACP，主备模式也需要厂商支持，上生产前先确认,这条踩坑的人不少。
该盯哪些指标
监控上至少埋这几个点,比看平均延迟有用得多：
- 网卡 RX/TX dropped 的增量速率,不是绝对值。
- TCP 重传率的分钟级增量。
- 各链路的 mtr 丢包率,定期主动探测。
- 连接数、conntrack 使用率和文件描述符占用。
据工信部公开的通信行业服务质量统计口径，链路质量主要看丢包率与时延抖动这两项,和自己的监控指标对得上。
Linux服务器网络不稳定怎么办：三个高频疑问
问：ping 一直通但业务偶尔报超时，这种情况怎么查？
ping 走 ICMP，业务走 TCP，路径上设备对两者的处理策略可能不同，重点看 TCP 重传、SYN 队列溢出和 conntrack 表满三项，命令在第三层定位里已经列过,另外确认业务侧有没有配超时时间过短的连接池。
问：改了内核参数之后网络更差了，是什么原因？
常见于调大 net.core.somaxconn 和 backlog 却没同步调整应用侧的 accept 队列，或者为了降延迟把 tcp_retries2 调得过小，导致轻微丢包就断连，改参数前先记录基线，一次只改一到两个，观察 24 小时再动下一个。
问：物理机和云服务器的排查思路有什么差别？
物理机多一层网卡速率协商、光模块和交换机端口，ethtool 和 dmesg 的信息量更大；云服务器看不到物理链路，重心放在实例规格的 PPS 上限、安全组丢包计数、公网出口质量,以及多网卡环境下的路由和策略路由配置上。
抓住一条主线就够了：先用 mtr 把丢包钉到具体一跳，再用网卡计数和 TCP 重传判断是本机还是链路，最后才动内核参数和架构层面的冗余，顺序反了,问题只会越查越糊。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/782832.html
