早上刚到公司，还没来得及喝上一口水，客服就打电话过来说客户投诉视频会议卡顿、语音断断续续。登录监控系统一看，某条关键链路的丢包率从平时的0.1%飙升到了8%，而且还在持续波动。这种情况并不少见，但每次出现都让人头皮发紧。
先确认是不是真丢包
有时候“丢包”可能是误报。比如监控工具用的是ICMP ping，而网络策略对ICMP做了限速或优先级降低，这时候看到的丢包并不反映真实业务情况。可以换用业务实际使用的协议测试，比如用 hping3 模拟TCP连接：
hping3 -S -p 443 -c 100 your-server.com观察返回结果里的丢包统计，看是否和ICMP测试一致。如果不一致，那可能只是ICMP被特殊对待了。
从近端开始查：先看本地设备
别急着怀疑运营商线路，先检查自己这边的设备。交换机端口有没有错包计数上升？路由器CPU是不是跑满了？这些都能导致发不出或收不到包。
登录核心交换机，执行：
show interface gigabitethernet 0/1重点关注 input errors、output drops 和 CRC 这几项。如果发现大量CRC错误，很可能是网线老化或者接口松动。之前我们一个分支办公室丢包，最后发现是老鼠把网线啃了半截，表面看着好好的，一压上去就接触不良。
分段测试，缩小范围
用 traceroute 或 mtr 把路径拆开看：
mtr -n -c 50 8.8.8.8如果前几跳没丢包，中间某一跳开始大量丢包，基本可以锁定问题出在那一段。比如第5跳是运营商接入点，从这跳开始丢包，大概率是线路问题。这时候该打电话给ISP了，别自己瞎折腾。
服务器自身也可能是元凶
有一次我们收到告警说外网访问延迟高，查了一圈网络设备都没事，最后发现是某台Web服务器的网卡驱动出了问题，接收缓冲区一直满，TCP重传暴涨。用 netstat -s 查看系统网络统计，发现大量 retransmit timeout 和 packet receive errors。
临时解决方案是重启网卡驱动，长期方案是升级固件。这种问题不会体现在交换机端口计数里，必须深入服务器内部看。
突发流量挤占带宽
别忘了检查流量突增的情况。某个部门凌晨跑了个全量数据同步，占满上行带宽，其他业务全被挤掉，表现出来就是丢包。用NetFlow或sFlow工具看看那段时间谁吃了最多带宽。
策略上建议对非关键业务做QoS限速，至少保证语音、会议这类实时流量有最低保障。
无线环境更复杂
如果是Wi-Fi环境，丢包原因更多。信道干扰、信号衰减、设备密集都会导致重传。拿手机连同一个AP，走几步丢包率就变，那基本就是信号问题。可以用WiFi分析仪类App看信道占用情况，切换到空闲信道试试。
丢包率突然变高不是玄学，关键是按步骤来，从物理层一路往上查。很多时候问题就藏在你以为“不可能出事”的地方。