关键不是多试命令，而是分层定位：从本地网卡→中间路径→对端服务逐段排除；丢包多因设备错误、策略拦截或缓冲区溢出，延迟高则倾向路由绕行、带宽打满或CPU处理滞后。
服务器维护中排查网络丢包与延迟过高，关键不是“多试几个命令”，而是按链路分层定位：从本地网卡→中间路径→对端服务，逐段排除。丢包和高延迟常共存，但成因不同——丢包多由设备错误、策略拦截或缓冲区溢出引起；延迟高则更倾向路由绕行、带宽打满或CPU处理滞后。
一、先确认是否真丢包，还是ICMP被限速
很多“ping丢包”其实是防火墙或云平台主动限速ICMP响应，不代表真实业务流量异常：
- 用 tcping 或 curl -w "@curl-format.txt" -o /dev/null -s http://目标IP 测试TCP端口连通性，对比ICMP结果
- 检查云厂商安全组/ACL是否显式放行ICMP协议（阿里云、腾讯云默认不放行）
- 在服务器上执行 iptables -L -nv | grep icmp，看是否有INPUT链DROP规则
- 若仅ping丢包但HTTP/SSH正常，大概率是ICMP策略限制，无需深挖物理链路
二、查服务器本机：网卡、驱动与内核瓶颈
丢包常始于服务器自身，尤其高并发或大包场景下：
- 运行 ethtool -S eth0 | grep -i "error\|drop\|fifo"，重点看 rx_fifo_errors（Ring Buffer溢出）、tx_aborted_errors（发送中断失败）
- 检查双工模式：ethtool eth0 | grep Duplex，确保服务器与交换机均为Full，避免协商失败导致冲突
- 查看软中断分布：cat /proc/interrupts | grep eth0，若某CPU核心中断远高于其他，说明网卡中断绑定不均，可手动绑定优化
- 用 dropwatch -l kas 实时监控内核在哪一层丢包（如netdev、ip_rcv、tcp_v4_do_rcv），直接定位协议栈环节
三、盯住中间路径：用MTR锁定问题跳点
单纯ping或traceroute容易误判，MTR能暴露每跳的丢包率和抖动：
- 执行 mtr --report-cycles=50 -r --no-dns 目标IP，输出中重点关注：
— 某跳丢包率突然升高（如从0%跳到15%），该节点即嫌疑点
— 延迟在某跳后持续攀升且抖动（mdev值大），说明该节点拥塞或QoS限速
— 前两跳就丢包，大概率是宿主机、虚拟交换机或物理网卡问题 - 若丢包集中在运营商骨干网（如AS4837、AS4134），属公网链路质量波动，需联系ISP或切换BGP线路
- 对比早晚高峰丢包变化：若仅晚高峰丢包，优先查带宽是否跑满（iftop -P 或云监控带宽图）
四、验证业务真实影响，避开“假症状”
ping丢包≠业务不可用，延迟高≠服务卡死，必须结合应用层表现交叉验证：
- 用 ss -ti 查看TCP连接的retransmits字段，>0说明已触发重传，证实丢包影响了业务流
- 抓包分析：tcpdump -i eth0 'tcp port 80 and host 目标IP' -w app.pcap，Wireshark里看“TCP Retransmission”和“TCP Out-Of-Order”比例
- 检查应用日志中的超时错误（如MySQL “Lost connection”，Nginx “upstream timed out”），确认是否与丢包时段吻合
- 若HTTP延迟高但无丢包，可能是服务端处理慢（查CPU、磁盘IO、数据库锁），而非网络问题
不复杂但容易忽略：多数丢包问题其实藏在最前面两步——ICMP策略误判和本机网卡配置错位。把这两关过了，再往链路上追，效率会高很多。
