Recarregar em vez de reiniciar
Um recarregamento indica ao NGINX que deve voltar a ler a configuração. Inicia novos processos de trabalho e permite que os antigos concluam os pedidos em aberto, pelo que os visitantes normalmente não notam nada. Se não for possível aplicar a nova configuração, o NGINX continua a funcionar com a antiga. Um reinício começa por parar o serviço, interrompendo as ligações, e pode não conseguir voltar a iniciá-lo se a configuração estiver errada.
Faça uma cópia de segurança do ficheiro que vai alterar
Antes de editar, crie uma cópia junto do ficheiro, com a data no nome. Não deixe cópias num diretório que o NGINX carregue com um padrão de caracteres universais, como conf.d/*.conf ou sites-enabled/*, pois também as carregaria. Em Debian e Ubuntu, edite o ficheiro em sites-available; a entrada em sites-enabled é normalmente apenas uma ligação para esse ficheiro.
sudo cp -a /etc/nginx/sites-available/example.conf /root/example.conf.$(date +%Y%m%d-%H%M%S)Teste e só depois recarregue
nginx -t verifica a sintaxe e os ficheiros referidos na configuração, como os certificados. Use nginx -T para ver a configuração completa após a inclusão de outros ficheiros. Recarregue apenas se o teste for bem-sucedido; ligar os comandos com && garante esse comportamento. O teste não consegue determinar se a configuração faz o que pretendia, por isso abra o site depois.
sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | less
curl -I https://example.com/Quando algo corre mal
Restaure a cópia de segurança, volte a testar e recarregue. Se o serviço tiver parado, o registo de erros e o journal indicam o motivo. Procure mensagens sobre uma porta já em utilização, um certificado em falta ou um nome de servidor duplicado.
sudo cp -a /root/example.conf.20261031-120000 /etc/nginx/sites-available/example.conf
sudo nginx -t && sudo systemctl reload nginx
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.logO que um recarregamento não abrange
As ligações de longa duração, como WebSockets, permanecem nos processos de trabalho antigos até terminarem, pelo que estes podem continuar ativos durante algum tempo e consumir memória adicional. Uma atualização do pacote pode reiniciar o serviço por si só. Teste primeiro as alterações maiores num servidor de teste, incluindo certificados e redirecionamentos.
NGINX Manager no CH-J Server Manager
O NGINX Manager edita ficheiros de configuração nos diretórios NGINX geridos em servidores Linux, até 512 KiB por ficheiro. Ao guardar, a aplicação cria uma cópia de segurança com o sufixo .chj-backup-, executa nginx -t e mantém a alteração apenas após um teste bem-sucedido. Um recarregamento exige a sua confirmação explícita e volta a executar o teste antes de começar. Uma ligação simbólica ativada não é substituída; edite o ficheiro correspondente em sites-available.