路由不可达丢包本质是内核无合法路径发包,应先用route -n查destination(0.0.0.0为默认路由)、gateway(须在本地子网)、genmask(须匹配destination)、iface(出接口是否正确),再用ip route get验证真实选路,结合arp -n和ping检查网关可达性。

路由不可达导致的丢包,本质是内核找不到合法路径把包发出去。问题往往不出在“连不通”,而在于“发错了地方”或“根本没路可走”。排查要快准狠,从路由表本身开始,而不是一上来就 ping 或 traceroute。
先看 route -n,盯死四列关键字段
执行 route -n,重点检查:
- Destination:0.0.0.0 表示默认路由;具体网段如 10.0.5.0 要和你目标 IP 匹配;出现孤立主机路由(如 172.16.30.5/32)却无对应网段路由,大概率漏配
- Gateway:非 0.0.0.0 的网关 IP 必须落在某张网卡的子网内。例如本机 eth0 是 192.168.1.100/24,但 Gateway 显示 10.1.1.1 → 这个网关根本无法 ARP,所有跨网段包都会静默丢弃
- Genmask:必须与 Destination 逻辑一致。比如 Destination 是 172.16.20.0,Genmask 却是 255.255.0.0,那实际匹配的是 /16 网段,可能覆盖更精确的 /24 条目
- Iface:确认出接口是否是你预期的物理或虚拟网卡。若目标应走 eth1,但匹配到 eth0 的路由,包会从错误接口发出,下游设备不认、不回应
验证内核真实选路:用 ip route get 模拟转发
route -n 只是静态配置,ip route get 才告诉你系统真怎么走:
Linux 性能分析与调优专家,覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景:系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 执行 ip route get 10.0.5.8,看返回的 via、dev 和 src —— 如果 via 是 192.168.100.1 且 dev 是 eth0,但你本意是让流量走 eth1 上的 10.0.1.1 网关,说明路由表缺失或 metric 冲突
- 若返回 RTNETLINK answers: Network is unreachable,代表没有匹配路由,不是网关不通,而是压根没这条路
- 对比不同目标 IP 的结果:访问外网正常但内网不通?很可能内网网段路由被默认路由抢了优先级
查网关可达性:arp -n + ping 组合验证
有路由不等于能通,下一跳得能“喊到”:
- 执行 arp -n | grep
:若无输出,说明没完成 ARP 解析 → 检查网关 IP 是否真在本地子网、网卡是否 UP、物理链路是否连通 - 单独 ping -c 3
:能通才说明二层可达;若不通,再查 ethtool 看 Link detected 是否为 yes,或 ifconfig 看 RX/TX 错误计数是否上升 - 注意:有些网关(如部分防火墙或云厂商网关)禁 ping,但 arp 表存在 + ip route get 正常 + 应用层能通,就不用强求 ping 通
警惕隐藏干扰项:tc、iptables 和重复路由
路由表没问题,不代表包真能过去:
- 运行 tc qdisc show dev eth0:若看到 netem、fq_codel 等带 loss、delay 参数的规则,丢包可能来自流量控制模块,而非网络本身
- 执行 iptables -t mangle -L -v -n | grep -E "(DROP|REJECT)":mangle 表可修改路由决策(如 TPROXY、ROUTE),也可能直接丢包
- 用 ip route show table all | grep -E "via|dev" 查所有路由表:某些策略路由(policy routing)会把特定源 IP 流量导向非主表,容易遗漏










