服务器丢包排查方法：从 ping 到 MTR 的完整定位流程

服务器出现丢包时，先别急着换机房或重启。
你需要先判断丢包发生在哪一段：是本机网卡、本地运营商、中间骨干网，还是目标服务器。
大多数情况下，用 ping 加 mtr 就能把范围缩小到某一段链路，再用 tcpdump 确认是否被防火墙或限速策略拦截。

先确认是不是真丢包

在开始排查前，需要先排除“看起来像丢包”的假象。
例如目标服务器禁用了 ICMP 回包，ping 会显示超时，但 TCP 业务其实是通的。

准备条件：

• 一台能正常执行命令的 Linux 服务器（CentOS、Ubuntu、Debian 均可）。
• 知道目标 IP 或域名，最好同时准备一个同机房的其他 IP 做对照。
• 如果是宝塔面板用户，可以直接在面板终端操作，路径为：面板首页 -> 终端。

先执行基础连通性测试：

ping -c 20 目标IP

观察输出末尾的统计行，例如 20 packets transmitted, 20 received, 0% packet loss。
如果丢包率在 1% 以内且延迟稳定，通常属于正常波动；
如果丢包率超过 5% 或延迟忽高忽低，才需要继续排查。

如果 ping 完全不通，但网站能打开或 SSH 能登录，说明目标禁用了 ICMP，这种情况不要用 ping 判断丢包。

用 MTR 定位丢包发生在哪一跳

ping 只能告诉你“丢了”，mtr 能告诉你“在哪丢的”。
MTR 会结合 ping 和 traceroute，持续向每一跳发送探测包。

安装 MTR：

# Debian/Ubuntu
apt install mtr -y

# CentOS
yum install mtr -y

执行双向测试，先测本机到目标：

mtr -rwzc 50 目标IP

参数含义：-r 输出报告，-w 宽屏模式，-z 显示 ASN 信息，-c 50 发送 50 个包。

结果解读：

• 如果从第 1 跳就开始丢包，问题在本机网卡、网线或本地网关。
• 如果中间某一跳开始丢包，且后续所有跳都持续丢包，问题大概率在该跳或之后。
• 如果中间某一跳丢包，但后续跳恢复正常，这通常是该路由器不响应 ICMP，属于正常现象，不代表链路故障。

再从目标服务器反向 MTR 回你的 IP，因为去程和回程可能走不同线路。
两边结果对比，能更快锁定单向丢包。

检查本机网卡和防火墙

如果 MTR 显示第一跳就丢包，或者丢包集中在你自己这台机器上，优先查网卡统计和防火墙规则。

查看网卡错误和丢包计数：

ip -s link show eth0

把 eth0 换成你的实际网卡名，可以用 ip addr 查看。
重点看 RX 和 TX 部分的 errors、dropped、overrun。
如果 dropped 持续增长，可能是网卡缓冲区不足或 CPU 处理不过来；
如果 errors 增长，可能是网线、光模块或交换机端口问题。

检查防火墙是否拦截或限速：

iptables -L -n -v

如果使用 firewalld：

firewall-cmd --list-all

注意看有没有 DROP、REJECT 规则，或者 hashlimit、limit 这类限速模块。
宝塔用户可以在 安全 页面查看是否有异常 IP 封禁记录。

用 tcpdump 确认业务端口是否被拦截

ICMP 测试正常，但业务端口丢包，需要用 tcpdump 抓包确认数据包到底有没有到达服务器。

抓取指定端口的流量：

tcpdump -i eth0 -nn host 你的客户端IP and port 目标端口 -c 100

例如排查 443 端口：

tcpdump -i eth0 -nn host 203.0.113.10 and port 443 -c 100

在客户端同时发起请求，观察服务端是否能抓到包。

判断依据：

• 服务端能抓到请求包，但没有回包，问题在服务端应用或防火墙出站规则。
• 服务端抓不到任何包，问题在中间链路或客户端到服务端之间被拦截。
• 抓到大量重复包或重传包，说明链路存在拥塞或丢包。

抓包时注意不要长时间全量抓取，避免占满磁盘。-c 100 表示抓满 100 个包自动停止，按 Ctrl+C 也可以手动结束。

容易踩坑的几个地方

不要只看一次 ping 结果就下结论。 网络抖动有随机性，至少测试 50 到 100 个包，并且在不同时间段复测。

MTR 中间跳丢包不一定是故障。 很多骨干路由器对 ICMP 探测包做了限速或降优先级，只要最终跳不丢包，业务通常不受影响。

区分 ICMP 丢包和 TCP 丢包。 有些服务器或云厂商安全组默认只放行特定端口，ICMP 被丢弃不代表业务端口有问题，反过来也一样。

云服务器还要看安全组和控制台监控。 阿里云、腾讯云等厂商的控制台通常有网络监控和流量日志，安全组规则错误也会表现为“丢包”，但实际是拦截。

改动防火墙或网卡参数前先备份。 例如修改 iptables 规则前执行 iptables-save > /root/iptables.bak，避免规则清空后无法远程连接。

验证丢包是否真正解决

完成调整后，按同样的方式复测，确认结果可对比：

ping -c 100 目标IP
mtr -rwzc 100 目标IP

如果丢包率从高位降到 0% 或接近 0%，且 MTR 各跳延迟稳定，说明问题已缓解。
如果仍然丢包，保留两次测试结果，提交给服务器提供商或运营商，让它们从骨干网侧继续排查。

排查服务器丢包的核心思路是：先确认是否真丢包，再用 MTR 定位跳数，最后用网卡统计和抓包确认本机与业务端口状态。
按这个顺序走，大多数常见丢包问题都能在半小时内缩小到具体环节。