VPS 出问题时，最让人慌的不是网站 502，而是 SSH 完全进不去。比如你改错了 /etc/fstab，重启后系统卡在启动界面；或者防火墙规则写错，SSH 端口被自己挡住；再或者 root 密码忘了、GRUB 损坏、文件系统需要 fsck。这类问题用普通 SSH 排查不了，因为系统根本没正常起来。
这时候不要第一反应就重装。很多 VPS 控制台都有 Rescue Mode / 救援模式：它会从一个临时系统启动，把你原来的系统盘挂出来，让你站在“外部系统”的角度修复原系统。用得好，可以救回配置、重置密码、修复启动项，甚至把重要数据先拷出来。
救援模式不是你的原系统，也不是简单的网页终端。它通常是服务商提供的一个临时 Linux 环境，启动后会把原来的 VPS 磁盘当作数据盘呈现出来。
你可以把它理解成：
- 原系统坏了，先不从原系统启动。
- 服务商给你启动一个干净的小系统。
- 你在这个小系统里挂载原来的磁盘。
- 然后修改原系统里的文件、修复启动、拷贝数据。
它和 VNC/控制台也不一样。VNC 是看原系统屏幕；Rescue Mode 是换一个临时系统来修原盘。很多时候这两者要配合用：先用 VNC 看启动卡在哪里，再进救援模式修。
下面这些场景适合用 Rescue Mode：
| 场景 | 是否适合 |
|---|---|
| SSH 密码忘了，需要重置 root 密码 | 适合 |
/etc/fstab 写错，系统启动失败 | 适合 |
| GRUB / initramfs 异常，VPS 进不了系统 | 适合 |
| 文件系统损坏，需要离线 fsck | 适合 |
| 防火墙/SSH 配置写错，自己锁在外面 | 适合 |
| 网站 502、Nginx 配置错误 | 通常不需要，先普通 SSH 排查 |
| 磁盘满了但还能 SSH | 不一定需要，先在线清理 |
一个简单判断：如果原系统还能 SSH 进去，就优先在线排查；如果原系统进不去、启动不了、根分区不能安全修，就考虑救援模式。
第一，能做快照就先做快照。救援模式里会改原系统文件，一旦你误删或 fsck 操作不当，可能造成数据损失。
第二，先看控制台/VNC。确认系统是卡在启动、密码问题、防火墙问题，还是文件系统问题。不要一上来就乱跑 fsck。
如果是疑似入侵事件，先保留证据：不要立刻重启，不要清日志，尽量先做快照或磁盘镜像。救援模式会改变挂载状态和部分时间戳，取证场景要更谨慎。
不同服务商入口不一样，但名称通常类似：
- Rescue Mode
- Boot to rescue
- Recovery mode
- Rescue ISO
- VNC + ISO
启用后，VPS 会重启到临时系统。部分服务商会把临时 root 密码发到邮箱，部分会在控制台里显示登录信息。进入救援系统后，先看磁盘：
lsblk
fdisk -l
常见磁盘名包括：
/dev/vda/dev/sda/dev/nvme0n1
分区可能是 /dev/vda1、/dev/sda1、/dev/nvme0n1p1。不要照抄命令里的设备名，先用 lsblk 确认。
假设根分区是 /dev/vda1：
mkdir -p /mnt/sysroot
mount /dev/vda1 /mnt/sysroot
如果系统有单独的 /boot 分区，也要挂载：
mount /dev/vda2 /mnt/sysroot/boot
如果是 LVM，需要先激活卷组：
vgscan
vgchange -ay
lsblk
然后再挂载对应的逻辑卷。
挂载后先确认是不是原系统：
ls /mnt/sysroot
cat /mnt/sysroot/etc/os-release
如果能看到 etc、var、home、usr，基本就是原系统根目录。
很多修复操作需要在原系统环境里执行，这时要绑定几个系统目录：
mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys
mount --bind /run /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash
进入后，你看到的 / 就是原系统根目录。现在可以像登录原系统一样改配置。
在 chroot 里执行：
passwd root
如果系统禁用了 root SSH 登录，还要检查：
nano /etc/ssh/sshd_config
重点看：
PermitRootLogin
PasswordAuthentication
不要为了省事长期开启 root 密码登录。更稳妥的做法是重置后登录一次，重新配置密钥，再关闭密码登录。
如果你改错了 /etc/fstab，系统可能会卡在 emergency mode。进入 chroot 后检查：
nano /etc/fstab
临时排查时，可以先把可疑挂载行注释掉。尤其是新加的数据盘、网络盘、对象存储挂载、错误 UUID。
查看分区 UUID：
blkid
确认无误后再写回 fstab。不要把救援系统里的设备名当成永久配置，最好用 UUID。
fsck 一定要谨慎。原则是：不要对已经挂载的分区直接 fsck。
如果你已经挂载了根分区，先退出 chroot 并卸载：
exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot
然后再执行：
fsck -f /dev/vda1
如果确定要自动回答 yes：
fsck -fy /dev/vda1
但对重要数据盘，不建议一上来就 -y。先看报错，再决定是否自动修。
如果 VNC 里看到 grub rescue>、找不到内核、升级内核后启动失败，可以尝试重装 GRUB。
先重新挂载并进入 chroot：
mount /dev/vda1 /mnt/sysroot
mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys
mount --bind /run /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash
BIOS 启动的常见修复：
grub-install /dev/vda
update-grub
注意：grub-install 后面通常是磁盘 /dev/vda，不是分区 /dev/vda1。
如果是 UEFI 机器，路径和命令可能不同，需要确认 EFI 分区是否挂载到 /boot/efi。不确定时先看：
lsblk -f
findmnt /boot/efi
如果你改错了 SSH 端口、防火墙规则或 sshd_config，可以在 chroot 中修：
nano /etc/ssh/sshd_config
也可以先禁用危险的防火墙规则。比如 UFW：
ufw disable
如果用的是 iptables/nftables，救援环境里不一定能完整反映原系统运行状态。更可靠的做法是修改原系统的规则文件或启动脚本，而不是只看当前临时环境。
修完后不要直接在面板点重启，先按顺序退出和卸载：
exit
umount /mnt/sysroot/run
umount /mnt/sysroot/sys
umount /mnt/sysroot/proc
umount /mnt/sysroot/dev
umount /mnt/sysroot/boot 2>/dev/null
umount /mnt/sysroot
如果提示 busy，先查谁占用：
lsof +f -- /mnt/sysroot
确认卸载完成后，到服务商面板关闭 Rescue Mode，切回硬盘启动，再重启 VPS。
启动后第一时间检查：
systemctl --failed
journalctl -b -p warning
ss -lntp
确认 SSH、网站、数据库都正常，再删临时弱密码、恢复防火墙、安全组和备份计划。
你的机器可能是 /dev/vda1，也可能是 /dev/sda1 或 /dev/nvme0n1p1。永远先看 lsblk。
这是最危险的误操作之一。要么先卸载，要么确认该分区没被挂载。
修完后如果不切回硬盘启动，下一次还是进救援系统，看起来像“没修好”。
救急可以，长期不建议。恢复后应重新配置 SSH 密钥、关闭密码登录、限制登录来源。
救援模式不是万能药，但它是 VPS 用户必须会的最后一道保险。它最适合处理三类问题：启动失败、自己锁在外面、原系统文件需要离线修复。
真正稳妥的流程是：先看控制台判断问题，再做快照，进入 Rescue Mode，挂载原系统，必要时 chroot，修完后正确卸载并切回硬盘启动。只要你不盲目 fsck -y、不乱删文件，大多数“SSH 进不去只能重装”的场景，其实都还有救。