Balanceo de proxy para n8n en Docker: corrigiendo errores de DNS

Balanceo de Carga Tolerante a Fallos con Proxy para n8n en Docker: Solucionando Timeouts de DNS y Errores de Acceso

Ejecutar n8n a través de un solo proxy representa una vulnerabilidad arquitectónica. Si la IP se bloquea o el servidor proxy falla, todos los flujos de trabajo se detienen en seco. La única solución confiable es implementar un grupo de proxies con conmutación por error automática y balanceo round-robin. Esta guía te explica paso a paso cómo configurar 3proxy en un stack de Docker, resolviendo errores críticos de DNS y problemas de permisos, y verificando la fiabilidad de toda la cadena.

Arquitectura de Grupo de Proxies Tolerante a Fallos

En lugar de conectar n8n directamente a Telegram u otras APIs externas, insertamos un contenedor local de 3proxy que actúa como puerta de enlace. Maneja solicitudes HTTP/HTTPS de n8n en el puerto 3128 y las distribuye entre una lista predefinida de proxies SOCKS5 externos. Ventajas clave:

• Conmutación por error automática: Si un nodo falla, el tráfico se redirige instantáneamente al siguiente proxy disponible.
• Transparencia para n8n: No se necesitan cambios en los flujos de trabajo; solo configura una sola dirección de proxy en las variables de entorno.
• Protección contra fugas de IP: Si todos los proxies externos fallan, las conexiones se cortan a la fuerza, evitando que el tráfico salga por la IP real del servidor.

La configuración usa docker-compose, con ambos servicios (n8n y 3proxy) en una red personalizada. Esto garantiza un enrutamiento interno estable sin exponer puertos en el host.

Configurando docker-compose.yml y el Archivo de Configuración de 3proxy

Comienza con este stack básico. Nota el parámetro user: "0:0" —es esencial para que 3proxy funcione dentro del contenedor, ya que el proceso necesita privilegios para vincular puertos de red y leer la configuración de los volúmenes.

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    environment:
      - HTTP_PROXY=http://3proxy:3128
      - HTTPS_PROXY=http://3proxy:3128
      - http_proxy=http://3proxy:3128
      - https_proxy=http://3proxy:3128
    networks:
      - n8n_net

  3proxy:
    image: ghcr.io/z3apa3a/3proxy:latest
    container_name: 3proxy
    restart: always
    user: "0:0"
    volumes:
      - ./3proxy.cfg:/etc/3proxy/3proxy.cfg
    networks:
      - n8n_net

networks:
  n8n_net:
    name: n8n_net

La lógica central de balanceo va en 3proxy.cfg. Aquí tienes una configuración mínima funcional con comentarios:

daemon
log /var/log/3proxy.log D
logformat "L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

# Use Docker's DNS resolver, not an external one (e.g., 8.8.8.8)
nserver 127.0.0.11
nscache 65536
timeouts 1 5 30 60 180 1800 15 60

# Enable ACL — without this, parent chains are ignored
auth iponly

# Allow must come BEFORE declaring parent
allow *

# Pool of external proxies (round-robin)
parent 1000 socks5 IP_PROXY_1 PORT_1 LOGIN_1 PASS_1
parent 1000 socks5 IP_PROXY_2 PORT_2 LOGIN_2 PASS_2
parent 1000 socks5 IP_PROXY_3 PORT_3 LOGIN_3 PASS_3

# Deny direct outbound if all proxies are unavailable
deny * * 0.0.0.0/0

# Launch HTTP proxy on port 3128
proxy -p3128 -a
flush

Diagnosticando y Solucionando Errores Comunes

En el primer arranque, encontrarás tres problemas típicos. Resolverlos es clave para un sistema estable.

Error 1: Timeouts de DNS (26 Segundos por Solicitud)

Síntomas: n8n se cuelga en cada solicitud exactamente 26 segundos, y luego recibe una respuesta o expira.

Causa: La configuración apunta a un servidor DNS externo (p. ej., nserver 8.8.8.8), pero el contenedor de 3proxy no puede acceder a internet fuera de la red personalizada de Docker. Las consultas DNS no van a ninguna parte y esperan el timeout.

Solución: Cambia al resolvedor interno de Docker con nserver 127.0.0.11. Esta dirección siempre está disponible en cualquier contenedor y reenvía las consultas al sistema host.

Error 2: Permiso Denegado al Iniciar el Contenedor

Síntomas: El contenedor de 3proxy se estrella justo después de iniciar, con logs que muestran incapacidad para vincular puertos o leer la configuración.

Causa: La imagen oficial de 3proxy se ejecuta como usuario sin privilegios por defecto, lo que impide vincular puertos por debajo de 1024 o acceder a volúmenes montados.

Solución: Configura explícitamente user: "0:0" en docker-compose para el servicio 3proxy. Esto ejecuta el proceso como root en el espacio de nombres aislado del contenedor —seguro porque la red está restringida.

Error 3: Tráfico que Evade el Grupo de Proxies

Síntomas: n8n funciona, pero las comprobaciones de IP saliente muestran la dirección real del servidor, no un proxy. El balanceador ignora las directivas parent.

Causas y Soluciones:

• Orden incorrecto de directivas: allow * debe ir estrictamente antes del primer parent, o el analizador genera un Chaining error y desactiva el encadenamiento.
• ACL desactivada: auth none desactiva completamente el control de acceso, rompiendo la lógica de reenvío. Usa auth iponly en su lugar.
• Sin protección de respaldo: Sin deny 0.0.0.0/0, el sistema puede filtrar tráfico directo si falla todo el grupo. Esta línea asegura que las conexiones se caigan en lugar de recurrir a la ruta por defecto.

Verificando la Funcionalidad del Sistema

Una vez configurado, confirma que el tráfico fluye a través del balanceador y el grupo de proxies. Usa estas dos comprobaciones:

• Revisa los logs de 3proxy:

```

docker compose logs --tail 20 3proxy

```

Busca entradas como [NNN] CONNECT ... —confirman que las solicitudes se aceptan y reenvían. Si ves Permission denied, revisa la configuración user: "0:0".

• Prueba de extremo a extremo desde n8n:

```

docker compose exec n8n curl -Ivx http://3proxy:3128 https://api.telegram.org

```

Espera un HTTP 200 OK y cabeceras. Si se cuelga, el problema es DNS (nserver). Si Connection refused, asegúrate de que 3proxy esté ejecutándose y el puerto 3128 abierto.

Opcionalmente, agrega logrotate 1000000 5 a la configuración de 3proxy para rotación de logs basada en tamaño y evitar llenar el disco.

Lecciones Clave

• El DNS de Docker debe apuntar siempre a 127.0.0.11, o tendrás timeouts de 26 segundos.
• Los permisos de usuario en el contenedor son críticos: Sin user: "0:0", 3proxy no puede vincular el puerto 3128.
• El orden de directivas en la configuración de 3proxy importa: allow * antes de parent, auth iponly en lugar de none.
• La protección contra fugas de IP es esencial: deny 0.0.0.0/0 bloquea el tráfico directo en caso de fallo total de proxies.
• El balanceo round-robin está integrado en 3proxy —no se necesitan herramientas o scripts extra.

Esta configuración mantiene n8n funcionando sin problemas incluso con fallos parciales de infraestructura. Los cambios son transparentes para los flujos de trabajo: solo apunta al proxy local una vez, y el enrutamiento se encarga del resto automáticamente.

— Editorial Team