n8n usa por debajo el cliente HTTP de Node, lo que significa que respeta las variables de entorno estándar de proxy. Eso da dos caminos de configuración, con ventajas e inconvenientes distintos.
Los nombres de nodos y opciones de esta guía están en inglés, tal como aparecen en la interfaz de n8n.
Antes de decidir: qué enrutar
Este es el punto que más quebraderos de cabeza da. n8n genera varios tipos de tráfico:
| Tipo de tráfico | ¿Enrutar por el proxy? |
|---|---|
| Llamadas a APIs externas | Sí, cuando necesitan una IP dedicada |
| Recopilación de páginas web | Sí |
| Base de datos (Postgres, MySQL) | No |
| Webhooks internos | No |
| Comunicación entre contenedores | No |
| Redis / cola | No |
Enrutar el tráfico interno por el proxy añade latencia, consume recursos y no aporta nada. Peor aún: puede romper la conexión con la base de datos.
Opción 1: variable de entorno (global)
Se aplica a todos los nodos que hacen llamadas HTTP, incluidos los nodos de integración ya hechos.
export HTTP_PROXY="http://usuario:[email protected]:8000"
export HTTPS_PROXY="http://usuario:[email protected]:8000"
export NO_PROXY="localhost,127.0.0.1,postgres,redis,n8n"
La variable NO_PROXY es la parte crítica. Enumera lo que no debe pasar por el proxy, y ahí es donde proteges el tráfico interno. Incluye los nombres de host de tus contenedores.
En Docker Compose:
services:
n8n:
image: n8nio/n8n:latest
environment:
- HTTP_PROXY=http://usuario:[email protected]:8000
- HTTPS_PROXY=http://usuario:[email protected]:8000
- NO_PROXY=localhost,127.0.0.1,postgres,redis
- N8N_HOST=tu-dominio.com
depends_on:
- postgres
Reinicia el contenedor después de cambiar las variables.
Opción 2: por nodo (granular)
Es mejor cuando solo algunas peticiones necesitan el proxy, o cuando workflows distintos usan proxies distintos.
En el nodo HTTP Request, abre Options → Proxy e indica:
http://usuario:[email protected]:8000
Ventaja: control total, sin afectar al resto de la instancia. Inconveniente: hay que configurarlo en cada nodo, y los nodos de integración ya hechos no ofrecen ese campo.
Opción 3: proxies distintos por cliente
Si atiendes a varios clientes en el mismo n8n, usa una variable por cliente y monta la URL de forma dinámica.
En un nodo Code antes de la petición:
const proxies = {
'cliente-a': 'http://user_a:[email protected]:8000',
'cliente-b': 'http://user_b:[email protected]:8000',
}
return items.map(item => ({
json: {
...item.json,
proxyUrl: proxies[item.json.cliente],
},
}))
Y en el nodo HTTP Request, usa {{ $json.proxyUrl }} en el campo del proxy.
Valida con un workflow de prueba
Antes de pasar a producción, monta un workflow mínimo:
- Nodo Manual Trigger
- Nodo HTTP Request apuntando a
https://ipinfo.io/json - Ejecútalo y revisa la respuesta
La IP devuelta tiene que ser la que contrataste, con el código del país que elegiste en el campo country. Si aparece la IP del servidor, el proxy no se está aplicando.
Guarda ese workflow. Se convierte en tu herramienta de diagnóstico cuando algo cambie.
Contraseña con caracteres especiales
Si la contraseña contiene @, :, / o #, codifícala dentro de la URL: @ pasa a %40, : a %3A, / a %2F y # a %23.
La @ es el caso crítico, porque es el separador entre la credencial y el host en la estructura de la URL. Más detalles en autenticación con usuario y contraseña.
Problemas comunes
n8n no arranca después de configurar el proxy: probablemente la base de datos se está enrutando por el proxy. Añade el host de la base de datos a NO_PROXY.
Los webhooks dejaron de funcionar: el tráfico de entrada no pasa por un proxy de salida, pero si lo enrutaste todo, las llamadas internas de retorno pueden estar rotas. Revisa NO_PROXY.
Algunos nodos usan el proxy y otros no: es el comportamiento esperado cuando mezclas configuración global y por nodo. La configuración del nodo tiene prioridad.
Error de autenticación: contraseña con caracteres especiales sin codificar, o credencial con un espacio de más.
Todo va lento después del cambio: estás enrutando tráfico interno. Ajusta NO_PROXY.
Otros fallos habituales están en errores comunes de configuración.
Cuándo necesitas una IP dedicada en n8n
No siempre. Vale la pena cuando:
- La API de destino limita las peticiones por IP y compartes la IP del proveedor de nube
- Necesitas que las llamadas salgan de un país concreto
- El workflow accede a cuentas que deben parecer independientes entre clientes
- La IP de tu proveedor de nube ya tiene un mal historial
Si el workflow solo llama a APIs públicas sin límites relevantes, la IP del servidor basta y no hay motivo para añadir un proxy. Y un proxy no cambia las condiciones de uso de la API de destino: si limita por cuenta o por clave, cambiar de IP no lo evita.
Para dimensionar IPs en automatizaciones, mira el proxy para automatización.