路由延迟突然增大通常不是路由表错误，而是数据包在某段路径被卡住、丢弃或重传；排查重点是验证真实路径每跳表现（如mtr持续探测）、确认路由执行是否异常（ip route get）、检查内核转发瓶颈（RcvQDrop、rp_filter）、排除上游策略干扰（ICMP/UDP对比），而非仅看路由表是否存在。
路由延迟突然增大，通常不是路由表本身出错，而是数据包在某段路径上被卡住、丢弃或反复重传。排查重点不在“路由是否存在”，而在“路由是否被正确执行”以及“中间节点是否对流量做了策略干预”。
先确认是否真由路由路径导致
单纯看路由表（ip route show 或 route -n）只能知道下一跳和出口设备，无法反映实际转发质量。必须验证真实路径上的每一段表现：
- 用 mtr -n -c 60 目标地址 持续探测，重点关注哪一跳开始出现丢包率上升或 RTT 明显跳变（比如从 5ms 突增至 120ms 且持续）
- 对比 traceroute -n 目标地址 和 hping3 -S -p 80 目标地址 的结果：若 traceroute 某跳超时但 hping3 的 SYN 包能通，说明该跳禁 ICMP，不是路由问题，是策略拦截
- 如果 mtr 中间某跳显示 ??? 或 * * *，但下跳恢复，大概率是该设备关闭了 ICMP 响应，不等于链路故障
检查本地路由决策是否异常
系统可能选了非预期的出口，尤其在多网卡、策略路由或默认网关漂移场景下：
- 运行 ip route get 目标IP，确认实际使用的源地址、出接口和网关是否符合预期
- 检查是否有冲突或冗余路由：ip route show table all | grep -v "unreachable\|blackhole"
- 查看策略路由规则：ip rule show，确认没有误配的 from/to 规则把业务流量导向低带宽或高延迟链路
- 若使用 BGP 或动态路由协议（如 FRR/Quagga），检查邻居状态：vtysh -c "show ip bgp summary"
排查路由相关内核行为异常
即使路由表正确，内核也可能因资源瓶颈或配置问题导致转发延迟升高：
- 检查软中断是否集中在单个 CPU：watch -n1 'cat /proc/interrupts | grep eth0'，若只有 CPU0 的网络中断飙升，说明 RSS/RPS 未生效，包处理串行化
- 确认接收队列是否溢出：netstat -s | grep "packet receive errors" 或 cat /proc/net/snmp | grep -A1 Tcp | grep TCPRcvQDrop，有大量 RcvQDrop 表示应用没及时收包，包在内核队列中排队
- 检查反向路径过滤（rp_filter）是否误启：sysctl net.ipv4.conf.all.rp_filter，设为 2（宽松模式）可避免因多路径回包不匹配被丢弃
排除上游路由策略干扰
很多“路由延迟增大”实为运营商或云厂商在骨干网侧做了限速、QoS 标记或安全策略：
- 用 mtr -I 目标地址（强制 ICMP）和 mtr --udp 目标地址 对比：若 UDP 模式大量丢包而 ICMP 正常，说明中间设备对 UDP 探测包做了限速或过滤
- 抓包确认是否出现异常 TTL 或 IP 头字段：tcpdump -i any 'host 目标IP and icmp' -c 20，观察是否有 TTL 异常减小、DF 标志异常等迹象
- 联系网络上游（IDC 运营商、云平台支持）提供 mtr 报告，要求核查对应跳点设备的端口缓存、ACL 策略或拥塞状况
