Skip to main content

Proxy reverso (Nginx, Caddy, Traefik)

PARA AGENTES DE IAChatGPTClaude

Camada de arquitetura de servidor intermediária que recebe tráfego externo da internet (portas 80/443), realiza a terminação SSL/TLS, compressão (Brotli/Gzip), cache de arquivos estáticos e roteia com segurança as requisições para aplicações internas.

1. Visão geral do conceito e problema sistêmico

Desenvolvedores iniciantes frequentemente tentam expor seus servidores diretamente à internet: executam npm start ou uvicorn main:app na porta 80. Essa configuração viola gravemente os padrões de arquitetura de produção:

  • Segurança: Para escutar nas portas 80 e 443, o processo precisa de privilégios de superusuário (root). Qualquer vulnerabilidade em uma dependência npm concede ao atacante controle total sobre o sistema operacional.
  • Ataques de conexões lentas (Slowloris): Um cliente com conexão instável que envia um byte a cada 10 segundos bloqueará as threads de trabalho do Node.js ou Python, paralisando o atendimento aos demais usuários.
  • Ineficiência na entrega de estáticos: Servir imagens, fontes e arquivos JS através das threads da aplicação consome recursos que deveriam ser dedicados à lógica de negócio.
  • Fragilidade do SSL: A necessidade de configurar criptografia dentro do código da aplicação obriga a reiniciar o serviço a cada atualização de certificado.

O Reverse Proxy atua como a porta de entrada segura e protegida da sua infraestrutura. Ele recebe o tráfego externo da internet, descriptografa as conexões HTTPS, comprime dados, faz cache de arquivos estáticos e encaminha transparentemente o tráfego interno puro para as portas locais dos seus aplicativos isolados (127.0.0.1:3000).

2. Taxonomia arquitetural e modelo mental

O cenário arquitetural de reverse proxies é classificado pela paradigma de configuração:

┌─────────────────────────────────────────────────────────────┐
│                 MATRIZ DE COMPARAÇÃO DE PROXY REVERSO       │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx: Arquitetura C orientada a eventos (epoll / kqueue)│
│    • Máximo desempenho bruto, uso mínimo de memória         │
│    • Requer Certbot externo para Let's Encrypt              │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy: Servidor Go seguro em memória com HTTPS automático│
│    • Obtenção e rotação SSL nativas automáticas             │
│    • Sintaxe moderna e concisa (Caddyfile)                  │
│    • Suporte nativo a HTTP/3 (QUIC) pronto para uso         │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik: Roteador de contêineres Cloud-Native            │
│    • Descoberta dinâmica de serviços via Docker Labels      │
│    • Ideal para automação PaaS (Coolify, Kubernetes)        │
└─────────────────────────────────────────────────────────────┘
  1. Terminação TLS/SSL (SSL Termination):
    • O proxy assume as operações criptográficas custosas do handshake (TLS Handshake), aliviando a carga no backend.
  2. Roteamento de Hosts Virtuais (Virtual Hosting & Routing):
    • Permite hospedar dezenas de projetos diferentes em um único servidor com um único IP:
      • gotburnout.com ➔ container local na porta 3000 (Next.js).
      • api.gotburnout.com ➔ container local na porta 8000 (FastAPI).
      • n8n.gotburnout.com ➔ porta interna 5678 (n8n).
  3. Proxying de Fluxos em Tempo Real (WebSockets & SSE):
    • Tratamento especial dos cabeçalhos Upgrade e desativação de buffering para suportar conexões full-duplex e streaming de tokens gerados por LLMs.
  4. Compressão On-the-fly (Gzip & Brotli):
    • Comprime recursos textuais, reduzindo o volume de tráfego enviado ao cliente em 60–80%.

3. Pipeline técnico e mecânica interna

