Checklist pré-deploy de Nginx no AlmaLinux 9 antes de ir ao ar

12 min de leitura  ·  Guia técnico

Checklist pré-deploy de Nginx no AlmaLinux 9 é a sequência de verificações técnicas que garantem que o servidor web está configurado, seguro e otimizado antes de receber tráfego real. Para validar seu Nginx antes do go-live, siga estes passos:

1. Valide a sintaxe com nginx -t e confira a versão instalada.
2. Ajuste worker_processes, worker_connections e limites de sistema.
3. Configure SSL/TLS com protocolos modernos e ciphers seguros.
4. Adicione headers de segurança (HSTS, X-Frame-Options, CSP).
5. Habilite gzip/brotli, cache e logs estruturados.
6. Verifique SELinux, firewalld e portas abertas.
7. Execute teste de carga e valide resposta HTTP antes de apontar o DNS.

Pré-requisitos antes de iniciar o checklist

• Servidor com AlmaLinux 9 atualizado (dnf update -y).
• Acesso root ou usuário com privilégios sudo.
• Nginx 1.26 ou superior instalado via repositório oficial (dnf install nginx).
• Domínio apontado ou registro A de teste já propagado.
• Certificado SSL válido (Let's Encrypt via certbot, ou comercial).
• Firewalld ativo e conhecimento básico de SELinux em modo enforcing.
• Backup da configuração atual em /etc/nginx/.

Validação de sintaxe e estrutura da configuração do Nginx

A primeira etapa do checklist pré-deploy de Nginx é garantir que nenhum erro sintático vá para produção. Um único ponto e vírgula faltante em um bloco server pode derrubar todos os sites hospedados no mesmo processo. Rode sempre o teste antes de recarregar o serviço:

sudo nginx -t

Output esperado:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Confira também a organização dos arquivos. No AlmaLinux 9, o padrão é manter virtual hosts em /etc/nginx/conf.d/ com um arquivo .conf por domínio. Evite blocos server duplicados, principalmente o default_server escutando na porta 443, pois ele causa conflito silencioso.

Valide também a versão em execução para confirmar que você está em uma build estável e recente:

nginx -V 2>&1 | head -n 3

Procure por módulos essenciais como --with-http_ssl_module, --with-http_v2_module e --with-http_gzip_static_module. Se algum módulo necessário estiver ausente, será preciso trocar o pacote pelo repositório oficial do Nginx em vez do AppStream do AlmaLinux.

Ajuste de workers, conexões e limites do sistema

O tuning de processos influencia diretamente a capacidade de atender requisições concorrentes. No bloco principal de /etc/nginx/nginx.conf, configure:

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

O valor auto em worker_processes faz o Nginx detectar o número de vCPUs disponíveis. Já worker_connections define quantas conexões simultâneas cada worker aceita — multiplicando ambos, você tem o teto teórico de conexões. Para um VPS com 4 vCPUs e 4096 conexões por worker, o limite chega a 16.384 conexões simultâneas.

Complemente no sistema operacional aumentando o limite de descritores de arquivo:

echo "nginx soft nofile 65535" | sudo tee -a /etc/security/limits.conf
echo "nginx hard nofile 65535" | sudo tee -a /etc/security/limits.conf

Crie também um override do systemd, pois o AlmaLinux 9 ignora limits.conf para serviços gerenciados pelo systemd:

sudo mkdir -p /etc/systemd/system/nginx.service.d
sudo tee /etc/systemd/system/nginx.service.d/limits.conf <<EOF
[Service]
LimitNOFILE=65535
EOF
sudo systemctl daemon-reload

Configuração de SSL/TLS e headers de segurança no Nginx

Nenhum deploy moderno vai ao ar sem HTTPS. O checklist exige ciphers robustos, desabilitar protocolos antigos e habilitar HSTS. Dentro do bloco server SSL, aplique:

listen 443 ssl;
http2 on;

ssl_certificate     /etc/letsencrypt/live/seudominio.com.br/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/seudominio.com.br/privkey.pem;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Depois do reload, valide com openssl:

openssl s_client -connect seudominio.com.br:443 -tls1_3 < /dev/null 2>&1 | grep -E "Protocol|Cipher"

Se você ainda não fez o redirecionamento de HTTP para HTTPS, consulte Como redirecionar um site http para https? para complementar esta etapa. Para análise externa, rode um scan em securityheaders.com e ssllabs.com — a meta é nota A ou A+ antes do deploy.

Permissões, SELinux e firewalld no AlmaLinux 9

O AlmaLinux 9 mantém SELinux em modo enforcing por padrão, e desabilitá-lo é um erro grave de segurança. Em vez disso, ajuste os booleans necessários. Se o Nginx atua como proxy reverso para backends (PHP-FPM, Node, Gunicorn), libere:

sudo setsebool -P httpd_can_network_connect 1
sudo setsebool -P httpd_can_network_relay 1

Para servir arquivos fora de /usr/share/nginx/html, aplique o contexto correto:

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/seusite(/.*)?"
sudo restorecon -Rv /var/www/seusite

Atenção: executar chmod -R 777 no diretório web é perigoso e facilita escalação de privilégios. Mantenha arquivos como 644 e diretórios como 755, com proprietário nginx:nginx.

No firewalld, libere apenas as portas necessárias:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Confirme quais processos escutam nas portas públicas:

sudo ss -tlnp | grep -E ":80|:443"

Gzip, cache e logs estruturados para performance

Compressão reduz banda e melhora TTFB. Habilite o gzip no contexto http:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss image/svg+xml;

Para cache de assets estáticos, adicione no bloco server:

location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}

Separe logs por site para facilitar auditoria e troubleshooting:

