Proxy reverso Nginx com SSL

Se você está executando um aplicativo da web em uma porta privada (como LocalHost: 3000), não é diretamente acessível pela Internet.Uma das maneiras mais eficazes de expor esse aplicativo com segurança é colocar um proxy reverso na frente dele.

O NGINX é uma ferramenta conhecida leve que pode fazer exatamente isso-recebe tráfego recebido e encaminhe-o para o seu aplicativo-enquanto também lida com HTTPS com um certificado SSL gratuito da Let's Encrypt.

Neste guia, você aprenderá como:

• Configure o nginx como um proxy reverso para um serviço da web interno
  
• Prenda -o com um certificado SSL usando o certbot
  
• Entenda cada parte da configuração para saber o que está fazendo e por quê

Novo em servidores da web?Confira nossa explicação sobre Como os servidores da web funcionam.

O que é um proxy reverso e por que usar um?

UMA proxy reverso é um servidor que fica entre seus usuários e seus serviços de back -end.Em vez de seu aplicativo ouvindo publicamente em uma porta (como 3000), o Nginx recebe o tráfego primeiro e depois o passa para o aplicativo em execução em segundo plano.

Eis por que essa abordagem é tão útil:

• Esconde portas e serviços internos
  Seu aplicativo não precisa ser exposto diretamente ao público.Isso reduz a superfície do ataque e ajuda a controlar o acesso.
  
• Lida com https para você
  Muitas estruturas da Web podem servir HTTPs diretamente, mas geralmente é mais fácil e confiável deixar o Nginx fazê -lo - especialmente ao usar certificados SSL gratuitos do Let's Encrypt.
  
• Ativa a hospedagem de vários serviços em um servidor
  Você pode executar vários aplicativos em portas diferentes (como 3000, 4000, 5000) e rotear o tráfego com base no domínio ou caminho usando apenas um IP público.
  
• Melhora a extração e o monitoramento
  O NGINX fornece logs de acesso e erros centralizados, por isso é mais fácil monitorar o desempenho ou investigar problemas.
  
• Fornece cache opcional, balanceamento de carga e limitação de taxa
  Você pode otimizar o fluxo de tráfego e proteger os serviços de back -end com apenas algumas linhas extras na sua configuração nginx.

Mesmo que seu aplicativo já possa lidar com o tráfego da Web, o uso do NGINX como proxy reverso geralmente simplifica a configuração, melhora a flexibilidade e aumenta o controle.

Pré-requisitos

Antes de começarmos, certifique -se de ter tudo o que precisa:

• Um VPS ou servidor em nuvem executando o Ubuntu 20.04 ou posterior: A maioria dos comandos e versões de pacotes usadas neste tutorial assume um sistema baseado em Debian.Embora o NGINX e o CERTBOT trabalhem em outras distribuições, o processo de configuração pode ser diferente.
• Acesso Root ou Sudo: Você estará instalando pacotes, editando arquivos do sistema e reiniciando serviços - todos os quais exigem privilégios elevados.
• Um nome de domínio registrado: Você precisará disso para solicitar um certificado SSL.Vamos criptografar valida a propriedade do seu domínio antes de emitir um certificado.Sem o DNS apontado para o seu servidor, a validação falhará.
• DNS apontando para o IP público do servidor: Verifique se os registros DNS do seu domínio estão atualizados.Um recorde simples apontando para o IP do servidor é suficiente:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

A propagação pode levar alguns minutos a algumas horas.

Não sabe como configurar seus DNs?Aqui está Como adicionar um registro com a maioria dos hosts de domínio.

