Como forçar redirect HTTPS da porta 80 para 443 no Nginx

Quando um servidor web aceita conexões em HTTP (porta 80) e HTTPS (porta 443) simultaneamente, o tráfego não criptografado continua viável — qualquer cliente que digite o domínio sem prefixo, clique em link antigo ou siga bookmark http:// vai bater na porta 80 e trafegar credenciais em texto plano. A correção é forçar redirect permanente 301 da porta 80 pra porta 443 no Nginx, garantindo que toda requisição seja terminada em TLS.

Este tutorial mostra a configuração correta de redirect HTTP → HTTPS no Nginx, incluindo o tratamento do desafio http-01 do Let’s Encrypt (que precisa de HTTP puro pra validar), ativação progressiva de HSTS e validação da configuração antes do reload. Aplica-se a Nginx 1.18+ em qualquer distribuição Linux (Ubuntu, Debian, Rocky, Alma).

Tempo de execução: cerca de 10 minutos, incluindo testes. Persona-alvo: developer ou sysadmin com Nginx já configurado servindo o site nas duas portas, que precisa consolidar tudo em HTTPS sem quebrar renovação de certificado.

Pré-requisitos

Antes de mexer no Nginx, faça backup da configuração atual. Um erro de sintaxe num server block deixa o serviço sem subir até você corrigir, e mexer em produção sem rede de segurança é convite pra downtime.

sudo cp -r /etc/nginx /etc/nginx.bak.$(date +%Y%m%d)

O comando duplica todo o diretório com timestamp — se algo der errado, basta reverter com sudo rm -rf /etc/nginx && sudo mv /etc/nginx.bak.YYYYMMDD /etc/nginx.

Estrutura recomendada: dois server blocks

A abordagem correta separa o redirect HTTP em um server block próprio, deixando o HTTPS num segundo block. Isso evita lógica condicional (if ($scheme = http)) que o autor do Nginx desencoraja explicitamente — o if dentro de location em Nginx tem comportamento contra-intuitivo e historicamente foi fonte de bugs.

sudo nano /etc/nginx/sites-available/seudominio.com

# Server block HTTP — redirect 301 pra HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name seudominio.com www.seudominio.com;

    # Mantém o desafio do Let's Encrypt funcionando
    location ^~ /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
        default_type "text/plain";
        allow all;
    }

    # Redirect catch-all pra HTTPS
    location / {
        return 301 https://$host$request_uri;
    }
}

# Server block HTTPS — termina TLS e serve o site
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name seudominio.com www.seudominio.com;

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

    # HSTS — comece com 300s, suba depois de validar
    add_header Strict-Transport-Security "max-age=300" always;

    root /var/www/seudominio.com;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
sudo chown -R www-data:www-data /var/www/letsencrypt
sudo chmod -R 755 /var/www/letsencrypt

sudo nginx -t

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

sudo systemctl reload nginx

Verificação

Confirme que o redirect está ativo testando via curl sem abrir navegador (cache de browser pode mascarar problemas):

curl -I http://seudominio.com

A resposta deve mostrar:

HTTP/1.1 301 Moved Permanently
Server: nginx
Location: https://seudominio.com/

Para confirmar que o destino HTTPS responde corretamente, use -L pra seguir o redirect:

curl -IL http://seudominio.com

Você verá duas respostas: primeiro o 301 do Nginx, depois o 200 OK do HTTPS. Se a segunda for 502, 503 ou outro erro, o problema não é o redirect — é o backend HTTPS.

Teste também o desafio ACME continua acessível em HTTP:

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
echo "teste-ok" | sudo tee /var/www/letsencrypt/.well-known/acme-challenge/teste
curl http://seudominio.com/.well-known/acme-challenge/teste

A resposta deve ser teste-ok em texto puro — não um redirect 301. Se vier redirect, a ordem dos location está errada.

Resolução de problemas

Loop de redirect infinito

Sintoma: navegador mostra erro “ERR_TOO_MANY_REDIRECTS”. Causa comum: a aplicação por trás do Nginx (PHP, Node) detecta $_SERVER['HTTPS'] como vazio e redireciona pra HTTPS de novo, mas o Nginx já redirecionou — ciclo infinito.

Solução: certifique-se que o server block HTTPS passa o header correto pro upstream:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

A aplicação deve confiar nesse header em vez de inspecionar $_SERVER['HTTPS'] direto.

HSTS travado em HTTPS quebrado

Por isso o template começa com max-age=300. Depois de uma semana validando que tudo funciona, suba pra max-age=31536000; includeSubDomains — esse é o valor pra produção estabilizada.

Renovação Let’s Encrypt falha com 301

Sintoma: certbot renew retorna erro “Failed authorization procedure” depois que você ativou o redirect. Causa: a diretiva location ^~ /.well-known/acme-challenge/ está abaixo do location / no arquivo, então o catch-all redireciona primeiro.

O modificador ^~ no template tem prioridade sobre location /, mas se você editou e perdeu o ^~, a ordem importa. Garanta que o location do ACME aparece antes do catch-all OU use ^~ que dá prioridade independente da ordem.

Próximos passos

Com HTTPS forçado e validação confirmada, aprofunde a segurança e performance do servidor:

• Hardening TLS: ajuste ssl_protocols TLSv1.2 TLSv1.3 e ssl_ciphers pra remover suítes legadas — use o gerador da Mozilla SSL Config como base.
• OCSP Stapling: ative ssl_stapling on pra reduzir latência de validação de certificado no primeiro request.
• HSTS preload: depois de 1 ano com max-age=31536000; includeSubDomains; preload, submeta o domínio em hstspreload.org pra entrar na lista de browsers.
• HTTP/3: Nginx 1.25+ suporta QUIC nativo — vale ativar pra clientes com latência alta.
• Logs separados: configure access_log específico do server block HTTPS pra facilitar análise de tráfego.

Se você está rodando esta config em produção, uma VPS Hostini já vem com Ubuntu/Debian otimizado e SSH endurecido — boa base pra subir Nginx com TLS sem tunar kernel manualmente.