丢包率上去了，先别急着骂运营商，用两步法判断问题出在内网还是出口，再对症下药。
丢包率飙升时，你的第一反应是什么
很多网管看到丢包率报警,第一件事就是打开路由器ping网关，其实这个动作太着急了你ping的是内网网关，丢包只能说明内网有问题，但出口丢包你根本测不到，真正的排查逻辑应该是：从用户端到核心交换机测一次，再从核心交换机到公网IP测一次，两次结果一对比，锅在谁身上立刻清楚。
举个例子,办公室电脑ping网关延迟正常但丢包10%，而防火墙ping公网IP丢包0%，那问题一定在内网，反过来，内网全网段测试都正常，唯独从防火墙出去丢包严重，那出口链路就是嫌疑大头，这套逻辑听起来简单，但实际执行时很多人因为不熟悉命令、不知道看哪几个指标，半天定位不到根因。
先分清楚：丢包到底发生在哪个物理段
把网络路径拆成三段终端到接入交换机、接入到核心、核心到出口运营商，每一段用不同的目标地址测试，就能把故障范围缩到最小。
终端到接入层：用ping网关验证
在用户电脑上执行ping <网关IP> -n 100（Windows）或ping -c 100 <网关IP>（Linux/macOS），网关IP一般是你接入交换机的管理地址或三层网关地址，观察三个核心指标：
- 丢包率：只要不为0，说明终端到接入层这段链路有干扰、协商异常或设备过载
- 延迟抖动：延迟稳定在1-2ms，突然跳到几十ms，大概率是端口协商到了半双工或网线质量差
- 顺序错误：如果显示“TTL传输中过期”或者乱序，可能是环网或广播风暴
这段测试最好用有线网络,Wi-Fi环境下丢包本来就受无线干扰影响，测出来的结果不能代表内网真实状态，行业共识认为，有线网络丢包率应该长期为0，无线网络正常情况下丢包率低于1%才算健康。
接入层到核心层：跨交换机分段ping
从核心交换机上ping各接入交换机的管理地址,或者反过来从接入交换机ping核心，这步是为了验证跨设备转发是否正常，执行ping <核心交换机VLAN接口IP> repeat 100（Cisco/H3C）或ping -i 0.01 -c 100（华为）等命令，这里有个操作技巧：
- 先ping接入交换机的上联口地址,通了再ping核心的网关地址
- 如果第一个通了第二个不通,问题出在接入交换机到核心之间的链路（光模块、跳线、VLAN配置）
- 如果两个都不通,优先检查接入交换机CPU使用率，可能是ARP攻击导致转发异常
很多内网丢包问题的根源不是线路,而是交换机CPU过载。广播报文、环路、异常流量都会导致CPU占用飙升，从而影响ping响应优先级，遇到这种情况，在交换机上执行display cpu-usage（华为）或者show process cpu（思科），看5秒内的峰值，如果大于50%，基本可以判定是设备性能瓶颈。
核心层到出口：用公网IP做参照物
选两个测试目标：一个是运营商给的网关IP（出口路由器的下一跳），另一个是公共DNS如
5.5.5，在核心交换机或防火墙上分别执行ping测试。
- 内网ping运营商网关丢包，但ping公网DNS不丢包：说明问题在运营商链路质量差，比如光衰过大、链路拥塞
- 两者都丢包：先看防火墙的会话数是否已满，再检查出口设备的带宽占用，多数情况下都是P2P下载或视频流量把出口带宽打满了
这里有个容易被忽略的点：运营商网关IP在设备上ping不通，不代表出口链路挂了，有些运营商禁ping，而有些网关设备本身QoS策略会丢弃ICMP报文，判断出口丢包最可靠的办法是同时ping两个不同的公网IP（比如阿里DNS和Google DNS），如果两个都丢包且丢包率接近，那才是真丢了。
常用排查工具和命令，别只会用ping
ping确实直观,但它测的是ICMP协议，而实际业务跑的是TCP/UDP，有时候ping不丢包，但下载文件或视频会议却卡顿，这说明应用层丢包被ping掩盖了，处理这类问题需要更专业的工具。
用mtr命令定位丢包点（Linux/Windows多平台）
mtr是traceroute和ping的结合体,能显示每一跳的丢包率和延迟，执行mtr -rw <目标IP>，看输出结果时重点关注中间节点的Loss%列：
- 如果目标节点丢包率很高,但最后一跳丢包率为0，说明中间节点的丢包是假象（节点QoS策略丢弃探测包）
- 如果最后一跳丢包率与中间节点一致,说明问题出在最终链路上
业内专家指出,mtr结果中如果某个节点连续多次丢包率超过20%，且后续节点同样丢包，那这个节点大概率是真实瓶颈。
用iperf3测端到端吞吐，区分丢包和限速
丢包率上升时,同时也跑一下iperf3测试，在服务器端执行iperf3 -s，客户端执行iperf3 -c <服务器IP> -u -b 100M，观察Jitter和Lost/Total，如果你内网跑UDP 100M带宽丢包率接近0，但业务一跑就卡，说明问题不在带宽而在设备转发性能或应用本身。
抓包看TCP重传率
当应用表现为卡顿但ping正常时,用Wireshark在服务器侧抓包，看TCP Retransmission的比例，重传率超过0.5%就说明存在真实丢包，通常由以下原因引起：
- 网卡队列溢出（软中断集中在单核）
- 交换机缓冲区不足（尾丢弃）
- 中间设备安全策略丢包（如防火墙IDS误杀）
这个场景下,ping根本反映不出问题，因为ICMP报文小且频率低，远达不到拥塞阈值。
内网丢包怎么排查：按顺序做这三件事
确认丢包发生范围在内网后,不要盲目更换网线，按下面步骤从高概率到低概率排查。
检查端口协商状态和错误计数
在接入交换机上执行display interface或show interface，看Input Errors、CRC Errors、Collisions几个计数器，CRC错误持续增长说明物理层信号质量差，大概率是网线或接口接触不良；Collisions增长说明存在半双工或环路；Input Errors增长可能是光模块光衰过大，这时候用clear counters清零后再观察5分钟，如果错误计数继续涨，直接换线换模块。
排查环路和广播风暴
内网设备数量不多但丢包严重,先广播一个场景：突然某几个终端网络卡顿，交换机跑满CPU，处理方式是在核心交换机上执行display mac-address（华为）或者show mac address-table，看MAC表项是否异常重复，更直接的方法是拔掉疑似环路端口的网线/光纤，看CPU使用率是否下降，如果没有环路，再检查是否存在ARP攻击在终端命令行执行arp -a，如果同一IP对应多个MAC地址，基本确认内网有伪造ARP设备。
检查VLAN和生成树配置
VLAN划分不合理或STP（生成树协议）收敛异常也会造成周期性丢包，比如接入交换机某些端口一直处于Blocking状态，数据转发绕路产生高延迟，用display stp brief看端口状态，如果存在大量Listening/Learning状态，说明STP在频繁收敛，多半是交换机间有物理环路或配置错误。
出口带宽丢包原因：从链路和流量两头查
内网测试全通过,丢包全在出口方向，那问题就聚焦到运营商链路和你的出口设备上了。
链路质量：光衰和拥塞是两大元凶
拨号线路或者专线,跑到机房看光猫/光模块的光功率，接收光功率在正常范围内（一般-20dBm以上）才合格，光衰过大直接导致丢包，且丢包率随温度升高而恶化，另一种常见情况是运营商链路拥塞办公高峰时段丢包激增，深夜恢复，这基本就是出口带宽跑满了，在设备上查看实时带宽利用率，如果持续超过90%，扩容带宽或者做QoS限速，二者必须选一个。
出口设备性能：防火墙和小路由器的软肋
很多企业用家用路由器当出口网关,连接数一多就丢包，家用路由器CPU处理能力有限，NAT会话表满了直接丢弃新连接，进入设备后台看系统负载和连接数，如果连接数接近上限值，考虑升级到企业级防火墙或路由器，另外检查出口设备是否开启了流量整形或安全策略，这些功能本身就会引入延迟和丢包，试着暂时关闭流控，再测丢包率，如果恢复正常，说明是设备策略误杀而非网络故障。
MTU设置不当，大包全丢
一种隐蔽的出口丢包场景是：ping小包不丢，ping大包全丢，这通常是MTU（最大传输单元）不一致导致的，比如运营商拨号线路要求MTU为1492，但你设备设置成了1500，超过链路承载能力的大包会被丢弃，用ping -f -l 1472 <公网IP>（Windows）测试，如果提示“需要拆分数据包”但设置了不分片，就说明MTU过大，调整出口接口的MTU值到适配线路即可解决。
丢包率多少算正常：不同场景的参考标准
很多运维人员对丢包率是否正常没有概念,等到业务投诉了才启动排查，给出一个行业常用参考值：
| 网络场景 | 正常丢包率 | 可接受阈值 | 需要处理 |
|---|---|---|---|
| 企业内网有线 | 0% | 05% | 高于0.1%就排查 |
| 企业Wi-Fi | 低于1% | 2% | 超过3%影响语音视频 |
| 公网专线 | 低于0.1% | 5% | 超过1%体验明显下降 |
| 家庭宽带 | 低于1% | 3% | 超过5%基本无法游戏 |
这个表是多年的运维经验总结,不代表任何官方标准，实际业务中，语音和视频对丢包最敏感，超过1%就会断续；网页浏览和文件下载相对容忍，但超过5%也会影响体验，所以判断是否要处理，先看业务类型，再对照这个表。
最终排查流程，照着做就行
现在把上面的方法收拢成一个标准操作流程,下次丢包率报警时按这个顺序执行，10分钟内定位到内网还是出口。
- 在终端ping内网网关,记录丢包率
- 在核心交换机上ping运营商网关和公网DNS,记录丢包率
- 对比结果：内网丢包>出口丢包，走内网排查流程；反之走出口排查流程
- 内网排查：检查端口错误计数、环路、STP、CPU负载
- 出口排查：查看带宽利用率、光功率、MTU、设备性能
- 修复后重新测试同一组ping命令,直到丢包率回到正常范围
整个过程不需要昂贵的工具,一台电脑加上交换机的命令行权限就能完成，核心记住一句话：分段测试，对比数据，别让直觉代替测量，丢包是谁的锅，数据会告诉你答案。
Q&A：丢包率排查常见疑问
丢包率上去了，先分清是内网还是出口的锅，到底哪种情况更多？
在实际故障中,内网问题占比更高，尤其在公司规模不大、网络结构简单的情况下，原因有三：一是内网网线老化或接头松动，二是交换机级联过多且没有生成树优化，三是终端网卡驱动异常导致大量错误包，出口丢包往往集中在特定时间段（高峰期）或者链路质量差的区域，判断方法很简单：用同一台电脑先ping网关再ping公网IP，如果网关丢包但公网不丢，大概率是内网；反过来则是出口问题。
丢包率正常范围是多少，ping测试丢几包算异常？
ping测试丢0%当然最好，但实际环境中偶发一两个包并不影响业务，比如ping 100个包丢1个，丢包率1%，对于网页浏览毫无感知，但对于视频会议可能就有卡顿，行业内一般把连续测试1000个包丢包率低于0.1%视为正常，如果你ping100个包丢了超过3个，就需要警惕，按上面的流程开始排查，值得注意的是公网测试目标的选择会影响结果，建议选两个运营商的DNS交替测试，避免单点误判。
内网ping正常，但下载文件总是中途失败，该怎么查？
这种情况属于典型的应用层丢包,隐蔽性强，先检查TCP重传率，如果重传率较高，说明数据包在传输过程中有丢失但被TCP机制重传了，所以ping测不出来，第二步检查网卡队列缓冲，在Windows下查看网卡高级属性里的接收缓冲区是否设置为最大值，Linux下用ethtool -g eth0查看，第三步检查交换机端口上的广播/组播流量，过大的广播包会占满小包缓冲区，导致大包被随机丢弃，最后一招是临时关闭防火墙的深度包检测功能，因为这类安全策略会重组数据包，处理不过来时直接丢弃，按这个顺序排查，多数情况下能找到根因。