高延迟但traceroute某跳回落，大概率是中间设备禁用ICMP而非链路故障；应优先用hping3发TCP SYN验证真实业务延迟，再排查内核收包队列、TIME-WAIT堆积或网卡ring buffer不足等问题。
ping 高延迟但 traceroute 某跳就回落，大概率是中间设备策略限制
很多人看到 ping 延迟高、丢包，第一反应是“网络差”，但真实情况常是 ICMP 被上游防火墙、运营商设备或云厂商安全组静默丢弃。这不是链路问题，而是协议层拦截。
- 用
hping3 -c 10 -S -p 80 目标IP发 TCP SYN 包，比 ping 更贴近真实业务流量；若延迟正常，说明 ICMP 被限，不用调系统参数 -
traceroute -n -w 2 -q 1 目标IP中如果某跳显示 * * * 但下跳又恢复，基本可判定该节点禁 ICMP —— 这不是故障，是配置 - 别急着改
/proc/sys/net/ipv4/icmp_echo_ignore_all，本机设这个没用，它只控制本机是否响应 ping，不解决外网丢包
内核接收队列溢出（RX queue dropped）导致的“隐形延迟”
延迟突然升高且伴随间歇性丢包，netstat -s | grep "packet receive errors" 或 cat /proc/net/snmp | grep -A1 Tcp 显示大量 TCPRcvQDrop，说明数据包到了网卡却卡在内核收包队列里没被及时取走。
- 典型诱因：软中断（softirq）集中在单个 CPU 核处理，而应用没及时调用
recv()或工作线程阻塞 - 检查命令：
cat /proc/interrupts | grep eth0看各 CPU 上网络中断分布；若只有 CPU0 高，说明 RSS/RPS 未启用或配置失效 - 临时修复：
echo f > /proc/irq/*/smp_affinity_list（绑定到所有核），但长期应配ethtool -L eth0 combined 4+ 启用 RPS
TIME-WAIT 连接堆积引发端口耗尽与连接失败
不是所有高延迟都来自 RTT，有时是客户端发不出新连接——ss -tan state time-wait | wc -l 超过 2~3 万，再看 ss -s 的 orphan 数量飙升，说明连接无法快速释放，新请求排队等待端口。
-
net.ipv4.tcp_tw_reuse = 1是安全的，但仅对客户端有效（需时间戳开启）；服务端请勿依赖它来缓解高并发短连接 -
net.ipv4.tcp_fin_timeout = 30可缩短 FIN_WAIT_2 时间，但不能低于 30 秒，否则可能丢 ACK - 禁用
tcp_tw_recycle：Linux 4.12+ 已移除，旧内核开启后在 NAT 环境下会导致大量连接被拒绝（时间戳反向校验失败）
驱动或 ring buffer 不足引发的底层丢包
Wireshark 抓包发现大量 “TCP Retransmission” 但服务器 netstat -s 却没报错？很可能丢包发生在网卡 DMA 层——数据还没进内核就被硬件丢弃了。
- 查丢包位置：
ethtool -S eth0 | grep -i "drop\|over\|error"，重点关注rx_missed_errors（ring buffer 溢出）、rx_over_errors（DMA 缓冲区满） - 增大 ring buffer：
ethtool -G eth0 rx 4096 tx 4096（值需查网卡支持上限，如 Intel ixgbe 最大 4096） - 老旧驱动常见于 Realtek 或某些国产网卡，
lspci -k | grep -A3 Ethernet看 kernel driver 是否为r8169（建议换r8168）
真正卡住排查节奏的，往往不是参数没调对，而是把应用层慢（比如数据库查询 500ms）当成网络延迟去优化。先跑通 hping3 -S 和 tcpdump 确认协议栈是否干净，再动内核参数。
