网络卡顿这件事，最怕的不是断网，而是那种"时好时坏"的丢包。网页能打开但图片加载一半卡住，视频会议声音断断续续，游戏里人物瞬移——这些症状背后往往就是丢包在作祟。很多人第一反应是重启路由器，或者打电话给运营商报修，结果对方一句"您这边线路正常"就把你打发了。其实在报修之前，你自己完全可以用系统自带的两个命令把问题定位个七七八八：ping和tracert。这两个工具不需要装任何软件，Windows、macOS、Linux 全都自带，用好了能帮你判断丢包发生在哪一段、是本地网络的问题还是运营商链路的问题、值不值得报修。这篇内容面向的是有一定动手能力、想自己排查网络问题的普通用户和初级运维人员，我会把这两个命令的用法、参数含义、结果解读、以及我这些年踩过的坑，一次讲透。
1. 先搞清楚丢包到底丢在了哪一段
1.1 丢包不是玄学，它是链路上某一跳的问题
很多人把"网络不好"当成一个整体概念，实际上从你的电脑到目标服务器之间，数据要经过十几甚至几十个节点：你的网卡、路由器、光猫、运营商接入设备、骨干网路由器、目标机房的路由器，最后才到服务器。丢包一定发生在其中某一跳上，而 ping 和 tracert 的价值就在于把这个"某一跳"给找出来。
ping 的原理很简单：向目标发送 ICMP 回显请求包，对方收到后回一个回显应答，你这边记录往返时间。如果发了 100 个包只回来 95 个，那丢包率就是 5%。但 ping 只能告诉你"到目标之间丢了"，没法告诉你丢在哪。tracert（Windows 叫 tracert，Linux/macOS 叫 traceroute）则是逐跳探测：先发一个 TTL=1 的包，第一跳路由器收到后 TTL 减为 0，回一个超时报文，这样你就知道了第一跳的地址；再发 TTL=2 的包，以此类推，把整条路径上的每一跳都画出来。
把两者结合，思路就清晰了：先用 ping 确认目标是否真的丢包，再用 tracert 找出路径，然后对路径上每一跳分别 ping，看从哪一跳开始丢包率突然上升。这个"分段定位"的思路是排查丢包的核心方法论，比盲目重启设备有效得多。
1.2 为什么不能只看 ping 的最终结果
我见过太多人 ping 一下目标，看到"请求超时"就断定网络坏了。这里有个关键认知：ping 不通不等于网络不通。很多服务器和中间路由器出于安全策略会禁用 ICMP 响应，你 ping 它没反应，但它的 80 端口、443 端口工作得好好的。所以 ping 的结果要分情况看：
- 如果 ping 目标完全不通，但网页能打开，说明对方只是禁了 ICMP，不代表链路有问题；
- 如果 ping 目标时通时不通，且丢包率稳定在某个比例，这才是真正的链路丢包；
- 如果 ping 目标延迟忽高忽低但一个包不丢，那是抖动（jitter），不是丢包，但对实时音视频同样致命。
tracert 也有类似的坑：路径中间某一跳显示"请求超时"是极其常见的，因为很多骨干路由器不响应 TTL 超时报文，这不代表那一跳坏了，只要后续跳数还能正常显示，路径就是通的。真正有意义的是"从某一跳开始，后面所有跳都超时"，那才说明问题出在那个位置。
1.3 排查前先明确你的目标是什么
动手之前先想清楚你要验证的是什么。是"我访问某个网站慢"，还是"我打游戏丢包"，还是"整个家里网络都不稳"？目标不同，ping 的对象也不同：
| 排查目标 | 建议 ping 的对象 | 说明 |
|---|---|---|
| 判断本机网卡和驱动是否正常 | 127.0.0.1 或本机 IP | 不通说明本机协议栈有问题 |
| 判断到路由器是否正常 | 网关地址（如 192.168.1.1） | 这一段丢包说明是内网问题 |
| 判断运营商接入是否正常 | 运营商 DNS 或公共 DNS | 这一段丢包要找运营商 |
| 判断目标服务器是否正常 | 目标域名或 IP | 只有这一段丢包才是对方的问题 |
这个分层思路很重要。我曾经遇到一个案例，用户抱怨"公司网络访问某云服务丢包严重"，结果一 ping 网关就丢了 8%，问题根本不在云服务，而是他工位的网线水晶头松了。如果不分层排查，很容易把锅甩错对象。
2. ping 命令的实战用法与结果解读
2.1 基础用法和那几个必须记住的参数
最基础的用法就是ping 目标地址，但默认只发 4 个包（Windows）或一直发（Linux/macOS），4 个包根本不足以判断丢包率。要真正测丢包，必须用参数控制发包数量和频率。Windows 下最常用的组合是：
ping -n 100 -l 1472 -w 1000 目标地址这里每个参数都有讲究。-n 100表示发 100 个包，样本量足够大才能算出可信的丢包率，4 个包丢 1 个是 25%，但样本太小没有统计意义。-l 1472指定发送的数据载荷大小为 1472 字节，这个数字不是随便定的——以太网 MTU 是 1500 字节，减去 IP 头 20 字节和 ICMP 头 8 字节，正好是 1472 字节，用这个大小能顺带测试路径 MTU 是否正常。-w 1000是超时时间 1000 毫秒，默认的 4000 毫秒太长，测丢包时没必要等那么久。
Linux 和 macOS 下参数名不同，对应的是：
ping -c 100 -s 1472 -W 1 目标地址-c是次数，-s是包大小，-W是超时秒数。这里有个容易踩的坑：Linux 的-s指定的是 ICMP 载荷大小，和 Windows 的-l含义一致，但有些教程会把它和整个 IP 包大小搞混，导致测出来的 MTU 判断错误。
2.2 长 ping 观察丢包的分布规律
短时间 ping 只能看到丢包率，长时间 ping 才能看出丢包的分布规律，而分布规律往往比丢包率本身更能说明问题。我的习惯是至少 ping 200 到 500 个包，观察丢包是均匀分布还是集中爆发：
- 均匀零星丢包（比如每 20 个包丢 1 个，很规律）：通常是链路质量差、有干扰，或者某一跳设备负载高；
- 集中连续丢包（比如连续丢 10 个然后恢复）：往往是链路瞬断、设备重启、或者无线信号切换；
- 周期性丢包（每隔固定时间丢一批）：可能是某个定时任务占满带宽，或者无线信道被周期性干扰。
Windows 下可以用ping -t 目标地址一直 ping，按 Ctrl+C 中断后看统计；更好的做法是加时间戳输出到文件，方便事后分析：
ping -n 500 目标地址 > ping_result.txtLinux 下可以用ping -D给每个包打上 Unix 时间戳，配合tee保存：
ping -D -c 500 目标地址 | tee ping_result.txt拿到带时间戳的结果后，把丢包的时间点和当时的操作对一下——是不是正好在下载大文件、是不是正好到了晚上用网高峰、是不是微波炉在加热——很多"玄学"丢包就是这么破案的。
2.3 读懂 ping 统计里的每一个数字
ping 结束后会输出一段统计，以 Windows 为例：
数据包: 已发送 = 100，已接收 = 96，丢失 = 4 (4% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 12ms，最长 = 89ms，平均 = 23ms这里除了丢包率，最大值和最小值的差距同样关键。平均 23ms 看着不错，但最长 89ms 说明存在明显的延迟抖动。对于普通网页浏览，这个抖动无所谓；但对于视频会议、在线游戏，抖动超过 30ms 就会有明显感知。所以判断链路质量不能只看丢包率，还要看延迟的稳定性。
还有一个细节：如果 ping 结果显示延迟极低（比如 1ms 以内）但丢包严重，要警惕是不是 ping 到了本机或者同一台交换机上的设备，这种"低延迟高丢包"的组合通常意味着本地链路有问题，而不是远端。
2.4 用 ping 测 MTU：一个被低估的排查手段
有些"丢包"其实是 MTU 不匹配导致的。典型症状是：小包能通，大包丢失，表现为网页能打开但大文件下载卡死、某些网站图片加载不出来。用 ping 可以精确测出路径 MTU：
ping -f -l 1472 目标地址-f是禁止分片标志（Linux 下是-M do），如果 1472 字节的包能通，说明路径 MTU 至少 1500；如果提示"需要拆分数据包但设置 DF"，就逐步减小-l的值，每次减 8 或 10，直到能通为止，那个临界值加上 28 就是实际的路径 MTU。这个技巧在排查某些特定应用"能连不能用"的问题时特别管用，我靠它定位过好几次莫名其妙的连接中断。
3. tracert 逐跳定位：把丢包点钉死
3.1 tracert 的基本输出该怎么看
Windows 下直接tracert 目标地址，输出是一行一行的跳数，每行显示跳数编号、三次探测的延迟、以及该跳的 IP 和域名。Linux/macOS 下是traceroute 目标地址，默认发 UDP 包，加-I可以改用 ICMP，加-T改用 TCP，这在目标屏蔽 UDP 探测时很有用。
看 tracert 输出要抓住几个要点。第一，延迟是逐跳累加的，正常情况下每一跳的延迟应该比上一跳略高或持平，如果某一跳延迟突然从 10ms 跳到 200ms，说明那一跳或者它前面的链路有拥塞。第二，星号*表示该跳没有响应，如前所述，中间跳出现星号很常见，不必惊慌。第三，关注从哪一跳开始出现连续的星号，如果从第 8 跳开始后面全是星号，那问题大概率出在第 8 跳附近。
一个典型的正常输出长这样：
1 1 ms 1 ms 1 ms 192.168.1.1 2 5 ms 4 ms 5 ms 10.0.0.1 3 12 ms 11 ms 12 ms 某运营商网关 4 15 ms 14 ms 16 ms 骨干网节点 5 18 ms 17 ms 19 ms 目标机房入口 6 20 ms 19 ms 21 ms 目标服务器如果第 3 跳开始延迟飙升到 150ms 且后面一直高，那问题就在运营商接入段；如果前几跳都正常，最后一跳才丢，那就是目标服务器自己的问题。
3.2 对每一跳做 ping：定位丢包点的关键一步
tracert 只告诉你路径和延迟，不告诉你每一跳的丢包率。真正的定位方法是：拿到 tracert 的路径后，对路径上每一跳的 IP 分别做长 ping。比如上面那个路径，就对 192.168.1.1、10.0.0.1、运营商网关、骨干网节点逐个 ping 100 个包，记录丢包率。
判断逻辑是这样的：如果第 1 跳到第 3 跳都不丢包，第 4 跳开始丢 5%，第 5、6 跳也丢 5%，那丢包就发生在第 3 跳到第 4 跳之间。注意，中间路由器对 ping 的响应优先级很低，它可能因为 CPU 忙于转发数据而丢弃发往自己的 ICMP 包，所以某一跳单独丢包但后续跳不丢，通常不代表真实丢包，只有"从某一跳开始，后续所有跳都丢"才说明问题。
这个"逐跳 ping"的操作虽然笨，但极其有效。我一般会写个简单的循环脚本批量跑，Windows 批处理或者 Linux shell 都行，省得手动一个个敲：
for ip in 192.168.1.1 10.0.0.1 网关IP 骨干网IP 目标IP; do echo "=== $ip ===" ping -c 50 $ip | tail -2 done跑完一遍，丢包从哪一跳开始，一目了然。
3.3 tracert 的几个实用参数
Windows 的 tracert 参数不多但够用。-d表示不解析域名，能大幅加快输出速度，排查时我基本都加这个参数，因为反查域名又慢又没必要。-h 最大跳数可以限制探测深度，默认 30 跳，一般够用。-w 超时毫秒设置每跳等待时间，默认 4000ms，路径长的时候整个 tracert 要跑两分钟，改成 1000ms 能快不少。
Linux 的 traceroute 参数更丰富，-n不解析域名，-m最大跳数，-q每跳探测次数（默认 3 次，改成 1 次更快但可靠性下降），-I用 ICMP 探测，-T用 TCP 探测。当目标或中间设备屏蔽 ICMP 时，用-T -p 443走 TCP 443 端口探测往往能穿透，因为 443 是 HTTPS 端口，一般不会被封。
提示：tracert 结果里的 IP 归属只能作为参考，不要拿它去做什么判断，重点看延迟变化和丢包分布。
4. 把 ping 和 tracert 组合起来的完整排查链路
4.1 一套可复现的五步排查流程
把前面的方法串起来，就是一套完整的排查流程。我把它整理成五步，遇到丢包问题照着走一遍，基本能定位到 90% 的情况：
- ping 本机回环和网关：
ping 127.0.0.1确认协议栈正常，ping 网关确认内网正常。网关就丢包，问题在网线、网卡、路由器或无线信号，跟运营商无关。 - ping 公共 DNS 或运营商网关：确认接入段是否正常。这一步丢包，直接找运营商报修，把 ping 结果截图给他们，比空口说"网不好"有说服力得多。
- ping 目标地址长包：
ping -n 200确认目标是否真的丢包，记录丢包率和延迟抖动。 - tracert 目标地址：拿到完整路径，观察延迟突变点和连续星号出现的位置。
- 逐跳 ping 路径上的关键节点：找出丢包率突增的那一跳，锁定问题区间。
这套流程的价值在于每一步都有明确的判断分支，不需要凭感觉猜。走完五步，你手里就有一份完整的证据链：哪一段正常、哪一段异常、异常的具体表现是什么。
4.2 三个真实场景的排查思路差异
不同场景下这套流程的侧重点不一样，我举三个典型情况。
场景一：家里 Wi-Fi 打游戏丢包。先 ping 网关，如果网关就丢包，八成是无线问题——信道干扰、距离太远、或者隔壁的微波炉。这时候 tracert 意义不大，重点是把有线接上对比测试，或者换个信道。如果网关不丢，再往外 ping，逐步排除。
场景二：访问某个网站特别慢。先 ping 目标，如果丢包且延迟高，tracert 看路径。如果路径正常但目标本身丢包，那是对方服务器的问题，你无能为力，只能等或者换镜像。如果路径中间某跳延迟飙升，可能是运营商互联互通的问题，换个时段再测往往会有变化。
场景三：整个办公室网络时断时续。这种影响面大的问题，先 ping 网关排除内网，再 ping 外网。如果内网就丢包，检查交换机、网线、有没有人在下 BT 占满上行带宽。上行带宽被占满时，下行也会表现为丢包，因为 ACK 包发不出去，这是很多人忽略的点。
4.3 排查时最容易犯的三个错误
第一个错误是样本量太小。ping 4 个包丢 1 个就下结论，实际上可能只是偶发。至少 100 个包起步，最好 500 个。
第二个错误是把中间跳的星号当成故障。前面强调过，中间路由器不响应 ICMP 是常态，只要后续跳正常，路径就是通的。我见过有人对着 tracert 里的星号研究半天，其实啥问题没有。
第三个错误是忽略本地因素。排查前先确认自己这边干净：有没有开下载、有没有连着一堆设备、网线是不是老化了、无线是不是 2.4G 拥挤频段。很多"运营商问题"最后查出来是自家路由器老化或者网线接触不良。
5. 那些文档里不会写的实操心得
5.1 用 ping 的 TTL 值反推经过了多少跳
ping 结果里有个 TTL 值，很多人不知道它还能用来估算跳数。初始 TTL 通常是 64（Linux）或 128（Windows），每经过一个路由器减 1。所以你 ping 目标看到的 TTL 如果是 52，说明经过了 64-52=12 跳（假设对方是 Linux）。这个技巧在没法跑 tracert 的时候能快速估个大概，也能用来验证 tracert 的结果是否合理。当然，有些系统会修改初始 TTL，所以只能作为参考。
5.2 无线环境下的丢包要单独对待
有线网络的丢包排查相对干净，无线就复杂得多。Wi-Fi 丢包可能来自信号弱、信道干扰、漫游切换、甚至蓝牙设备。我的经验是：无线环境下 ping 网关如果丢包率在 1% 到 3% 之间波动，先别急着报修，用手机连同一个 Wi-Fi 对比，如果手机也丢，那是路由器或信号问题；如果只有电脑丢，检查电脑的无线网卡驱动和电源管理设置——有些笔记本为了省电会周期性关闭网卡，表现为规律性丢包，把"允许计算机关闭此设备以节约电源"取消勾选就能解决。
5.3 保存证据比口头描述有用一百倍
跟运营商或 IT 支持沟通时，"我网络不好"是最没用的描述。正确的做法是提供：ping 网关的结果、ping 外网的结果、tracert 的完整输出、以及丢包发生的时间点。把这些整理成一个文本文件发过去，对方一看就知道你不是小白，处理效率会高很多。我习惯用ping -n 500 目标 > 结果.txt加上tracert 目标 >> 结果.txt把两份结果存一起，附上测试时间，一次说清楚。
5.4 长期监控比一次性排查更有价值
如果是那种"偶尔丢一下"的间歇性问题，一次性 ping 很难抓到。这时候可以用简单的脚本做长期监控，比如每分钟 ping 20 个包记录丢包率，跑一整天，把数据存成 CSV，用表格画个折线图，丢包集中在什么时段一目了然。Windows 下用计划任务跑批处理，Linux 下用 cron 跑 shell 脚本，都不需要装额外软件。这种长期数据在跟运营商扯皮时是杀手锏——"你看，每天晚上 8 点到 10 点丢包率稳定在 6%，这不是偶发"。
5.5 别迷信工具，先怀疑自己
最后说个心态问题。ping 和 tracert 是排查工具，不是诊断结论。它们能告诉你现象，但原因需要结合实际情况判断。我见过太多人拿着 tracert 结果里的某个 IP 就断定"是某某节点的问题"，实际上那个 IP 可能只是个不响应 ICMP 的普通路由器。排查网络问题最重要的能力不是背命令，而是分层思维：从内到外、从近到远，一段一段排除，每排除一段就缩小一次范围。工具只是帮你收集证据的手段，真正的判断还得靠脑子。
这套方法我用了很多年，从家庭宽带到机房链路都适用。核心就一句话：先用 ping 确认丢不丢，再用 tracert 找到丢在哪，然后逐跳 ping 钉死位置。把这三步做扎实，大部分网络问题你自己就能说清楚，不用再被"重启试试"打发。
