新买的 RackNerd VPS，最让人着急的一类故障是：控制台里的 VNC 能登录，SSH 却连接不上，服务器里执行 ping 8.8.8.8 也没有回应。这个现象说明机器不一定宕机，VNC 只是绕过了公网网络入口；真正需要确认的是网卡、IP、默认路由、DNS、防火墙和服务状态。
本文给出一套从“先判断故障层级”到“恢复 SSH”的安全流程，适用于 RackNerd 以及大多数 KVM VPS。不要一上来就重装系统或盲目重启 NetworkManager，因为 Ubuntu、Debian、Rocky Linux 和 CentOS 的网络管理方式并不完全相同。
在本地电脑先做三项检查：
ping -c 4 你的VPS公网IP
nc -vz 你的VPS公网IP 22
ssh -vvv root@你的VPS公网IP
Ping 不通并不能单独证明服务器断网，很多 VPS 会过滤 ICMP。真正有判断价值的是 TCP 22 端口：
| 现象 | 更可能的原因 |
|---|---|
| 22 端口 connection refused | 服务器在线，但 sshd 没启动或没有监听 22 |
| 22 端口 timeout，VNC 正常 | 网卡、路由、防火墙或上游网络异常 |
| 22 端口能连，密码/密钥失败 | 用户、密钥、sshd 配置或 Fail2Ban 问题 |
| 只有域名连接失败，IP 可连 | DNS 记录或本地 DNS 缓存问题 |
如果同一台机器之前正常、刚改过 UFW、iptables、NetworkManager 或 netplan，优先从最近一次变更开始回滚检查。
登录服务商控制台的 VNC 或 Web Console，先查看内核和网络接口：
uname -a
ip -br link
ip -br address
ip route
正常情况下，主网卡（常见名称为 eth0、ens3 或 enp1s0）应为 UP，并有服务商分配的公网 IPv4。默认路由通常类似：
default via 203.0.113.1 dev eth0
203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.10
下面几种结果分别表示：
- 网卡是
DOWN：接口没有启用，或网络管理服务没有接管它； - 网卡是
UP但没有inet地址：DHCP、静态配置或云-init 配置有问题； - 有 IP 但没有
default路由：只能访问同网段，无法访问外网； - IP 和路由都正常但域名不通：继续检查 DNS，不要反复重启网卡。
确认物理接口名称后，再执行：
ip link set dev eth0 up
把 eth0 替换成 ip -br link 显示的实际名称。此命令只启用接口，不会替你猜测 IP 和网关。
不要只运行 ping google.com。按下面顺序测试，能快速定位故障在哪一层：
ip route get 1.1.1.1
ping -c 4 你的默认网关
ping -c 4 1.1.1.1
getent hosts google.com
resolvectl status 2>/dev/null || cat /etc/resolv.conf
- 默认网关都 Ping 不通：先修网卡、IP、路由或服务商侧网络；
- 网关可达、
1.1.1.1不通：检查默认路由、出口策略和 VPS 商家的网络状态； 1.1.1.1可达、域名不通：检查/etc/resolv.conf、systemd-resolved 或 DNS 防火墙规则；- 都正常但 SSH 不通：故障已经缩小到 sshd、22 端口防火墙或 Fail2Ban。
临时测试 DNS（只用于定位，不建议永久覆盖发行版的 DNS 管理）：
resolvectl query google.com 2>/dev/null || nslookup google.com
如果确实是解析服务故障，先查看当前配置，再按系统对应的方法修复。不要直接把 /etc/resolv.conf 改成普通文件后长期使用，因为它可能会被 netplan、NetworkManager 或 systemd-resolved 覆盖。
Ubuntu Server 常见网络管理器是 netplan 配合 systemd-networkd，桌面或部分镜像也可能使用 NetworkManager。先确认当前状态：
systemctl is-active systemd-networkd
systemctl is-active NetworkManager
networkctl status 2>/dev/null | head -n 30
ls -l /etc/netplan/
查看 netplan 配置，确认接口名、DHCP 和默认路由没有被改坏：
sudo sed -n '1,200p' /etc/netplan/*.yaml
修改前先备份，使用 netplan try 而不是直接 apply。netplan try 会在确认超时后自动回滚，适合通过 VNC 修复远程网络：
sudo cp -a /etc/netplan /etc/netplan.backup-$(date +%F-%H%M)
sudo netplan try
如果确认配置正确，再应用并检查路由：
sudo netplan apply
ip -br address
ip route
只有确认系统使用 NetworkManager 时，才执行：
sudo systemctl enable --now NetworkManager
nmcli device status
nmcli connection show
不要在 systemd-networkd 正常工作的 Ubuntu 镜像上强行启用 NetworkManager，两个服务同时接管同一接口可能产生路由和地址冲突。
Rocky Linux、AlmaLinux 和较新的 CentOS 通常由 NetworkManager 管理网络。先检查服务和连接：
systemctl status NetworkManager --no-pager
nmcli device status
nmcli connection show --active
如果 NetworkManager 确实未运行，并且系统没有其他网络服务接管接口，可执行：
sudo systemctl enable --now NetworkManager
nmcli device connect eth0
ip -br address
ip route
同样要把 eth0 换成真实接口名。若服务启动失败，先查看日志，不要连续重启：
sudo journalctl -u NetworkManager -b --no-pager -n 150
重点检查连接配置是否包含错误的静态 IP、网关、子网掩码或重复默认路由。RackNerd 控制台里显示的 IP、网关和掩码应以当前实例信息为准，不能照抄别人的教程参数。
如果网关和公网 IP 都能访问，但外部 TCP 22 超时，检查主机防火墙：
sudo ufw status verbose 2>/dev/null || true
sudo nft list ruleset
sudo iptables -S 2>/dev/null
sudo fail2ban-client status sshd 2>/dev/null || true
确认 SSH 端口在当前规则中被允许。不要为了“快速恢复”执行清空全部规则的命令；如果必须临时放行，应先保存现有规则并限制来源 IP。若是刚开启 UFW 后失联，可参考 开启 UFW 后 SSH 进不去的恢复清单。
如果只有自己的公网 IP 被封，查看 Fail2Ban 的封禁列表并针对单个地址解封：
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 你的公网IP
不要把 SSH 永久开放给全世界后就认为问题解决。恢复访问后，应使用密钥登录、限制管理来源、关闭密码登录，并保留 VNC 或 Rescue Mode 作为最后的自救入口。
网络恢复后，继续确认 SSH 服务本身：
sudo systemctl status ssh 2>/dev/null || sudo systemctl status sshd
sudo ss -lntp | grep -E ':(22|2222)'
sudo sshd -t
sshd -t 没有输出才表示语法检查通过。若你修改过 /etc/ssh/sshd_config，先修正语法，再重启服务：
sudo systemctl restart ssh 2>/dev/null || sudo systemctl restart sshd
sudo journalctl -u ssh -u sshd -b --no-pager -n 100
确认是否把端口改成了 2222 或其他端口，并同步检查云防火墙和本机防火墙。服务监听在 127.0.0.1 而不是 0.0.0.0 时，外部也无法连接。
如果网卡、路由、防火墙和 sshd 都正常，但 TCP 22 仍然超时：
- 在 RackNerd 控制台确认实例没有暂停、欠费或触发流量限制；
- 检查控制台显示的 IPv4 是否已更换，DNS 是否仍指向旧地址；
- 用 VNC 查看
dmesg -T和系统日志，确认没有磁盘满、内核错误或启动任务失败； - 使用 Rescue Mode 挂载系统盘，修复 netplan、sshd 或防火墙配置；
- 保留工单中的测试时间、源 IP、目标 IP、Traceroute 和端口测试结果，便于服务商定位上游问题。
基础诊断信息可以这样收集：
date -Is
ip -br address
ip route
ss -lntp
sudo journalctl -b --no-pager -p warning..alert | tail -n 100
需要深入处理 Rescue Mode、chroot 和文件系统检查时，可参考 VPS 救援模式怎么用。不要在不清楚磁盘设备的情况下运行 fsck 或格式化命令。
确认 SSH 恢复后，马上做一次最小化加固：
- 使用普通管理员 + sudo，避免长期直接使用 root 密码登录；
- 为管理员配置 SSH 密钥，测试新会话成功后再关闭密码登录；
- 保留一个已验证可用的 VNC 或救援入口；
- 记录 netplan / NetworkManager 配置、网关和防火墙变更；
- 设置磁盘、内存、网络和服务状态监控，避免故障只能靠用户发现。
VNC 能登录而 SSH、Ping 不通，通常不是“服务器完全死机”，而是公网网络链路中的某一层出了问题。正确顺序是：确认接口和公网 IP，再查默认路由，接着区分 DNS、主机防火墙和 sshd，最后才考虑服务商上游或 Rescue Mode。
最重要的一点是不要把 systemctl enable --now NetworkManager 当成万能命令。先识别发行版和当前网络管理器，再使用 netplan try、nmcli、nftables 或 systemd 日志进行针对性修复，才能降低二次断网风险。