在Ubuntu服务器运维中遇到网络丢包问题，最直接有效的定位手段就是组合使用mtr和traceroute这两个工具。traceroute能帮你逐跳追踪数据包从源到目的经过的每一个路由器节点，而mtr则在traceroute的基础上增加了实时丢包率和延迟统计，能持续监控每一跳的网络质量。两者配合使用，基本可以在几分钟内锁定丢包发生在哪一段链路上，是运营商骨干网、机房出口还是内网交换层的问题。

很多运维人员在排查丢包时只用ping命令看通不通，这远远不够。ping只能告诉你目标可达还是不可达，无法告诉你问题出在哪一跳。traceroute和mtr的核心价值就在于"逐跳诊断"，把整条链路拆开来看，每一跳的延迟和丢包率一目了然。

一、traceroute的安装与基本使用

Ubuntu系统默认通常没有预装traceroute，需要手动安装。执行以下命令即可：

sudo apt update
sudo apt install traceroute -y

安装完成后，最基础的用法是指定目标IP或域名：

traceroute 8.8.8.8

输出结果会显示从你的服务器到目标IP经过的每一跳路由器，每一行包含三个时间值（单位毫秒），分别代表发送三个探测包的往返延迟。如果某一跳出现三个星号（* * *），说明该节点没有响应ICMP探测包，但这不一定代表丢包，很多路由器出于安全策略会禁用ICMP回复。

更推荐使用ICMP模式而不是默认的UDP模式，因为很多防火墙会过滤UDP探测包，导致中间节点全部显示星号，误导判断。使用ICMP模式的命令：

traceroute -I 8.8.8.8

如果你想指定源IP地址（比如服务器有多个网卡），可以用：

traceroute -I -s 192.168.1.100 8.8.8.8

traceroute还有一个实用参数是-n，不做DNS反向解析，直接显示IP，速度更快也更清晰：

traceroute -n -I 8.8.8.8
二、mtr的安装与核心功能

mtr（My Traceroute）是traceroute的增强版，它把traceroute的逐跳追踪和ping的持续统计结合在一起，实时刷新每一跳的丢包率、平均延迟、最大延迟、最小延迟等数据。在Ubuntu上安装：

sudo apt install mtr -y

mtr有两种运行模式：交互式和报告模式。交互式模式适合实时观察：

sudo mtr 8.8.8.8

进入交互式界面后，你会看到一个不断刷新的表格，每一行代表一跳，列包括Loss%（丢包率）、Snt（发送包数）、Last（最近一次延迟）、Avg（平均延迟）、Best（最小延迟）、Wrst（最大延迟）、StDev（标准差）。重点关注Loss%这一列，哪一跳出现持续丢包，问题基本就在那一跳或其下一跳。

报告模式适合把结果保存下来发给网络供应商或做后续分析，指定发送100个包后自动生成报告：

sudo mtr -r -c 100 8.8.8.8

如果你需要同时做DNS解析和IP显示，可以组合参数：

sudo mtr -r -c 100 -n 8.8.8.8

还有一个很实用的功能是指定报告输出为XML或JSON格式，方便脚本解析：

sudo mtr -r -c 100 --json 8.8.8.8
三、如何通过输出结果精准定位丢包位置

拿到mtr或traceroute的输出后，关键是学会读懂数据。举个实际场景：你的Ubuntu服务器访问某个业务IP时用户反馈卡顿，你执行mtr后发现第3跳开始Loss%持续在15%-30%，而前两跳是0%。这说明问题出在第3跳对应的路由器或链路上。如果第3跳是你机房的出口路由器，那就是内网问题；如果第3跳已经是运营商的节点，那就需要联系ISP。

这里有一个常见误区：某一跳显示100%丢包但后续跳又恢复了，这通常不是真正的丢包。很多中间路由器配置了ACL策略，禁止对ICMP探测包做响应，但实际转发数据包是正常的。判断真正丢包的标准是：从某一跳开始Loss%持续大于0，并且后续所有跳的Loss%都同步升高，这才说明该节点确实在丢弃数据包。

另一个技巧是对比双向路径。从你的服务器traceroute到目标，再从目标traceroute回你的服务器（如果目标允许的话），双向对比可以判断是去程还是回程丢包。很多时候用户反馈"访问慢"，其实是回程链路有问题。

四、结合其他工具做深度排查

mtr和traceroute定位到大致位置后，还需要配合其他工具做进一步确认。如果怀疑是带宽拥塞导致的丢包，可以用iperf3做带宽测试：

# 在服务器端
iperf3 -s
# 在客户端
iperf3 -c 服务器IP -t 30 -P 4

如果怀疑是TCP层面的问题（比如某些应用走TCP而mtr默认用ICMP/UDP），可以用tcptraceroute来追踪TCP路径：

sudo apt install tcptraceroute
sudo tcptraceroute 8.8.8.8 443

tcptraceroute使用TCP SYN包进行追踪，能模拟真实业务流量的路径，对于排查Web服务、数据库连接等TCP场景的丢包非常有价值。

同时，查看系统层面的网络统计也很重要。用ss或netstat查看是否有大量重传：

ss -s

如果输出中retrans的数值持续增长，说明TCP层面确实在重传，结合mtr定位的位置就能确认问题链路。

五、实际运维中的排查流程建议

给大家总结一套标准化的丢包排查SOP。第一步，先用ping确认目标是否可达以及基础延迟和丢包率：

ping -c 20 8.8.8.8

第二步，用traceroute -n -I快速看路径和大致哪一跳开始异常。第三步，用mtr -r -c 100 -n持续监测100个包，获取每一跳的精确丢包率。第四步，如果发现某一跳丢包，用tcptraceroute确认TCP路径是否同样有问题。第五步，用iperf3测试带宽，排除拥塞因素。第六步，如果确认是运营商链路问题，把mtr报告截图或导出发给ISP技术支持，这是最有力的证据。

在日常运维中，建议把mtr做成定时监控脚本，每隔几分钟跑一次并记录结果，这样可以捕捉到间歇性丢包。间歇性丢包最难排查，因为你手动跑的时候可能恰好正常，但用定时脚本就能抓到异常时间窗口。

#!/bin/bash
while true; do
    mtr -r -c 50 -n -j 8.8.8.8 >> /var/log/mtr_$(date +%Y%m%d_%H%M%S).log
    sleep 300
done
六、常见问题与注意事项

使用mtr和traceroute时有几点必须注意。首先，这两个工具都需要root权限才能发送原始ICMP包，普通用户运行会自动切换到UDP模式或者报错。其次，云服务器环境中，很多云平台的安全组或虚拟网络会限制ICMP，导致traceroute中间全是星号，这时候需要在云控制台开放ICMP或者改用tcptraceroute。再者，mtr的交互式界面中按d键可以切换显示DNS名称，按n可以切换回IP显示，按q退出。

还有一个容易忽略的点：如果你的服务器本身CPU负载很高，mtr和traceroute的统计数据也会不准确，因为探测包的发送和接收受到系统资源影响。排查前最好先用top或htop确认CPU和内存状态正常。

最后强调一点，mtr和traceroute是定位工具，不是修复工具。它们能告诉你问题在哪里，但解决问题需要根据定位结果采取不同措施：如果是内网交换机问题就换设备或调配置，如果是运营商问题就提交工单，如果是服务器自身网卡或驱动问题就排查硬件和内核参数。工具用对了，排查效率能提升数倍，这是每个Ubuntu运维人员都应该熟练掌握的基本功。