Proxy Inverso (Nginx, Caddy, Traefik)

1. Visión general del concepto y problema sistémico

Los desarrolladores principiantes a menudo intentan exponer su servidor directamente a Internet: ejecutan npm start o uvicorn main:app en el puerto 80. Esta configuración es una violación grave de los estándares arquitectónicos de producción:

• Seguridad: Para escuchar en los puertos 80 y 443, el proceso debe ejecutarse con privilegios de superusuario (root). Cualquier vulnerabilidad en una dependencia de npm le da al hacker control total sobre el sistema operativo.
• Ataques de conexiones lentas (Slowloris): Un cliente con mala conexión que envía un byte cada 10 segundos bloqueará el hilo de trabajo de Node.js o Python, paralizando el servicio a otros usuarios.
• Ineficiencia en la entrega de estáticos: Enviar imágenes, fuentes y archivos JS a través de los hilos del proceso consume recursos que deberían dedicarse a la lógica de negocio.
• Fragilidad de SSL: La necesidad de configurar el cifrado dentro del código de la aplicación obliga a reiniciar el servicio con cada actualización de certificado.

Proxy Inverso actúa como la puerta de entrada segura de su infraestructura. Acepta el tráfico externo de Internet, descifra las conexiones HTTPS, comprime los datos, almacena en caché los estáticos y reenvía de manera transparente el tráfico interno limpio a los puertos locales de sus aplicaciones aisladas (127.0.0.1:3000).

2. Taxonomía arquitectónica y modelo mental

El paisaje arquitectónico de los proxies inversos se clasifica según la paradigma de configuración:

┌─────────────────────────────────────────────────────────────┐
│                 MATRIZ DE COMPARACIÓN DE PROXY INVERSO     │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx: Arquitectura C basada en eventos (epoll / kqueue) │
│    • Máximo rendimiento bruto, mínimo uso de memoria        │
│    • Requiere Certbot externo para Let's Encrypt            │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy: Servidor Go seguro en memoria con Auto-HTTPS (ACME)│
│    • Obtención y rotación automática de SSL nativa          │
│    • Sintaxis moderna y concisa (Caddyfile)                 │
│    • Soporte nativo para HTTP/3 (QUIC) de serie             │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik: Enrutador de Contenedores Nativo de la Nube     │
│    • Captura dinámica de servicios mediante etiquetas de Docker│
│    • Ideal para la automatización de PaaS (Coolify, Kubernetes)│
└─────────────────────────────────────────────────────────────┘

1. Terminación TLS/SSL (SSL Termination):
   • El proxy asume las operaciones criptográficas intensivas del apretón de manos (TLS Handshake), liberando al backend de la carga.
2. Enrutamiento de hosts virtuales (Virtual Hosting & Routing):
   • Permite alojar decenas de proyectos diferentes en un solo servidor con una sola dirección IP:
     • gotburnout.com ➔ contenedor local en el puerto 3000 (Next.js).
     • api.gotburnout.com ➔ contenedor local en el puerto 8000 (FastAPI).
     • n8n.gotburnout.com ➔ puerto interno 5678 (n8n).
3. Proxy de flujos en tiempo real (WebSockets & SSE):
   • Manejo especial de los encabezados Upgrade y desactivación de buffering para soportar conexiones de dúplex completo y streaming de generación de tokens desde LLM.
4. Compresión en vuelo (Gzip & Brotli):
   • Comprime recursos de texto, reduciendo el volumen de tráfico enviado al cliente en un 60–80%.

3. Pipeline técnico y mecánica interna

El ciclo de vida de una solicitud del cliente a través del proxy inverso:

1. Establecimiento de conexión segura (TLS Handshake): El cliente inicia la conexión en el puerto 443. Caddy o Nginx negocian el protocolo TLS 1.3, envían un certificado de dominio válido y cifran el canal.
2. Análisis de encabezados y SNI (Server Name Indication): El proxy lee el encabezado Host: gotburnout.com y la ruta URL /api/v1/chat.
3. Normalización de encabezados del proxy: El proxy añade encabezados de servicio para que la aplicación interna conozca la dirección IP real del cliente:

   X-Real-IP: 203.0.113.195
   X-Forwarded-For: 203.0.113.195, 10.0.0.1
   X-Forwarded-Proto: https
   

4. Envío al upstream (Upstream Dispatch): La solicitud se redirige a un socket local http://127.0.0.1:3000 a través de un pool de conexiones previamente abierto (Connection Pooling).
5. Recepción y transmisión de la respuesta al cliente:
   • Si se devuelve un archivo estático, el proxy lo almacena en caché.
   • Si se trata de un streaming de tokens (SSE), el proxy transmite inmediatamente cada chunk al cliente sin acumular en el buffer.

4. Escenarios prácticos de ingeniería en producción

01. Configuración de Caddy para Next.js y streaming de AI en 10 líneas

Archivo Caddyfile para producción con HTTPS automático y soporte para streaming:

gotburnout.com {
    encode zstd gzip

    # Proxy de la aplicación
    reverse_proxy 127.0.0.1:3000 {
        # Desactivación de buffering para streaming inmediato de tokens LLM
        flush_interval -1
    }

    # Almacenamiento en caché de archivos estáticos de Next.js por 1 año
    @static path /_next/static/*
    header @static Cache-Control "public, max-age=31536000, immutable"
}

02. Configuración de Nginx para Server-Sent Events (SSE)

Prevención de congelamientos en el streaming en Nginx:

location /api/generate {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    
    # Directivas críticas para streaming de AI:
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;
    proxy_read_timeout 600s;
}

03. Enrutamiento de plataforma multiserver en un solo servidor

Organización del acceso a herramientas internas:

• Caddy distribuye el tráfico: solicitudes a ai.company.internal se dirigen al contenedor Ollama, y metrics.company.internal a la interfaz de Grafana, cerrando el acceso con autenticación básica (basic_auth).

5. Errores comunes, trampas y seguridad

• Congelamiento del streaming por buffering: El error más común en Nginx es tener proxy_buffering habilitado por defecto. El usuario ve una pantalla en blanco durante 30 segundos, después de lo cual todo el artículo generado aparece de una vez.
• Suplantación de IP a través de encabezados no confiables (IP Spoofing): Si su backend lee ingenuamente req.headers['x-forwarded-for'] sin verificar que la solicitud proviene de su proxy local, un atacante puede falsificar cualquier dirección IP para eludir los límites de tasa.
• Inyección de encabezados Host: Si en la configuración de Nginx se establece un bloque por defecto (default_server) que reenvía tráfico sin verificar el nombre del host, un atacante puede manipular enlaces de restablecimiento de contraseña a través de un encabezado Host falsificado.
• Tiempos de espera olvidados para largas solicitudes de AI: El tiempo de espera estándar para esperar una respuesta del backend es de 60 segundos (proxy_read_timeout 60s). Si un modelo complejo de razonamiento tarda 90 segundos, el proxy devolverá al cliente un 504 Gateway Timeout. Aumente el tiempo de espera para rutas de AI.