Como implementar reverse proxy em APIs backend: guia prático para produção

Publicar uma API diretamente na internet parece simples: abrir uma porta, iniciar o processo da aplicação e apontar o domínio. Em produção, porém, esse desenho cria dificuldades para aplicar HTTPS, limitar abusos, registrar tráfego, distribuir carga e trocar versões com segurança. Um reverse proxy resolve essas responsabilidades em uma camada própria.

Neste guia, você vai configurar o Nginx como porta de entrada de uma API backend, mantendo a aplicação em rede interna e preparando a operação para segurança, observabilidade e crescimento.

O que é reverse proxy e por que APIs backend precisam dele

Um reverse proxy é um servidor que recebe a requisição do cliente e a encaminha para um ou mais serviços internos. Para quem consome a API, o Nginx é o endereço público. Para a aplicação, o Nginx é o intermediário que entrega apenas as requisições permitidas.

Isso é diferente de um forward proxy, usado por clientes para controlar ou ocultar sua saída para a internet. No reverse proxy, a proteção está do lado da infraestrutura que publica o serviço.

Em uma arquitetura comum, uma API Node.js, Python, Java ou PHP escuta somente em 127.0.0.1:3000 ou em uma rede privada. O Nginx recebe conexões nas portas 80 e 443, termina o TLS, aplica regras de tráfego e encaminha as chamadas ao backend.

Essa separação reduz a superfície exposta, centraliza políticas HTTP e torna a manutenção mais previsível. Também facilita evoluir a arquitetura sem alterar o endereço público da API.

Arquitetura recomendada para API com Nginx em produção

Use o Nginx como único ponto público de entrada. O DNS aponta, por exemplo, api.exemplo.com para o servidor ou balanceador que executa o proxy. A aplicação e o banco de dados ficam em redes restritas.

Cliente → DNS → Nginx (80/443) → API interna (3000/3001) → Banco de dados

O backend não deve precisar de uma regra pública de firewall quando estiver no mesmo host ou em uma rede privada. O banco de dados deve aceitar conexões apenas das aplicações e serviços autorizados.

Esse desenho também permite iniciar com uma única instância e, depois, adicionar réplicas ao upstream do Nginx. Em ambientes com containers, mantenha Nginx e API em uma rede privada compartilhada e publique externamente somente o proxy.

Pré-requisitos antes de configurar o Nginx

Antes de criar a configuração, confirme que o domínio aponta para o IP correto, o Nginx está instalado e a API responde localmente. Um endpoint de saúde simples ajuda a separar uma falha da aplicação de uma falha do proxy.

curl -i http://127.0.0.1:3000/health
nginx -t

Libere no firewall apenas as portas públicas necessárias, normalmente 80 e 443. A porta interna da aplicação não deve ser acessível pela internet.

Prepare também o certificado TLS. Ele pode ser provisionado antes da publicação ou automatizado conforme a política operacional do ambiente. Verifique permissões de leitura dos arquivos de certificado pelo processo do Nginx.

Como configurar Nginx como reverse proxy para uma API

O bloco abaixo publica a rota /api/ e encaminha as chamadas para uma aplicação local. Ajuste domínio, porta, rota e caminhos de certificado ao seu ambiente.

