VPS 重启后博客打不开、代理连不上，手动启动又一切正常——这种"重启就掉"的故障，十有八九出在自启配置上，而不是服务本身坏了。按顺序查五个地方，多数问题十分钟就能定位。
前置知识
本文面向已在 VPS 上跑服务（博客、代理、面板）的读者，需能 SSH 登录、会用基本命令。文中以 systemd 为例，它是 Debian、Ubuntu 等主流发行版默认的服务管理器。
先说一个最容易混淆的概念：start 和 enable 是两回事。start 是"现在启动一次"，重启后失效；enable 是"开机自动启动"。服务能手动跑起来、重启后却没起来，第一怀疑对象就是：当初只 start 了，没 enable。
第一步：查自启开关开了没有
systemctl is-enabled 你的服务名返回 enabled 表示开机自启已开；返回 disabled 就是病根，补上即可：
systemctl enable 你的服务名第二步：看日志，找它到底为什么没起来
如果自启开了、服务还是没起来，别急着改配置，先看它启动时报了什么错：
journalctl -u 你的服务名 --since "1 hour ago" --no-pager刚重启过的机器可以把时间范围换成 --since boot，只看本次开机以来的日志。常见报错一眼就能认出来：配置文件路径写错、端口被别的进程占了、启动命令里写了相对路径、依赖的目录或数据盘还没挂载。先把报错原文记下来再改配置，比凭感觉改一通快得多。
第三步：查启动时机，是不是跑得太早了
有些服务自启开了、配置也没错，但开机时还是起不来，手动启动却正常——这通常是启动时机问题：服务启动时，它依赖的东西还没就绪。典型情况有两种：
- 依赖网络，但网络还没通。 在服务配置的
[Unit]段加After=network-online.target，并配上Wants=network-online.target，等网络就绪再启动。 - 依赖其他服务或挂载点。 比如服务要读另一块数据盘上的文件，开机时盘还没挂载，服务就退出了。在
[Unit]段加After=挂载点对应的 mount 单元，或用Requires=声明依赖。
改完配置要重载并重启验证：
systemctl daemon-reload
systemctl restart 你的服务名第四步：查启动命令本身有没有坑
服务配置里的启动命令有几个常见坑，手动启动时不容易暴露：
| 现象 | 可能原因 | 查法 |
|---|---|---|
| 手动能跑，自启就退出 | 启动命令用了相对路径 | 检查 ExecStart 是否写了绝对路径 |
| 一启动就报找不到文件 | 工作目录不对 | 检查 WorkingDirectory 是否指向程序所在目录 |
| 需要环境变量，启动后读不到 | 变量只写在了当前 shell 里 | 用 EnvironmentFile 或 Environment 写进服务配置 |
| 退出码非零、反复重启 | 程序本身启动失败 | 看 journalctl 报错原文，不要只调重启策略 |
另外注意 Type 的选择：程序一直在前台运行时用默认的 Type=simple；程序启动后自己转入后台时才用 Type=forking，选错了 systemd 会误判服务已退出，进而反复拉起或直接放弃。
第五步：给服务加一道保险，再实测一次
定位并修好后，别只验证"现在能跑"，要验证"重启后还能跑"。给服务加上失败自动重启，是防止偶发失败的好习惯：
# 在服务配置的 [Service] 段加入
Restart=on-failure
RestartSec=5意思是失败后 5 秒重试一次。加完重载配置，然后做一次真正的重启验证：
systemctl daemon-reload
reboot重启后重新登录，跑 systemctl is-active 你的服务名 确认是 active。只有这一步通过了才算真正修好——"手动启动正常"不算，"重启后自动起来"才算。
结尾：一张排查顺序表
下次再遇到"重启后服务没起来"，按这个顺序查，别跳步：自启开关（is-enabled）→ 当前状态（status）→ 启动日志（journalctl）→ 启动时机（After 依赖）→ 启动命令（路径、工作目录、环境变量）。查到哪一步问题现形，就在哪一步停手修好，最后用一次真实重启验证收尾。