Not being able to access things after a reboot isn't necessarily the same problem.

So the first step isn't to guess—SSH in and look at the real status.

systemctl status nginx
systemctl status docker
systemctl status mysql
systemctl status redis

If your system uses PostgreSQL or MariaDB, the service name may be:

systemctl status postgresql
systemctl status mariadb

If you're not sure of the service name, you can search for it:

systemctl list-units --type=service | grep -i nginx
systemctl list-units --type=service | grep -i mysql

Many people only do this step when deploying a service for the first time:

systemctl start nginx

This only means "start now," not "start on next boot."

The correct approach is:

systemctl enable nginx
systemctl enable docker
systemctl enable mysql

To confirm it was set successfully:

systemctl is-enabled nginx
systemctl is-enabled docker
systemctl is-enabled mysql

Only when you see enabled does it mean it will start with the system.

If the output is disabled, that explains it: everything works fine after you manually start it, but once the VPS reboots, it won't come back on its own.

I now do a quick check after deploying a service:

systemctl is-enabled nginx docker mysql

It's simple, but it saves you a lot of trouble.

If systemctl status shows failed, it's not simply a missing autostart setting.

In that case, don't just look at the last line—look at the full log:

journalctl -u nginx -b --no-pager
journalctl -u docker -b --no-pager
journalctl -u mysql -b --no-pager

The -b here is very useful: it only shows logs since this boot, so old errors from long ago don't get mixed in.

nginx -t

systemctl restart nginx
systemctl status nginx

df -h
journalctl -u mysql -b --no-pager
ls -ld /var/lib/mysql

journalctl -u postgresql -b --no-pager
systemctl status postgresql

Docker is another trouble spot.

Many people start containers with docker run without adding a restart policy. The container runs fine at the moment, but after a VPS reboot it won't come back automatically.

First check container status:

docker ps -a

Then check a specific container's restart policy:

docker inspect 容器名 --format '{{.HostConfig.RestartPolicy.Name}}'

If the output is no, it won't restart automatically.

Common fix:

docker update --restart unless-stopped 容器名

If you use Docker Compose, add this in compose.yml:

services:
  app:
    image: your-image
    restart: unless-stopped

Then restart:

docker compose up -d

Here I'd recommend unless-stopped rather than blindly using always. Because a container you stopped manually is usually one you don't want sneaking back up on its own.

This is also very common.

systemctl status nginx showing active doesn't mean the website is necessarily reachable. You also need to check whether the port is listening:

ss -lntp

Focus on:

• :80
• :443
• The application's own port, such as :3000, :8000, :8080

If Nginx is up but the backend application isn't, you may get a 502 when accessing it.

In that case, check in order:

systemctl status nginx
systemctl status your-app
ss -lntp
curl -I http://127.0.0.1

If it's reachable locally but not from the internet, check the firewall:

ufw status
iptables -S

Cloud providers also have a security group layer—don't forget it. Many people have everything configured correctly inside the machine, but the security group in the console doesn't allow 80/443, and they waste a lot of time troubleshooting.

Some services start fine manually but fail on automatic boot because they start too early.

For example:

• The application starts before the database
• Nginx starts before the certificate mount directory
• The disk that a Docker container depends on isn't mounted yet
• The network isn't fully ready, but the service has already started connecting to external APIs

With this kind of problem, you can usually see errors like "connection failed," "directory does not exist," or "port unavailable" in journalctl.

systemd services can add dependencies, for example:

[Unit]
After=network-online.target mysql.service
Wants=network-online.target

After changing the unit file, run:

systemctl daemon-reload
systemctl restart your-service

If you use Docker Compose, you can use depends_on, but note: depends_on only guarantees startup order, not that the database is fully ready. The truly rigorous approach is for the application itself to support connection retries.

If this VPS runs a production website, I usually do a manual drill.

First confirm all services are set to autostart:

systemctl is-enabled nginx docker mysql

Then reboot:

reboot

Wait 1-2 minutes, log back in, and check:

systemctl --failed
systemctl status nginx docker mysql
ss -lntp
curl -I https://你的域名

If it's a Docker project, also check:

docker ps

This check isn't complicated, but it's very useful. Because when something really goes wrong, you may not happen to be online.

Next time services don't recover after a VPS reboot, you can follow this order:

1. systemctl status 服务名: confirm whether it's inactive, failed, or active
2. systemctl is-enabled 服务名: check whether it starts on boot
3. journalctl -u 服务名 -b --no-pager: look at this boot's logs
4. systemctl --failed: list all failed services
5. ss -lntp: confirm whether the port is listening
6. docker ps -a: if using Docker, check whether containers came up
7. df -h: for database and log-related issues, check the disk first
8. curl -I http://127.0.0.1: distinguish between local service issues and external access issues

Don't reinstall the system right away, and don't just click reboot in the panel. Many problems are really just a missing enable or a wrong service startup order.

The habit worth building is: after deployment, proactively do a reboot drill.

A VPS that can survive a manual reboot is more likely to survive uncontrollable situations like late-night provider maintenance, kernel upgrades, and host migrations.