network-unreachable

本地路由表找不到目标网段，连接直接返回 network is unreachable 的定位与修复

现象

客户端报 connect: network is unreachable、Network is unreachable 或 ENETUNREACH，curl 显示 Failed to connect ... Network is unreachable，Go 程序可能看到 dial tcp [<ipv6>]:443: connect: network is unreachable。这表示本地内核在选路阶段就没有找到可用的路由，数据包通常根本没有发出。

它与 no route to host 不同：后者是已经选好出口，但无法把包交付到具体主机；network is unreachable 更接近“本机不知道去这个网段该走哪”。最常见的两种场景是默认路由缺失，以及应用尝试走 IPv6 但主机或容器没有 IPv6 默认路由。排查顺序应始终从本机地址和路由表开始，而不是先怀疑远端服务。

快速定位

先确认地址、默认路由和实际选路结果：

ip -br addr
ip route show default
ip -6 route show default
ip route get <ipv4>
ip route get <ipv6>
ip rule show
ip route show table all | head -60
ping -c 3 <ipv4>
ping -6 -c 3 <ipv6>
curl -4 -v --max-time 5 https://<host>/
curl -6 -v --max-time 5 https://<host>/
traceroute -n <ipv4>
resolvectl status
nmcli connection show --active
networkctl status

容器或 Kubernetes 场景进入同一网络命名空间对比：

kubectl exec <pod> -n <ns> -- ip route
kubectl exec <pod> -n <ns> -- ip -6 route
kubectl exec <pod> -n <ns> -- ip -br addr
kubectl exec <pod> -n <ns> -- cat /etc/resolv.conf

ip route get 直接报 Network is unreachable，说明主路由表没有匹配项；如果命令有结果但应用仍失败，检查策略路由 ip rule 是否把流量导向了空表，以及应用是否绑定了错误的源地址或地址族。IPv4 正常、IPv6 失败时，用 curl -4 和 curl -6 分别验证，确认是协议族问题还是目标地址问题。

检查转发和 NAT：

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S | grep -E 'MASQUERADE|SNAT'
sudo nft list ruleset | grep -E 'masquerade|snat'

常见根因

1. 默认路由缺失：DHCP 未下发网关、网络重启后路由被删或手工配置漏写 default via。
2. 接口没有地址、接口 down 或地址配置在错误的网卡上，内核无法选出源地址。
3. 应用或客户端优先使用 IPv6，但主机没有全局 IPv6 地址、RA 未提供默认路由或 IPv6 被部分禁用。
4. DNS 返回了 AAAA 记录，但当前网络没有 IPv6 出口，连接在选路阶段失败。
5. 容器网络命名空间缺少默认路由，网桥、veth 或 CNI 插件配置异常。
6. Pod 所在节点没有开启 IP 转发，或缺少到外网的 NAT 规则。
7. 策略路由把流量送到没有默认路由的路由表，常见于 VPN、kill switch 或多网卡环境。
8. VPN 断线后路由被清理，或 split tunnel 的 AllowedIPs 没有包含目标网段。
9. 云主机位于私有子网，路由表没有指向 NAT 网关或目标网段的路由。
10. 子网掩码配置错误，目标被判断为不同网段，但又没有默认网关。
11. NetworkManager、systemd-networkd 或 netplan 应用了错误配置，重启后覆盖临时路由。
12. 目标地址是保留地址、链路本地地址或不属于当前网络的地址，内核拒绝选路。

修复

• 用 ip route get 确认内核是否选路成功，以及选中的接口、源地址和网关是否符合预期。
• 默认路由缺失时，先确认 DHCP 或 RA 是否正常，再通过 nmcli、netplan 或 systemd-networkd 持久化配置，而不是只执行临时 ip route add。
• 接口无地址或 down 时修复链路和地址配置，确认地址属于目标网段且没有冲突。
• IPv6 场景检查全局地址、RA 接受状态和 IPv6 默认路由；需要时在路由器或云网络侧补齐 IPv6 出口。
• 应用层可临时优先 IPv4 验证问题，但长期应修复 IPv6 路由或清理错误的 AAAA 记录，不要把禁用 IPv6 当作唯一方案。
• 容器场景对比宿主机与 Pod 的路由，修复 CNI、网桥、veth 和默认网关；检查节点 ip_forward 与 NAT 规则。
• 策略路由场景用 ip rule 和所有路由表逐条核对，修正 VPN kill switch、多网卡和源地址选择规则。
• 云环境检查子网关联的路由表、NAT 网关和安全组，确认私有地址到公网的路径完整。
• 修正错误的子网掩码，确保同网段判断和网关选择正确。
• 修改网络配置后验证默认路由在重启、网卡热插拔和 VPN 切换后仍然存在。
• 监控默认路由是否存在、网关是否可达以及 ENETUNREACH 错误率，按主机和地址族告警。
• 不要用添加一条错误静态路由的方式掩盖 DHCP 或 CNI 故障，否则问题会在下次重启后复发。

相关命令

• no-route-to-host — 有路由但无法交付到主机
• ipv6-connectivity — IPv6 地址、RA 与连通性
• dns-resolution-failed — AAAA 记录与解析问题
• connection-timeout — 有路由但连接超时
• arp-conflict — 同网段地址冲突
• ip — 地址、路由、策略路由与邻居
• ping — 验证网关和目标可达性
• traceroute — 检查路径与首跳
• nmcli — 持久化网络配置
• networkctl — systemd-networkd 状态
• resolvectl — DNS 与地址族解析结果

参考链接

• RFC 1122: 主机需求
• RFC 4291: IPv6 地址架构
• RFC 6724: 默认地址选择
• Linux ip-route(8) 手册

读完自测

合上页面，先回答，再展开对照。

1. network is unreachable 说明数据包已经到达远端了吗？
2. IPv4 访问正常、IPv6 地址却报 network is unreachable，应检查什么？
3. Pod 内访问外网报 network is unreachable，而宿主机正常，排查重点是什么？