VPS重启后网站打不开？按启动顺序查服务、挂载、容器和反向代理

VPS重启后网站打不开，先不要反复重启整台机器。SSH能连接只说明操作系统和部分网络正常，网站请求还要经过DNS、公网端口、反向代理、应用、数据库与数据盘。最有效的排查方法，是记下本次启动时间，沿请求路径确认每一层是否真的就绪。

先界定故障范围

从一台独立客户端记录域名解析结果、HTTP状态码和准确时间。再在VPS本机分别访问反向代理与应用监听端口。如果本机应用可访问而公网不行，重点查监听地址、安全组、防火墙和反向代理；如果本机应用也失败，继续查服务、容器和依赖。

uptime
who -b
systemctl --failed
ss -lntup
curl -I http://127.0.0.1

端口排查的完整分层可参考VPS端口不通的检查顺序。这里重点处理“重启前正常、重启后失效”这一时间边界。

服务运行不等于已设置开机自启

systemctl status显示当前进程状态，systemctl is-enabled才用于核对是否配置为随系统启动。应用可能一直由管理员手动启动，所以平时正常，一重启就消失。检查反向代理、数据库、应用服务与Docker守护进程，不要只看其中一个。

systemctl is-enabled nginx
systemctl status nginx --no-pager
journalctl -b -u nginx --no-pager

journalctl -b把日志限定到本次启动，能避免旧错误干扰判断。若服务启动失败，先处理第一条有因果意义的错误，不要用连续重启把日志刷满。

数据盘可能还没挂载

网站目录、数据库或容器卷如果位于独立数据盘，挂载失败后，服务可能看到一个空目录并启动，甚至在根分区重新写出一套“新数据”。先比较findmnt、lsblk -f与/etc/fstab，确认设备标识、挂载点、文件系统和权限。

不要看到目录为空就立刻恢复备份或复制数据。应先确认真实数据盘是否仍在、是否只读、是否因设备名变化而未挂载。优先使用稳定的UUID或平台推荐标识，并为依赖该挂载的服务建立正确的systemd依赖。

Docker要查守护进程和容器两层

Docker服务开机启动，不代表每个容器都会恢复。运行docker ps -a查看容器是否退出，再检查重启策略与本次启动日志。always、unless-stopped与on-failure语义不同，不能只为了自动启动统一改成同一个值。

systemctl status docker --no-pager
docker ps -a
docker inspect -f '{{.HostConfig.RestartPolicy.Name}}' CONTAINER
docker logs --since 30m CONTAINER

即使容器自动启动，数据库可能尚未接受连接，应用就先失败退出。Compose中的启动顺序也不等于依赖已经健康。应给数据库和应用配置健康检查、合理的重试与明确的失败日志。容器部署、数据卷和回滚的基础设计可参照Docker Compose建站与回滚教程。

反向代理可能比上游更早启动

Nginx或其他反向代理已经监听80/443，但上游应用尚未就绪时，客户端可能看到502或504。先从错误日志确认是连接被拒绝、名称解析失败还是读取超时；再直接请求上游地址。若上游用容器名称或内部DNS，确认重启后网络与服务名仍一致。

不要把所有启动期502都通过无限重试掩盖。更稳妥的设计是让依赖有健康信号、应用失败时可控重启，监控在宽限期后再告警。若故障表现为504，可结合Nginx连接与读取超时排查重建请求时间线。

数据库“启动了”也可能不可用

数据库可能正在崩溃恢复、等待磁盘、拒绝远程地址，或因数据目录未挂载而启动失败。查看本次启动日志、监听地址、磁盘空间和应用连接错误。不要在没有备份与恢复方案时直接删除锁文件、重建数据目录或执行破坏性修复。

如果应用依赖环境变量、密钥文件或网络存储，还要确认systemd服务与交互式Shell是否使用了同一环境。手动启动成功、开机启动失败，经常是工作目录、用户、PATH、权限或环境文件不同。

防火墙与公网地址也要复核

部分本机防火墙规则、策略路由或临时命令不会自动持久化；平台侧公网IP在某些变更后也可能不同。比较当前公网地址、DNS解析、安全组与主机防火墙。不要为了快速恢复把管理端口和数据库端口对全网开放。

一条低风险恢复顺序

1. 保存本次启动日志、HTTP错误和配置版本，不先清理现场；
2. 确认磁盘与挂载，避免服务写入错误目录；
3. 恢复数据库和必要依赖，等待健康检查通过；
4. 恢复应用并在本机直接访问其监听端口；
5. 恢复反向代理，验证本机域名与TLS；
6. 核对防火墙、安全组、DNS和公网访问；
7. 从外部客户端完成登录、读取和一项无破坏性的关键路径验证。

若某一步需要修改配置，先保存原文件并一次只改一个变量。这样恢复失败时能回退，也能确认真正原因。

修好以后做一次受控重启演练

在维护窗口执行计划内重启，记录各服务从开机到健康的时间。演练至少检查挂载完成、数据库可连接、容器状态、反向代理上游、证书加载、监控告警和备份任务。若只能靠人工SSH后运行一串命令，说明恢复流程还没有真正自动化。

结论

VPS重启后网站打不开，通常不是单一“端口问题”，而是启动状态与依赖顺序发生了变化。以本次开机日志为时间线，先确认挂载，再恢复数据库、应用和反向代理，最后检查公网路径；修复后通过受控重启证明配置能自动恢复，才算完成。