O ciclo de vida de uma requisição do cliente atravessando o reverse proxy:

  1. Estabelecimento de Conexão Segura (TLS Handshake): O cliente inicia a conexão na porta 443. O Caddy ou Nginx negocia o protocolo TLS 1.3, envia o certificado válido do domínio e cifra o canal.
  2. Análise de Cabeçalhos e SNI (Server Name Indication): O proxy lê o cabeçalho Host: gotburnout.com e o caminho da URL /api/v1/chat.
  3. Normalização de Cabeçalhos de Proxy: O proxy adiciona cabeçalhos informativos para que a aplicação interna conheça o IP real do cliente:
    X-Real-IP: 203.0.113.195
    X-Forwarded-For: 203.0.113.195, 10.0.0.1
    X-Forwarded-Proto: https
    
  4. Encaminhamento para Upstream (Upstream Dispatch): A requisição é redirecionada para o socket local http://127.0.0.1:3000 através de um pool de conexões previamente aberto (Connection Pooling).
  5. Recebimento e Retorno da Resposta ao Cliente:
    • Se for retornado um arquivo estático — o proxy faz cache dele.
    • Se for streaming de tokens (SSE) — o proxy transmite imediatamente cada chunk ao cliente sem acumular no buffer.

4. Cenários práticos de engenharia em produção

01. Configuração do Caddy para Next.js e Streaming de IA em 10 linhas

Arquivo Caddyfile para produção com HTTPS automático e suporte a streaming:

gotburnout.com {
    encode zstd gzip

    # Проксування додатку
    reverse_proxy 127.0.0.1:3000 {
        # Вимкнення буферизації для миттєвого стрімінгу LLM токенів
        flush_interval -1
    }

    # Кешування статичних файлів Next.js на 1 рік
    @static path /_next/static/*
    header @static Cache-Control "public, max-age=31536000, immutable"
}

02. Configuração do Nginx para Server-Sent Events (SSE)

Prevenção de travamentos no streaming via Nginx:

location /api/generate {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    
    # Критично важливі директиви для стрімінгу AI:
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;
    proxy_read_timeout 600s;
}

03. Roteamento de Plataforma Multisserviço em um Único Servidor

Organização de acesso às ferramentas internas:

  • O Caddy distribui o tráfego: requisições para ai.company.internal são direcionadas ao container Ollama, enquanto metrics.company.internal vai para o painel Grafana, protegendo o acesso com autenticação básica (basic_auth).

5. Armadilhas comuns, erros típicos e segurança

  • Travamento de streaming devido a buffering: O erro mais comum no Nginx é o proxy_buffering ativado por padrão. O usuário vê uma tela vazia por 30 segundos, após o qual todo o artigo gerado aparece simultaneamente.
  • Spoofing de IP via cabeçalhos não confiáveis (IP Spoofing): Se seu backend lê ingenuamente req.headers['x-forwarded-for'] sem verificar se a requisição veio exatamente do seu proxy local, um atacante pode falsificar qualquer endereço IP para burlar rate limits.
  • Host Header Injection: Se a configuração do Nginx possui um bloco default (default_server) que encaminha tráfego sem validar o nome do host, um atacante pode manipular links de redefinição de senha através de um cabeçalho Host forjado.
  • Timeouts esquecidos para requisições longas de IA: O timeout padrão de espera pela resposta do backend é de 60 segundos (proxy_read_timeout 60s). Se um modelo complexo de raciocínio levar 90 segundos para "pensar", o proxy retornará ao cliente um 504 Gateway Timeout. Aumente os timeouts para rotas de IA.
/ Perguntas FrequentesSchema.org FAQPage

FAQ: Proxy reverso (Nginx, Caddy, Traefik)

A vinculação às portas privilegiadas (80/443) exige a execução da aplicação como root (risco crítico de segurança). Aplicações em Node.js são mal otimizadas para conexões lentas (ataques Slowloris), o fornecimento de arquivos estáticos pesados via V8 bloqueia o event loop, e a falha do processo interrompe completamente o acesso ao site.
/ Links internos
Todos os termos