server {
    listen 80;
    server_name api.exemplo.com;

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_http_version 1.1;

        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;

        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

O comportamento da barra final em proxy_pass importa. Com location /api/ e proxy_pass http://127.0.0.1:3000/, o prefixo /api/ é substituído ao encaminhar a requisição. Teste as rotas reais da sua API para garantir que o caminho esperado pelo backend foi preservado.

Os cabeçalhos encaminhados são essenciais para logs, geração de URLs e políticas que dependem do protocolo original. A aplicação deve confiar em X-Forwarded-For e X-Forwarded-Proto somente quando o tráfego chegar por proxies conhecidos.

Sempre valide a sintaxe antes de aplicar a alteração e recarregue o serviço sem interromper conexões existentes.

nginx -t && systemctl reload nginx

HTTPS, redirecionamento e cabeçalhos de segurança

Em produção, a API deve atender por HTTPS. Mantenha um bloco na porta 80 apenas para redirecionar o tráfego ao endereço seguro e concentre a terminação TLS no Nginx.

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

server {
    listen 443 ssl http2;
    server_name api.exemplo.com;

    ssl_certificate /caminho/fullchain.pem;
    ssl_certificate_key /caminho/privkey.pem;

    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy no-referrer always;

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

HSTS pode reforçar o uso de HTTPS, mas deve ser habilitado somente depois de validar que todos os subdomínios e fluxos necessários funcionam corretamente com TLS. Para APIs, aplique cabeçalhos de segurança de acordo com o comportamento da aplicação, sem copiar regras destinadas a páginas HTML sem avaliação.

O backend precisa receber X-Forwarded-Proto: https após a terminação TLS; caso contrário, poderá gerar redirecionamentos incorretos ou interpretar a requisição como insegura.

Timeouts, limites de requisição e rate limiting

Timeouts muito altos mantêm recursos ocupados por mais tempo; valores muito baixos interrompem operações legítimas. Comece com limites coerentes com os endpoints e ajuste-os com base em métricas de latência e erros.

Defina o tamanho máximo de corpo conforme o uso da API. Endpoints JSON normalmente precisam de limites menores do que endpoints de upload.

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    server {
        client_max_body_size 10m;

        location /api/auth/ {
            limit_req zone=api_limit burst=20 nodelay;
            proxy_pass http://127.0.0.1:3000/;
        }
    }
}

A limitação por IP é especialmente útil em autenticação e rotas suscetíveis a abuso, mas não substitui controles da aplicação. Clientes legítimos podem compartilhar IP, e serviços atrás de CDN ou outro proxy exigem configuração correta do IP real antes de usar esse critério.

Quando uma requisição for recusada por limite, responda de forma consistente com 429 Too Many Requests e documente as expectativas de consumo para integrações parceiras.

Balanceamento de carga e alta disponibilidade

Quando uma instância deixa de ser suficiente, defina um bloco upstream e encaminhe o tráfego para ele. Por padrão, o Nginx distribui as chamadas em round-robin.

upstream api_backend {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl http2;
    server_name api.exemplo.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

least_conn pode ajudar quando a duração das requisições varia. ip_hash oferece afinidade por IP, mas costuma ser uma alternativa menos flexível do que manter a aplicação stateless e armazenar sessões fora das instâncias.

Os parâmetros de falha ajudam a remover temporariamente servidores que não respondem, mas não substituem health checks, monitoramento e um processo de deploy seguro. Combine o proxy com estratégias de alta disponibilidade de aplicações para reduzir indisponibilidade durante picos e atualizações.

Logs, monitoramento e checklist de validação

O access log do Nginx mostra volume, códigos HTTP e tempos de resposta; o error log ajuda a identificar falhas de conexão, timeout e configuração. Inclua um identificador de requisição quando possível para correlacionar o log do proxy com o log da aplicação.

Acompanhe taxa de respostas 4xx e 5xx, latência, conexões ativas, consumo de recursos e disponibilidade do endpoint de saúde. Alertas devem considerar tendência e impacto, não apenas uma ocorrência isolada.

Checklist antes e depois da publicação

• Validar a configuração com nginx -t.
• Recarregar o Nginx e verificar se o processo permanece saudável.
• Testar o endpoint /health externamente por HTTPS.
• Confirmar autenticação, rotas protegidas, payloads permitidos e respostas de erro.
• Verificar se o backend não está acessível diretamente pela porta interna.
• Revisar logs após o deploy e monitorar a taxa de erros.

Com essa base, o reverse proxy deixa de ser apenas um redirecionador de portas e passa a ser uma camada operacional importante para publicar APIs com previsibilidade.

Precisa publicar ou modernizar APIs com Nginx, HTTPS, segurança e monitoramento? Conheça as soluções da Max Alex para infraestrutura e aplicações em produção.