access_log /var/log/nginx/seusite-access.log;
error_log  /var/log/nginx/seusite-error.log warn;

Garanta que o logrotate está ativo em /etc/logrotate.d/nginx para não encher o disco. Monitore em tempo real durante o deploy com tail -f /var/log/nginx/seusite-error.log.

Teste de carga e validação final antes do go-live

Antes de apontar o DNS definitivo, simule tráfego realista. Instale o ab (Apache Benchmark) ou wrk:

sudo dnf install httpd-tools -y
ab -n 5000 -c 100 https://seudominio.com.br/

Output esperado (resumido):
Requests per second:    812.44 [#/sec] (mean)
Time per request:       123.087 [ms] (mean)
Failed requests:        0

Cheque os headers retornados em produção:

curl -I https://seudominio.com.br/

Procure por HTTP/2 200, presença de strict-transport-security e ausência de Server: nginx/1.x.x detalhado (mascarar com server_tokens off; no contexto http). Para topologias com cache e proteção adicional, o artigo Dicas de Otimização de Servidores Linux traz ajustes complementares de kernel e TCP que fazem diferença sob carga elevada.

Problemas comuns e como resolver

Sintoma: Nginx falha ao iniciar após alterar configuração SSL

Causa: caminho incorreto do certificado, permissões restritivas ou chave privada com senha.
Solução: rode sudo nginx -t para ver o erro exato, confira com ls -l se o usuário nginx consegue ler o arquivo e verifique journalctl -u nginx -n 50. Se a chave estiver criptografada, remova a senha com openssl rsa -in privkey.pem -out privkey.pem.

Sintoma: Erro 502 Bad Gateway ao conectar ao PHP-FPM ou backend

Causa: SELinux bloqueando a conexão, socket inexistente ou backend fora do ar.
Solução: aplique setsebool -P httpd_can_network_connect 1, confira systemctl status php-fpm e o caminho do socket em fastcgi_pass. Veja detalhes em /var/log/nginx/error.log — mensagens como "Permission denied" indicam SELinux; "Connection refused" indicam backend parado.

Sintoma: Too many open files nos logs sob carga

Causa: limite de descritores de arquivo do systemd abaixo do número de conexões simultâneas.
Solução: crie o drop-in em /etc/systemd/system/nginx.service.d/limits.conf com LimitNOFILE=65535, rode systemctl daemon-reload e reinicie o Nginx. Valide com cat /proc/$(pidof nginx | awk '{print $1}')/limits.

Sintoma: Site carrega por HTTP mas retorna erro SSL no HTTPS

Causa: porta 443 bloqueada no firewalld, certificado expirado ou vhost SSL sem listen 443 ssl.
Solução: valide com firewall-cmd --list-all, renove o certificado com certbot renew --dry-run e confira o bloco server SSL. Teste externamente com curl -vI https://seudominio.com.br.

Perguntas frequentes sobre checklist pré-deploy de Nginx

Quais os itens mínimos de um checklist pré-deploy do Nginx?

O mínimo inclui validação da sintaxe com nginx -t, ajuste do worker_processes e worker_connections, ativação de gzip, configuração de SSL/TLS com protocolos seguros, headers de segurança como HSTS e X-Frame-Options, e teste de carga básico. Também é essencial conferir logs de erro e permissões do diretório web antes de liberar tráfego.

Como testar se o Nginx está pronto para produção no AlmaLinux 9?

Execute nginx -t para validar a sintaxe, use curl -I no domínio para conferir headers de resposta, rode ss -tlnp para verificar que as portas 80 e 443 estão escutando, e teste o certificado com openssl s_client. Complemente com uma ferramenta de carga como ab ou wrk para simular tráfego real antes do go-live.

Qual o valor ideal de worker_processes e worker_connections no Nginx?

Defina worker_processes como auto para o Nginx detectar automaticamente o número de núcleos disponíveis. Para worker_connections, comece com 1024 e aumente para 4096 ou 8192 em servidores com mais RAM e tráfego elevado, lembrando de ajustar também o ulimit do sistema para não limitar as conexões.

Preciso desabilitar o SELinux para rodar Nginx no AlmaLinux 9?

Não, o recomendado é manter o SELinux em modo enforcing e ajustar os booleans corretos como httpd_can_network_connect quando o Nginx precisar conectar a backends. Desabilitar o SELinux reduz a segurança do servidor e não é necessário para a maioria dos cenários de produção.

Como configurar headers de segurança no Nginx antes do deploy?

Adicione no bloco server as diretivas add_header Strict-Transport-Security, add_header X-Content-Type-Options nosniff, add_header X-Frame-Options SAMEORIGIN e add_header Referrer-Policy strict-origin-when-cross-origin. Esses headers protegem contra MITM, clickjacking e sniffing de conteúdo, e são verificáveis via curl -I ou ferramentas como securityheaders.com.

Conclusão

• Sempre rode nginx -t e valide logs antes de qualquer systemctl reload nginx em produção.
• Combine tuning de workers com ajuste de LimitNOFILE no systemd — sem isso, o tuning do Nginx não surte efeito.
• Mantenha SELinux ativo, use HTTPS com TLS 1.2/1.3 e meça tudo com teste de carga antes de apontar o DNS definitivo.

Leia também

• Entenda o Deploy de Node.js no Debian 12 com PM2
• Guia Definitivo: Configurar Nginx como Proxy Reverso
• Gzip e Brotli no Nginx: ative, compare e economize banda

Precisa de ajuda com deploy de Nginx em produção?

Se você está preparando um ambiente crítico e quer um VPS pronto para rodar Nginx no AlmaLinux 9 com performance, snapshots e suporte técnico em português, a AviraHost oferece planos otimizados para aplicações web de qualquer porte.

Conheça os planos de VPS da AviraHost