• Um aplicativo em execução no host (por exemplo,,, por exemplo, http://localhost:3000): Este é o aplicativo para o qual você estará proxy.Pode ser qualquer coisa - node.js, frasco de python, rubi nos trilhos etc. Enquanto estiver ouvindo em uma porta local, você pode procurar.

Nota: Se o seu aplicativo ainda não estiver em execução, tudo bem - você ainda pode passar pela configuração e testar mais tarde.

• Nginx instalado: O NGINX atuará como o servidor público.Se ainda não estiver instalado:

sudo apt update
sudo apt install nginx

Então verifique se está em execução:

sudo systemctl status nginx

Você deve ver "ativo (em execução)".

• CERTBOT instalado com o plug -in nginx: O CERTBOT automatiza o processo de obtenção e renovação de certificados SSL da Let's Encrypt.Instale -o assim:

sudo apt install certbot python3-certbot-nginx

Este plug -in permite que o CERTBOT modifique sua configuração nginx automaticamente ao solicitar um certificado - nenhuma edição manual necessária para configurações básicas.

Tem outro sistema operacional?Siga este guia sobre Como instalar Let's Encrypt em Fedora e Debian

Etapa 1: Configure o proxy reverso nginx

Agora que seu sistema está pronto, a primeira etapa real é configurar o NGINX para ouvir o tráfego em seu domínio e encaminhá -lo para o seu aplicativo interno - é isso que faz com que o NGINX atue como um proxy reverso.

Por que isso importa

Sem essa configuração, os usuários que tentam visitar seu site atingiriam uma página vazia ou a tela de boas -vindas do NGINX padrão.Você precisa dizer explicitamente nginx:

• Quais domínios deve responder
  
• O que fazer com solicitações de entrada
  
• Onde enviar o tráfego nos bastidores

Crie um novo bloco de servidor

Você criará um arquivo de configuração para o seu domínio no diretório disponível sites da Nginx.Isso mantém as configurações organizadas e facilitam a ativação ou desativação de sites individuais.

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

Cole no bloco a seguir, ajustando o domínio e a porta do aplicativo conforme necessário:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        # Pass important headers to the backend
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

O que esta configuração faz

• Ouça 80;
  Diz ao Nginx para ouvir o tráfego HTTP na porta 80.
  
• server_name yourDomain.com www.yourdomain.com;
  Combina esse bloco com solicitações feitas ao seu domínio.Você pode adicionar ou remover subdomínios conforme necessário.
  
• localização /
  Pega todas as solicitações à raiz e as encaminha para o seu aplicativo.
  
• proxy_pass http: // localhost: 3000;
  Este é o coração do proxy reverso - ele envia a solicitação para o aplicativo de back -end em execução na porta 3000.
  
• linhas proxy_set_header
  Esses preservam os detalhes da solicitação original do cliente, como:
  
  • O endereço IP do usuário (X-real-ip)
    
  • O protocolo original (http ou https)
    
  • O nome do host original
    
• Essas informações são úteis para registro, análise ou quando seu aplicativo precisa gerar URLs que correspondam à experiência do visitante.

Ativar a configuração

Nginx usa links simbólicos no sites habilitados diretório para ativar sites.Então agora você criará um link e recarregue o nginx:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Verifique se há erros de sintaxe.Se tudo parecer bom:

sudo systemctl reload nginx

Seu proxy reverso está agora ao vivo - pedidos para http://yourdomain.com será passado para o seu aplicativo na porta 3000.

Etapa 2: Adicionar SSL com Let's Encrypt e CertBot

Com o proxy reverso trabalhando sobre o HTTP, a próxima etapa é prendê -lo com HTTPS.Isso adiciona criptografia a toda a comunicação entre seus usuários e seu servidor - protegendo credenciais de login, solicitações de API, dados pessoais e muito mais.

Você usará o Let's Encrypt, uma autoridade de certificação gratuita e o CERTBOT, que automatiza o processo.

Por que o HTTPS é importante

• Criptografa tráfego então ninguém pode interceptar ou adulterar com ele
  
• Melhora o SEO - Os mecanismos de pesquisa preferem sites seguros
  
• Constrói confiança - Os usuários esperam ver o ícone do cadeado
  
• Necessário para muitas APIs, logins e sistemas de pagamento

Solicitar o certificado

Execute este comando, substituindo os domínios por seus valores reais:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

O que isso faz:

• Diz ao CERTBOT para usar o plugin nginx
  
• Especifica quais domínios você está solicitando um certificado para

CertBot Will:

• Execute a validação do domínio criando um arquivo temporário em sua configuração nginx
  
• Contate Let's Encrypt para verificar a propriedade do domínio
  
• Baixe seu certificado SSL e chave privada
  
• Modifique sua configuração nginx para usar https
  
• Opcionalmente redirecionar todo o tráfego HTTP para HTTPS

Dica: Se o seu DNS não estiver totalmente propagado ou o seu servidor Firewall Blocks Port 80, a validação falhará.Você pode testar isso com:

curl -I http://yourdomain.com

Para entender melhor as portas, confira nosso guia sobre Como funcionam as portas do servidor da web.

Verifique as alterações

Depois que o CERTBOT é concluído, sua configuração nginx deve incluir algo assim:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Agora você deve visitar https://yourdomain.com e ver seu site com um certificado SSL válido.

Opcional: Force Https

Se você não escolheu a opção de redirecionamento durante a configuração do CERTBOT, poderá adicionar isso manualmente:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

Isso força todo o tráfego HTTP a ser redirecionado para o HTTPS, o que garante que os usuários não usem acidentalmente a versão insegura do seu site.

Etapa 3: Melhore as configurações SSL (recomendado para produção)

Depois que seu certificado SSL estiver em vigor, você poderá ajustar o NGINX para melhorar a segurança e a compatibilidade.Essas configurações entram no bloco do servidor HTTPS.

Aqui está um exemplo melhorado:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

O que essas configurações fazem

• ssl_protocols TLSv1.2 TLSv1.3
  Desative protocolos mais antigos e menos seguros como o TLS 1.0 e 1.1.
  
• ssl_prefer_server_ciphers ON
  Permite que seu servidor decida o algoritmo de criptografia, em vez de adiar o navegador - o que pode reduzir a exposição a ataques de cifra fracos.
  
• SSL_CIPHERS HIGH :! Anull :! MD5
  Especifica suítes cifras fortes e exclui as fracas ou quebradas (como MD5 e cifras nulas).
  
• ssl_session_cache e ssl_session_timeout
  Controle a reutilização da sessão SSL, que pode melhorar um pouco o desempenho sem comprometer a segurança.
  
• SSL_Session_Tickets OFF
  Desativa os ingressos de sessão, que podem ser uma preocupação de segurança se não forem girados regularmente.

Essas mudanças melhoram sua pontuação de segurança SSL e protegem os visitantes contra ataques de rebaixamento ou opções de criptografia insegura.

Opcional: Você pode testar seu site com o SSL Labs para ver como o seu configuração é executado e obter sugestões específicas de melhoria.

Etapa 4: (opcional) Adicione os parâmetros Diffie-Hellman

Para uma criptografia ainda mais forte, você pode gerar uma tecla Diffie-Hellman (DH) personalizada.Esta etapa é opcional, mas geralmente é recomendada para ambientes de produção.

Execute este comando para gerar um grupo DH de 2048 bits:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Em seguida, adicione a seguinte linha ao seu bloco de servidor SSL:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Por que adicionar isso?

Os parâmetros Diffie-Hellman se fortalecem sigilo avançado, o que significa que, mesmo que sua chave privada esteja de alguma forma comprometida no futuro, as sessões criptografadas anteriores ainda estarão seguras.

Demora alguns minutos para gerar o grupo DH, mas é um passo único e vale a pena fazer uma melhor postura de segurança.

Etapa 5: Configurar a renovação automática para certificados SSL

Vamos criptografar os certificados expirarem a cada 90 dias.Felizmente, o CERTBOT instala um cronômetro de sistema que verifica duas vezes por dia para certificados devido a expirar e renová -los automaticamente.

Você pode confirmar que o timer está ativo com:

sudo systemctl list-timers | grep certbot

Você deve ver algo assim:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

Para testar o processo de renovação manualmente (sem fazer alterações), execute:

sudo certbot renew --dry-run

Isso simula o processo completo de renovação e confirma que seu sistema está pronto para lidar com ele automaticamente.

Se não houver erros, seus certificados renovarão silenciosamente em segundo plano daqui para frente.

Passos finais e bons hábitos

Agora que seu proxy reverso é configurado e protegido com o SSL, é uma boa ideia encerrar com algumas verificações práticas e práticas recomendadas.

Esses hábitos simples podem ajudar a prevenir problemas na linha, facilitar a manutenção de sua configuração e garantir que tudo continue correndo da maneira que você espera.

Mesmo que tudo pareça estar funcionando, gastar alguns minutos extras aqui pode economizar tempo e problemas mais tarde.

Reinicie seu aplicativo se não detectar alterações automaticamente
Alguns aplicativos precisam ser reiniciados para funcionar corretamente atrás de um proxy.

Verifique os logs
Você pode monitorar logs Nginx quanto a erros ou tráfego incomum:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Mantenha o nginx e o certbot atualizado
Use a atualização SUDO APT UPDATE && SUDO APT regularmente.Pacotes atualizados corrigem os bugs, melhoram os problemas de compatibilidade e patches de segurança.

Casos de uso avançado para proxy reverso nginx com SSL

Depois de dominar o básico da configuração de um proxy reverso seguro, você pode estender sua configuração para suportar necessidades mais complexas.Aqui estão alguns cenários comuns que podem ajudá -lo a tirar mais do seu servidor.

Hospedando vários aplicativos em um servidor

Se você executar vários aplicativos da Web em diferentes portas, o NGINX poderá rotear solicitações para cada aplicativo com base no caminho do domínio ou URL.

Exemplo: diferentes domínios

server {
    listen 80;
    server_name app1.example.com;

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

server {
    listen 80;
    server_name app2.example.com;

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

Essa configuração permite que você sirva vários aplicativos usando subdomínios separados, tudo via nginx nas portas padrão.

Usando o Docker?Aprender Como proxy múltiplos aplicativos de docker com nginx.

Proxying baseado em caminho

Como alternativa, você pode proxy com base em caminhos de URL, o que é útil se você deseja todos os aplicativos em um único domínio:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

Nota: Ao usar o proxy baseado em caminho, as barras e a reescrita de URL podem ficar complicadas-verifique se o aplicativo de back-end pode lidar sendo servido sob um sub-caminho.

Adicionando taxa de limitação para proteger seu aplicativo

Você pode limitar quantas solicitações um cliente pode fazer em um determinado prazo para proteger seu back -end contra abuso ou sobrecarga acidental.

Adicione isso no bloco http em /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Então, no seu servidor ou bloco de localização:

limit_req zone=mylimit burst=20 nodelay;

Essa configuração permite 10 solicitações por segundo com rajadas de até 20 solicitações, retirando solicitações de excesso para evitar sobrecarregar seu aplicativo.

Balanceamento de carga em vários servidores de back -end

Se você tiver várias instâncias de execução do seu aplicativo (por exemplo, vários contêineres ou VPSs), o Nginx poderá distribuir o tráfego entre eles:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

O NGINX balança solicita-se a Round-Robin por padrão, mas você pode configurá-lo para outros métodos, como menos conexões ou hash IP.

Para saber mais, confira nosso guia sobre DNS Balanceamento de carga.

Registro e depuração

Você pode personalizar o registro para incluir informações importantes do proxy para solução de problemas ou análises:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

Isso registra os tempos de resposta a montante e os tempos de solicitação totais, ajudando a identificar respostas lentas de back -end.

Cabeçalhos personalizados e aprimoramentos de segurança

Você pode adicionar ou modificar cabeçalhos HTTP para segurança ou funcionalidade:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Esses cabeçalhos protegem contra o clickjacking, o Sniffing Mime e a aplicação do uso de HTTPs.