Tutoriais de VPS
O que fazer quando os serviços da VPS não voltam após reiniciar (2026): diagnóstico de systemd, Docker, Nginx e inicialização automática de bancos de dados
Após reiniciar a VPS, o site, os contêineres Docker, o Nginx ou o MySQL não sobem: não se apresse em reinstalar o sistema. Verifique na ordem systemd, enable, logs, portas e dependências; normalmente dá para localizar o problema rápido.
O que fazer quando os serviços da VPS não voltam após reiniciar (2026): diagnóstico de systemd, Docker, Nginx e inicialização automática de bancos de dados
Já vi muitas falhas de VPS que não eram "o serviço caiu", mas sim que os serviços simplesmente não subiram automaticamente depois que a máquina reiniciou.
Os cenários mais comuns são estes:
- O provedor fez manutenção e a VPS foi reiniciada uma vez
- Você mesmo atualizou o kernel e executou
rebootsem pensar - A máquina travou e você clicou em reinício forçado no painel
- Entre Docker, Nginx, MySQL, Redis e outros, sempre tem um que não volta
Se você ainda está na frente do computador, tudo bem: entra por SSH e executa manualmente systemctl start nginx para recuperar. O problema é um reinício automático de madrugada e você só descobrir no dia seguinte que o site ficou fora do ar a noite toda.
Este artigo segue a minha própria ordem de diagnóstico: primeiro confirmar se o serviço está no ar, depois ver se está configurado para iniciar no boot e, por fim, descobrir por que a inicialização automática falhou.
Não conseguir acessar depois de um reinício não significa necessariamente o mesmo problema.
| Sintoma | Problema mais provável |
|---|---|
systemctl status mostra inactive | O serviço não está configurado para iniciar no boot, ou foi desabilitado |
| Mostra failed | O serviço tentou iniciar, mas falhou |
| O serviço está active, mas o site não abre | Problema de porta, firewall, configuração do Nginx ou serviço upstream |
| Os contêineres Docker não subiram | A restart policy do contêiner não foi configurada, ou o próprio Docker não subiu |
| O banco de dados não subiu | Erro de configuração, disco cheio, problema de permissão, saída anormal da última vez |
Então o primeiro passo não é adivinhar: entre por SSH e veja o estado real.
systemctl status nginx
systemctl status docker
systemctl status mysql
systemctl status redis
Se o seu sistema usa PostgreSQL ou MariaDB, o nome do serviço pode ser:
systemctl status postgresql
systemctl status mariadb
Se não tiver certeza do nome do serviço, pode pesquisar:
systemctl list-units --type=service | grep -i nginx
systemctl list-units --type=service | grep -i mysql
Muita gente só faz este passo ao implantar um serviço pela primeira vez:
systemctl start nginx
Isso significa apenas "iniciar agora", não "iniciar no próximo boot".
A forma correta é:
systemctl enable nginx
systemctl enable docker
systemctl enable mysql
Para confirmar se foi configurado com sucesso:
systemctl is-enabled nginx
systemctl is-enabled docker
systemctl is-enabled mysql
Só quando você vê enabled é que significa que ele vai iniciar junto com o sistema.
Se a saída for disabled, isso explica tudo: funciona normalmente depois que você inicia manualmente, mas, assim que a VPS reinicia, ele não volta sozinho.
Agora eu faço uma verificação rápida depois de implantar um serviço:
systemctl is-enabled nginx docker mysql
É simples, mas evita muita dor de cabeça.
Se em systemctl status você vê failed, não é apenas falta de configuração de inicialização automática.
Nesse caso, não olhe só a última linha: veja o log completo:
journalctl -u nginx -b --no-pager
journalctl -u docker -b --no-pager
journalctl -u mysql -b --no-pager
O -b aqui é muito útil: ele mostra apenas os logs desde este boot, sem misturar erros antigos.
Primeiro teste a configuração:
nginx -t
Se houver problema, normalmente ele diz exatamente qual linha está errada. Por exemplo:
- Falta um ponto e vírgula
server_nameno lugar errado- O caminho do certificado não existe
- O endereço upstream do proxy reverso está errado
Depois de corrigir, execute:
systemctl restart nginx
systemctl status nginx
Quando o MySQL / MariaDB não sobe após reiniciar, eu normalmente verifico primeiro isto:
df -h
journalctl -u mysql -b --no-pager
ls -ld /var/lib/mysql
Se o disco estiver cheio, o banco de dados pode falhar facilmente ao iniciar. Já passei por isso uma vez: o problema real não era a configuração do MySQL, mas os logs enchendo o disco, e o banco não conseguia nem gravar arquivos temporários.
No PostgreSQL, você pode verificar:
journalctl -u postgresql -b --no-pager
systemctl status postgresql
Não se apresse em reinstalar só porque o banco de dados não sobe: primeiro encontre o primeiro erro claro no log.
Docker é outro ponto crítico.
Muita gente inicia contêineres com docker run sem adicionar uma política de reinício. O contêiner funciona naquele momento, mas, após reiniciar a VPS, não volta automaticamente.
Primeiro veja o status dos contêineres:
docker ps -a
Depois veja a política de reinício de um contêiner específico:
docker inspect 容器名 --format '{{.HostConfig.RestartPolicy.Name}}'
Se a saída for no, ele não vai reiniciar automaticamente.
Correção comum:
docker update --restart unless-stopped 容器名
Se você usa Docker Compose, adicione isto em compose.yml:
services:
app:
image: your-image
restart: unless-stopped
Depois reinicie:
docker compose up -d
Aqui eu recomendo mais unless-stopped do que usar always sem pensar. Porque um contêiner que você parou manualmente geralmente é um que você não quer que volte sozinho às escondidas.
Isso também é muito comum.
systemctl status nginx mostrar active não significa que o site necessariamente esteja acessível. Você também precisa ver se a porta está escutando:
ss -lntp
Preste atenção em:
:80:443- A porta da própria aplicação, como
:3000,:8000,:8080
Se o Nginx está no ar, mas a aplicação backend não subiu, ao acessar pode aparecer um 502.
Nesse caso, verifique na ordem:
systemctl status nginx
systemctl status your-app
ss -lntp
curl -I http://127.0.0.1
Se funciona localmente mas não pela internet, verifique o firewall:
ufw status
iptables -S
O provedor de nuvem também tem uma camada de security group; não esqueça. Muita gente tem tudo configurado corretamente dentro da máquina, mas o security group do painel não libera 80/443, e perde muito tempo diagnosticando.
Alguns serviços iniciam bem manualmente, mas falham na inicialização automática porque sobem cedo demais.
Por exemplo:
- A aplicação inicia antes do banco de dados
- O Nginx inicia antes do diretório onde o certificado é montado
- O disco do qual o contêiner Docker depende ainda não foi montado
- A rede ainda não está totalmente pronta e o serviço já começou a conectar a APIs externas
Nesse tipo de problema, normalmente dá para ver erros como "connection failed", "directory does not exist" ou "port unavailable" em journalctl.
Serviços systemd podem adicionar dependências, por exemplo:
[Unit]
After=network-online.target mysql.service
Wants=network-online.target
Depois de alterar o arquivo unit, execute:
systemctl daemon-reload
systemctl restart your-service
Se você usa Docker Compose, pode usar depends_on, mas atenção: depends_on só garante a ordem de inicialização, não que o banco de dados esteja totalmente pronto. A forma realmente rigorosa é a própria aplicação suportar novas tentativas de conexão.
Se esta VPS roda um site em produção, eu normalmente faço um simulado manual.
Primeiro confirmo que todos os serviços estão configurados para iniciar no boot:
systemctl is-enabled nginx docker mysql
Depois reinicio:
reboot
Espero 1-2 minutos, entro novamente e verifico:
systemctl --failed
systemctl status nginx docker mysql
ss -lntp
curl -I https://你的域名
Se for um projeto Docker, também verifico:
docker ps
Essa verificação não é complicada, mas é muito útil. Porque, quando algo realmente dá errado, pode ser que você não esteja online naquele momento.
Na próxima vez que os serviços não se recuperarem após reiniciar a VPS, você pode seguir esta ordem:
systemctl status 服务名: confirmar se está inactive, failed ou activesystemctl is-enabled 服务名: ver se inicia no bootjournalctl -u 服务名 -b --no-pager: olhar os logs deste bootsystemctl --failed: listar todos os serviços com falhass -lntp: confirmar se a porta está escutandodocker ps -a: se usar Docker, ver se os contêineres subiramdf -h: para problemas de banco de dados e logs, verifique primeiro o discocurl -I http://127.0.0.1: distinguir entre problema do serviço local e problema de acesso pela internet
Não reinstale o sistema de imediato, nem apenas clique em reiniciar no painel. Muitos problemas são, na verdade, só um enable faltando ou uma ordem de inicialização errada de algum serviço.
O hábito que vale a pena cultivar é: depois da implantação, faça um simulado de reinício de forma proativa.
Uma VPS que aguenta um reinício manual tem mais chance de aguentar situações imprevisíveis como manutenção noturna do provedor, atualizações de kernel e migrações de host.