Proxies para n8n: cómo configurar HTTP Request y evitar el error 403

```html

Has creado un flujo de trabajo en n8n, ha funcionado durante dos semanas y luego comenzó a caer constantemente con 403 Forbidden. El primer pensamiento es "el sitio se ha roto" o "las credenciales han caducado". La mayoría de las veces, el problema es otro: el servidor de destino ha detectado que la solicitud proviene de una automatización, no de un navegador, y está utilizando la IP del centro de datos de tu VPS. n8n tiene un mecanismo de proxy integrado, pero no está habilitado por defecto, y parte de la configuración se encuentra en un lugar inesperado.

Desglosaremos paso a paso: dónde se configura el proxy en n8n, qué diferencia hay entre self-hosted y Cloud, y cuáles son las tres trampas que consumen más tiempo.

Por qué n8n es bloqueado más a menudo que tu navegador

n8n es la plataforma de automatización open-source más grande: casi 198 mil estrellas y 59,6 mil bifurcaciones en GitHub, la versión actual en el momento de la publicación es [email protected] (24 de julio de 2026). La popularidad tiene un lado negativo: los sistemas anti-bots conocen perfectamente su huella digital.

Se combinan tres factores:

• User-Agent te delata instantáneamente. Esto no es una suposición, sino un comportamiento documentado oficialmente. En n8n hay una variable N8N_ENFORCE_GLOBAL_USER_AGENT (por defecto false), y la documentación describe claramente su propósito: reemplazar la cadena "desnuda" User-Agent n8n por una compatible con RFC Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/), para prevenir el bloqueo de solicitudes por firewalls de aplicaciones web. El problema llegó a ser tan grave que se reportaron errores: en el issue #28280 (abierto el 10 de abril de 2026, cerrado) se describe cómo los nodos nativos devolvían bare-UA n8n, y los sitios respondían con 403 por "Bad User-Agent". El nodo HTTP Request utiliza axios y sin un encabezado manual se reconoce fácilmente.
• La IP de tu servidor es de un centro de datos. n8n casi siempre se ejecuta en VPS o en la nube. Estos rangos son públicamente conocidos y etiquetados como "no de usuario": algunas plataformas los bloquean más estrictamente, hasta límites de solicitudes mucho más bajos que los de las conexiones domésticas.
• El ritmo de solicitudes es inhumano. Un nodo en un ciclo emite decenas de solicitudes por segundo desde una sola dirección, lo que provoca un clásico desencadenante de limitación de tasa y posterior baneo de IP.

Paso 1. Proxy en el propio nodo (funciona también en Cloud)

La forma más rápida es establecer un proxy específicamente para una solicitud HTTP:

1. Abre el nodo HTTP Request.
2. En la parte inferior, haz clic en Add Option y selecciona Proxy — este es un campo de texto para la URL del servidor proxy.
3. Escribe la cadena en el formato estándar con autenticación: http://USUARIO:CONTRASEÑA@host:port.
4. También añade la opción de encabezados: activa Send Headers y establece User-Agent de un navegador real — copia manualmente la cadena actual de DevTools de tu Chrome.

Este método es el único disponible en n8n Cloud: allí no gestionas el entorno de ejecución, por lo que las variables de entorno del sistema no están disponibles, y la IP de salida no está fija y cambia de ejecución a ejecución. La ventaja de este enfoque es la granularidad: diferentes nodos de un mismo flujo de trabajo pueden usar diferentes proxies y diferentes geografías. La desventaja es que si hay veinte nodos, tendrás que editar veinte lugares.

Paso 2. Proxy global a través de variables de entorno (self-hosted)

En tu propio servidor, es más lógico enrutar todo el tráfico saliente de una vez. n8n lee las variables estándar:

• HTTP_PROXY — URL del proxy para el tráfico HTTP no cifrado de los nodos;
• HTTPS_PROXY — lo mismo para solicitudes TLS/SSL (en la práctica, este es tu parámetro principal);
• ALL_PROXY — se utiliza cuando no se han establecido proxies más específicos HTTP_PROXY/HTTPS_PROXY;
• NO_PROXY — lista de hosts separados por comas, a los que n8n se conectará directamente sin pasar por el proxy.

En docker-compose.yml esto se vería así:

• HTTPS_PROXY=http://USUARIO:CONTRASEÑ[email protected]:8080
• NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
• N8N_ENFORCE_GLOBAL_USER_AGENT=true

Asegúrate de completar NO_PROXY. De lo contrario, a través del proxy externo también se enviarán las solicitudes internas — a tu Postgres, a contenedores vecinos, a tu propio dominio de webhook. El síntoma es "todo se rompió después de habilitar el proxy", aunque los sitios de destino comenzaron a abrirse.

Si deseas no revelar la versión de n8n externamente, en lugar de la cadena RFC, establece la tuya a través de N8N_GLOBAL_USER_AGENT_VALUE — esta anula el valor por defecto. La lógica general para configurar el tráfico del contenedor es la misma que en otros escenarios: el desglose de formatos y trampas está en la guía sobre proxies para contenedores Docker.

Paso 3. Tres trampas que roban la tarde

Trampa 1: el registro de variables importa

No es obvio y casi no se encuentra en tutoriales. n8n procesa las variables que terminan en _PROXY a través del paquete npm proxy-from-env, y este impone su propio orden de prioridad: las versiones en minúsculas (http_proxy) tienen prioridad sobre las mayúsculas (HTTP_PROXY) si ambas están establecidas. Un escenario clásico de dolor: en el sistema hay un https_proxy olvidado desde hace tiempo, tú cuidadosamente escribes HTTPS_PROXY en el compose — y el tráfico sigue yendo a la antigua dirección. Verifica ambos registros.

Un detalle separado para Enterprise: la variable proxy para solicitudes al servidor de licencias https_proxy_license_server debe ser solo en minúsculas, formato — https://user:pass@proxy:port.

Trampa 2: el nodo Code no hace lo que pensabas

Un consejo común de los foros es "escribe tu solicitud en el nodo Code usando un agente proxy". Por defecto, esto no funcionará: n8n desactiva la importación de módulos en el nodo Code. Tienes que permitirlos explícitamente — NODE_FUNCTION_ALLOW_BUILTIN para los integrados y NODE_FUNCTION_ALLOW_EXTERNAL para los externos (de n8n/node_modules). Un matiz adicional: si tienes ejecutores de tareas en modo externo, estas variables se establecen no en el entorno del contenedor, sino en la configuración de los ejecutores /etc/n8n-task-runners.json como env-override. Es más fácil y seguro quedarse con la opción estándar Proxy en el nodo.

Trampa 3: hay proxy, pero el ritmo sigue igual

El proxy cambia la dirección, pero no el comportamiento. Si el flujo de trabajo sigue emitiendo una ráfaga de solicitudes, simplemente quemarás nuevas IP. En el mismo nodo hay frenos integrados:

• Batching — Items per Batch (cuántos elementos por lote) y Batch Interval en milisegundos (0 = sin pausa). Establece un lote de 1–5 y un intervalo de 1000–3000 ms.
• Timeout — en milisegundos; los canales residenciales son más lentos que los de centros de datos, el valor por defecto debe aumentarse.
• Response → Never Error — no cae todo el flujo de trabajo en el primer 403, permite manejar el código de respuesta mediante bifurcaciones.
• Pagination — modos Update a Parameter y Response Contains Next URL en lugar de ciclos hechos a mano.

A nivel de instancia, el ritmo está limitado por N8N_CONCURRENCY_PRODUCTION_LIMIT (por defecto -1, es decir, sin límite) — un valor razonable protegerá tanto el pool de proxies como el servidor mismo. Más información sobre cómo las plataformas cuentan tus solicitudes y qué hacer con los límites, está en el análisis de cómo eludir la limitación de tasa a través de proxies.

Qué proxies elegir para n8n

La elección no depende de "qué tan buenos" son, sino de quién está en el otro extremo.

• De centros de datos. Baratos y rápidos. Son adecuados para APIs oficiales, servicios internos, sitios amigables con bots y cualquier tarea donde se necesite simplemente una dirección estática y estable — por ejemplo, para que tu IP sea incluida en la lista blanca de un socio. En plataformas protegidas, devuelven exactamente el mismo 403 que un VPS desnudo: sus rangos son conocidos. Esta es la base para tareas por lotes sin anti-bots.
• Residenciales. Direcciones de proveedores domésticos reales — lo que se necesita para la recolección de datos de sitios con protección seria, para contenido dependiente de la geolocalización y monitoreo de precios. Para flujos de trabajo que navegan por sitios públicos, los proxies residenciales son el valor por defecto: elige rotación por solicitud para scraping masivo y sesiones fijas cuando necesites mantener una sesión en una cadena de nodos.
• Móviles. El nivel más alto de confianza: detrás de un operador hay miles de suscriptores reales, bloquear una IP así es costoso para la plataforma. Son justificables donde el corte es más severo — trabajo con redes sociales y mensajeros. A cambio, pagas por velocidad y precio.

Un esquema práctico en un flujo de trabajo mixto: APIs oficiales — directamente o a través de proxies de centros de datos, sitios públicos — a través de proxies residenciales, redes sociales — a través de proxies móviles. La opción Proxy se configura en cada nodo por separado, por lo que se puede combinar todo esto en un solo escenario sin complicaciones.

Lista de verificación antes de lanzar

1. Proxy establecido — ya sea como opción Proxy en el nodo, o a través de HTTPS_PROXY; en Cloud solo está disponible la primera opción.
2. Se han verificado ambos registros de variables — las minúsculas anulan a las mayúsculas.
3. NO_PROXY cubre localhost, la base de datos y hosts internos.
4. User-Agent reemplazado: N8N_ENFORCE_GLOBAL_USER_AGENT=true o encabezado propio en el nodo. Además, verifica la coherencia de los demás encabezados — un conjunto incoherente de headers puede delatar la automatización tan bien como el propio User-Agent.
5. Batching activado con un intervalo diferente de cero.
6. Se ha realizado una prueba con 3–5 elementos, no con toda la lista.

Conclusión

El 403 en n8n casi siempre no es una sola razón, sino la suma de tres: un User-Agent reconocible, una IP de centro de datos y un ritmo de solicitudes demasiado uniforme. Esto también se soluciona con un conjunto de medidas, no con un solo ajuste: cambiar el UA, dirigir el tráfico a través del proxy adecuado y ralentizar el nodo mediante Batching. Los tres mecanismos ya están integrados en la plataforma — solo es necesario encontrarlos y activarlos.

Es más fácil comenzar con un canal residencial en los nodos más problemáticos y uno de centro de datos en los demás: el pago en ProxyCove se realiza por tráfico, por lo que para pruebas puedes tomar un volumen mínimo y ver cómo se comporta tu flujo de trabajo específico. Seleccionar un proxy para la tarea y colocar la cadena en el campo Proxy es cuestión de minutos.