SSH、curl或应用连接远端地址时出现 No route to host，并不一定代表服务器彻底断网。这个错误说明当前连接没有找到可用路径，或途中设备明确返回主机不可达，也可能来自本机防火墙的拒绝规则。
先别急着重启网络或删除路由。最重要的是确认错误发生在域名解析、路由选择、网关邻居、端口访问还是云平台网络层。
先确认目标地址和失败范围
先绕开应用，直接核对目标域名解析结果和端口连通性：
getent ahosts example.com
ping -c 3 203.0.113.20
nc -vz -w 5 203.0.113.20 22域名无法解析时应先处理DNS；IP能ping通而端口失败，更应检查服务监听、防火墙或安全组。多个目标都报错时，再把重点放到本机接口和默认路由。
查看网卡、地址和链路状态
读取接口摘要与详细链路状态：
ip -br link
ip -br address
ip -s link业务网卡应处于 UP，并拥有与云平台配置一致的地址和前缀。不要看到接口名称变化就直接修改配置文件，先用 ip route get 确认内核实际选择的是哪张网卡。
用ip route get还原内核选路
Linux的 ip route get 会按照当前路由表解析指定目标，并显示下一跳、出口接口与源地址：
ip route get 203.0.113.20
ip route show
ip -6 route show若命令直接返回 Network is unreachable，重点检查默认路由和目标网段路由。若结果选错出口接口或源地址，应继续查看策略路由，而不是临时添加多条重复默认路由。
检查网关邻居和策略路由
先从路由结果中找到网关，再检查邻居表与策略规则：
ip neigh show
ip rule show
ip route show table all邻居状态长期停在 FAILED 或 INCOMPLETE，说明主机无法在二层找到下一跳。多网卡、VPN、容器网络或源地址策略也可能把流量导向错误表。不要执行 ip route flush table main 这类整表清空命令，远程服务器可能立刻失联。
区分本机防火墙和云平台规则
查看主机规则时，优先使用当前系统实际启用的工具：
sudo nft list ruleset
sudo iptables -S
sudo ufw status verbose拒绝规则既可能返回不可达，也可能直接丢包。云服务器还要核对安全组、子网路由、弹性网卡绑定和网络ACL。云平台控制台显示的私网地址、网关和实例网卡必须与系统侧保持一致。
做最小修复并保留回滚路径
配置缺失时，可先在控制台或备用会话中保留救援入口，再根据发行版的网络管理方式修正持久配置。临时验证路由可使用：
sudo ip route replace default via 192.0.2.1 dev eth0上面的网关、接口必须换成实际值。远程操作前先确认控制台可用，错误默认路由可能中断当前SSH连接。 需要在隔离VPS复现网络配置时，可以使用 萤光云 或 LightNode 建立测试环境，不要把生产私钥和真实防火墙白名单复制过去。
修复后怎样验收
重新执行路由解析、网关连通和目标端口测试：
ip route get 203.0.113.20
ping -c 3 192.0.2.1
nc -vz -w 5 203.0.113.20 22验收标准是出口接口、下一跳和源地址符合设计，目标端口连续可达，重启网络或服务器后配置仍然存在，而不是某一次ping偶然成功。
FAQ
能ping通却仍提示No route to host是什么原因？ ICMP与业务端口可能经过不同过滤规则，主机或中间防火墙也可能对TCP连接返回不可达，需要结合端口测试和防火墙计数判断。
重启服务器能修好吗？ 重启可能重新获取DHCP和默认路由，但也会清掉临时配置。没有确认根因前重启，只会让问题暂时消失或扩大恢复难度。
温馨提示
远程修改路由前保存 ip address、ip route 和 ip rule 输出，并准备云控制台。每次只改一个变量，验证成功后再写入持久配置。
