路由表配置错误是导致服务器无法访问外网或跨网段通信失败的常见原因，需优先检查默认路由是否存在且正确，再验证网关可达性及实际转发路径是否符合预期。
路由表配置错误是导致服务器无法访问外网或跨网段通信失败的常见原因。它不像硬件断连那样直观，但影响直接——数据包根本发不出去，或被错发到错误路径。排查关键在于“确认系统是否知道怎么把包送出去”，而不是盲目查服务或DNS。
看默认路由是否存在且正确
这是最基础也最关键的一步。没有有效的默认路由（default route），服务器就无法访问任何非本地网段的地址。
- 执行 ip route show | grep default，检查输出是否类似：
default via 192.168.1.1 dev eth0 - 若无输出，说明默认路由缺失；若网关IP明显不属于你所在子网（比如服务器IP是10.0.2.10，却指向192.168.1.1），就是配置错误。
- 临时修复可运行：
sudo ip route add default via [正确网关IP] dev [对应网卡名]
验证路由走向是否符合预期
即使有默认路由，也可能因多条规则冲突、策略路由或错误静态路由，导致流量绕行或丢弃。
- 用 ip route get 8.8.8.8 模拟发往外网的数据包，查看实际选择的出口和下一跳。
输出应显示 via + 网关 + dev + 网卡，且网关必须可达。 - 若返回 Network is unreachable 或指向了错误接口（如 tun0、docker0），说明路由逻辑异常。
- 检查是否有冗余或冲突的静态路由：
ip route show table all | grep -v "local\|broadcast"，重点识别重复目标、低优先级覆盖、或误配的 0.0.0.0/0 条目。
结合网关连通性交叉验证
路由表再“看起来正确”，如果网关本身不可达，一切仍是空谈。
- 先 ping 默认网关 IP（如 ping -c 4 192.168.1.1）。不通，说明链路层或网关设备问题，不是纯路由配置问题。
- 若网关能通，但 ip route get 8.8.8.8 显示 via 该网关，而 ping 8.8.8.8 不通，则问题大概率出在网关之后（如NAT网关未启用、云平台安全组拦截、上游路由缺失）。
- 此时需同步检查 NAT 网关状态（云环境）、防火墙 FORWARD 链策略、以及网关设备自身的路由表。
留意云环境特有陷阱
公有云（如阿里云、腾讯云、AWS）中，路由表常由控制台统一管理，与本地命令看到的不完全一致。
- Linux 命令看到的路由只是“实例内核路由”，真正生效还需云平台路由表（VPC Route Table）允许该流量流出。
- 务必登录云控制台，检查关联子网的路由表中，是否有指向 Internet 网关（IGW）或 NAT 网关的有效条目（目标 0.0.0.0/0 → IGW/NAT）。
- 常见错误：VPC 路由表被误删、NAT 网关状态为 “pending” 或 “failed”、ECS 实例未绑定弹性公网IP（EIP）却期望直连公网。
