Web scraping con n8n: HTTP Request y ajustes de proxy

Publicado:

22 min de lectura

Acar Diveroli
Autor: Acar Diveroli
Marco de esquinas en cruz: logo de Proxynet, un aspa y el de n8n, sobre filas de IP tenues; etiqueta INTEGRATION

El flujo de trabajo que montaste en n8n abre cada mañana diez páginas de producto y escribe los precios en una hoja. La primera semana no hay problemas. Luego la lista sube a doscientos productos, el flujo empieza a enviar peticiones una tras otra desde la única dirección IP de tu servidor y el nodo HTTP Request se pone en rojo: primero 429, después 403. O el caso contrario: la API de destino muestra el precio correcto solo a las peticiones que llegan de un país concreto, y tu servidor de n8n está en otro. En ambos casos el ajuste que buscas es el mismo: hacer que las peticiones salientes de n8n pasen por un proxy.

En este artículo explicamos los dos lugares donde se define un proxy en n8n: la opción Proxy del nodo HTTP Request y las variables de entorno de una instalación self-hosted. Vemos por orden cómo se escriben las credenciales en la dirección, qué ajuste prevalece sobre cuál, la diferencia entre n8n Cloud y tu propio servidor y los errores más habituales. También separamos el tema del proxy inverso (reverse proxy), que es lo que en realidad busca parte de quienes escriben "n8n proxy". El flujo de ejemplo sigue precios en un sitio publicado para practicar.

¿Qué es n8n y dónde encaja en el scraping?

n8n es una herramienta de automatización en la que montas flujos de trabajo uniendo cajas (nodos, "nodes" en inglés) con líneas. Un nodo disparador inicia el flujo (programador, webhook, formulario) y los nodos siguientes obtienen los datos, los transforman y los escriben en algún sitio. Puedes usar la herramienta en la nube de n8n (n8n Cloud) o instalarla en tu propio servidor (self-hosted). Esta distinción es decisiva en el tema del proxy.

En el lado del scraping, el trabajo lo hacen dos nodos. El nodo HTTP Request envía una petición a una dirección y recibe la respuesta; el nodo HTML extrae de esa respuesta los campos que quieres mediante selectores CSS. Esta pareja funciona bien en páginas cuyo contenido llega listo desde el servidor y en APIs que devuelven JSON. En páginas cuyo contenido se genera en el navegador con JavaScript, HTTP Request solo ve un esqueleto vacío; explicamos la diferencia en Páginas estáticas y dinámicas. Para escribir selectores, consulta Selector CSS o XPath.

El punto fuerte de n8n es lo que se hace después con los datos: escribirlos en una hoja, compararlos con el valor anterior, avisar cuando cambian. No es la herramienta adecuada para un rastreo de miles de páginas; a esa escala hace falta un framework como Scrapy o una infraestructura de extracción de datos. En Cómo extraer datos de una web comparamos qué método basta en cada caso.

"n8n proxy" son dos temas distintos: ¿cuál buscas?

En las sugerencias de búsqueda, junto a "n8n proxy" aparecen también las palabras proxy hops, nginx y reverse. No tienen que ver con el ajuste del que trata este artículo:

Proxy directo (forward proxy)Proxy inverso (reverse proxy)
Sentido del tráficoPeticiones que salen de n8nPeticiones que llegan a n8n
Para qué sirveDetermina la dirección IP y el país desde el que sale la peticiónPublica n8n con un dominio y HTTPS
Herramienta típicaEl endpoint del proveedor de proxiesnginx, Caddy, Traefik
Ajuste en n8nHTTP Request → Proxy, HTTP_PROXY, HTTPS_PROXYN8N_PROXY_HOPS, variable de la URL del webhook
Síntoma407, ECONNREFUSED, 403 / 429 en el sitio de destinoLa URL del webhook aparece como localhost, IP de cliente incorrecta

Si ejecutas n8n detrás de nginx, la página de la documentación de n8n sobre la configuración de la URL del webhook detrás de un proxy inverso pide dos cosas: poner N8N_PROXY_HOPS en 1 (el valor por defecto es 0 e indica cuántos proxies inversos hay delante de n8n) y que el último proxy de la cadena reenvíe las cabeceras X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Estos ajustes no afectan en absoluto a tus peticiones salientes. La diferencia entre ambos conceptos y un ejemplo con nginx están en Forward proxy y reverse proxy. El resto del artículo trata del proxy directo.

¿Cómo se define el proxy en el nodo HTTP Request?

El ajuste no está entre los campos principales del nodo, sino en la sección Options, al final del todo; por eso no se ve a primera vista.

  1. Abre el nodo HTTP Request en tu flujo y rellena los campos Method y URL.
  2. En la sección Options, al final de los parámetros, pulsa Add option.
  3. Añade la opción Proxy de la lista.
  4. Escribe en el campo nuevo la dirección del proxy, esquema incluido: http://user:pass@pr.proxynet.io:8000
  5. Ejecuta el nodo por separado con Execute step y revisa la salida.

El texto de ejemplo del campo es e.g. http://myproxy:3128; es decir, n8n espera aquí una URL completa. En la versión actual que instalamos en local para este artículo, una dirección escrita sin esquema (user:pass@pr.proxynet.io:8000) no dio error: la petición salió directamente, sin pasar por el proxy. Con una dirección que empieza por socks5:// el resultado fue el mismo: el campo es para proxies HTTP. La documentación del nodo HTTP Request dice claramente que esta opción tiene prioridad sobre el ajuste global hecho con HTTP_PROXY, HTTPS_PROXY y ALL_PROXY. Así, aunque tu servidor tenga definido un proxy corporativo, puedes sacar un solo nodo por otro endpoint.

¿Dónde se escriben el usuario y la contraseña?

El nodo no tiene un campo aparte de usuario o contraseña para el proxy. Las credenciales se escriben dentro de la dirección, con la forma usuario:contraseña@. La sección Authentication del nodo va al sitio de destino, no al proxy; escribir ahí la contraseña del proxy no resuelve un 407.

Si tu contraseña contiene caracteres como @, :, / o #, la dirección se parte por donde no debe. Escríbelos con codificación porcentual: %40 en lugar de @, %3A en lugar de :. En nuestra prueba local, la contraseña pa@ss:1 escrita como pa%40ss%3A1 se interpretó bien en el proxy. El detalle de los dos métodos de autenticación está en Autenticación de proxy: user:pass o lista blanca de IP.

Una nota de seguridad: el campo Proxy es texto plano y no entra en el almacén cifrado de credenciales de n8n (Credentials). Cuando exportas el flujo como JSON y lo compartes, la contraseña del proxy viaja dentro del archivo; vacía el campo antes de compartirlo.

¿Se puede usar una lista de IP autorizadas en n8n?

Para un n8n en tu propio servidor con dirección IP fija, sí: añades la IP del servidor a la lista de IP autorizadas en tu panel de proxy y la dirección se escribe sin contraseña, http://pr.proxynet.io:8000. En n8n Cloud este método no es fiable. En la página de su documentación sobre las direcciones IP de Cloud, n8n dice que las IP de salida no son fijas y pueden cambiar sin previo aviso. La dirección que autorizas hoy puede dejar de valer mañana. En Cloud, conéctate con usuario y contraseña.

¿Cómo se usan las variables de entorno en una instalación self-hosted?

En lugar de escribir el proxy nodo por nodo, puedes definir uno para todo el proceso de n8n. La página de variables de entorno de despliegue de n8n enumera cuatro variables:

VariableFunción
HTTP_PROXYEl tráfico HTTP sin cifrar que sale de los nodos pasa por esta dirección
HTTPS_PROXYEl tráfico con TLS (HTTPS) que sale de los nodos pasa por esta dirección
ALL_PROXYSe usa para ambos si las dos variables más específicas no están definidas
NO_PROXYLista separada por comas de hosts a los que se conecta directamente, sin proxy

En una instalación con Docker Compose, las variables se añaden a la sección environment del servicio:

yaml
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - HTTP_PROXY=http://user:pass@pr.proxynet.io:8000
      - HTTPS_PROXY=http://user:pass@pr.proxynet.io:8000
      - NO_PROXY=localhost,127.0.0.1,postgres,redis

Que el valor de HTTPS_PROXY empiece por http:// no es una errata: el nombre de la variable no indica el esquema del proxy, sino qué tráfico irá hacia él. En Proxy con wget explicamos cómo se definen estas variables en el sistema operativo; aquí solo tocamos tres trampas propias de n8n.

La variable en minúsculas se impone a la de mayúsculas. La misma página de la documentación señala que en el paquete proxy-from-env que usa n8n, los nombres en minúsculas como http_proxy tienen prioridad sobre los de mayúsculas cuando ambos están definidos. Si otra persona puso una variable en minúsculas en tu imagen de Docker o en tu servidor, tu valor de HTTP_PROXY se ignora en silencio. Dentro del contenedor, revisa las dos con env | grep -i proxy.

No dejes vacía la lista NO_PROXY. Si n8n también habla por HTTP con la base de datos de la misma red, con Redis o con una API interna, esas peticiones irán igualmente al proxy y lo más probable es que se queden atascadas allí. Añade a la lista los nombres de host internos y localhost.

No todos los nodos respetan estas variables. Los nodos que usan el asistente HTTP propio de n8n ven el ajuste. En algunos nodos que traen su propia biblioteca cliente hay incidencias que indican que la variable no se tiene en cuenta (por ejemplo, la incidencia #19652 del repositorio de n8n se abrió en 2025 para el nodo RSS Read y se cerró después). Antes de poner en producción un nodo crítico, pruébalo con el paso de verificación de más abajo.

Las variables se leen al arrancar el proceso de n8n; después de cambiarlas tienes que reiniciar el contenedor o el servicio.

n8n Cloud y self-hosted: ¿qué vía está abierta en cada caso?

n8n CloudSelf-hosted (Docker, npm)
HTTP Request → opción ProxyDisponibleDisponible
HTTP_PROXY / HTTPS_PROXYNo se pueden definir, porque el entorno del servidor no es tuyoSe definen y afectan a todo el proceso
Proxy con lista de IP autorizadasNo recomendado: las IP de salida cambian sin previo avisoFunciona en un servidor con IP fija
IP de salida sin proxyDirecciones variables de la infraestructura en la nube de n8nLa dirección de tu propio servidor

Si usas Cloud, tu única vía es la opción del nodo. En una instalación self-hosted están abiertas las dos; puedes pensar en la variable de entorno como la "salida por defecto" y en la opción del nodo como "que esta petición salga por otro sitio".

Flujo de ejemplo: seguir el precio de un producto

Montamos el ejemplo sobre books.toscrape.com, un sitio publicado para practicar scraping. En tu propio trabajo, mira primero si el sitio de destino tiene una API oficial o un panel de vendedor; si lo tiene, úsalo en vez de analizar HTML. Si no, lee el archivo robots.txt del sitio y sus condiciones de uso. Cómo se leen las reglas de robots.txt está en Qué es robots.txt.

El flujo tiene seis nodos:

  1. Schedule Trigger: inicia el flujo una vez al día. En el seguimiento de precios rara vez hace falta una consulta cada minuto.
  2. Lista de productos: toma las direcciones de una hoja de Google Sheets o de un nodo Edit Fields. Cada fila lleva un campo url.
  3. Loop Over Items: procesa la lista elemento a elemento. Deja Batch Size en 1.
  4. HTTP Request: escribe la expresión {{ $json.url }} en el campo URL, define el Proxy en Options y deja el formato como texto en la opción Response.
  5. HTML: elige Extract HTML Content como operación y define los campos que quieres extraer con selectores CSS.
  6. Wait: espera unos segundos y vuelve al inicio del bucle.

Cuando termina el bucle, escribes los datos en una hoja, los comparas con el precio del día anterior en un nodo If y envías un aviso si hay diferencia.

Así queda el nodo HTTP Request en el JSON del flujo exportado:

json
{
  "parameters": {
    "url": "={{ $json.url }}",
    "options": {
      "proxy": "http://user:pass@pr.proxynet.io:8000",
      "timeout": 20000,
      "response": {
        "response": { "fullResponse": true, "responseFormat": "text" }
      }
    }
  },
  "name": "HTTP Request",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4.2
}

En el nodo HTML, para este sitio bastan tres filas:

KeyCSS SelectorReturn Value
tituloh1Text
preciop.price_colorText
stockp.availabilityText

Activa Trim Values y Clean Up Text en Options; así se limpian los saltos de línea y los espacios sobrantes de la fila de stock. La salida es un texto como £51.77; para convertirlo en número tendrás que quitar el símbolo de moneda y corregir el separador decimal en el nodo siguiente.

Un montaje más completo, con emparejamiento de productos, historial de precios y alerta por umbral, está en Cómo hacer seguimiento de precios de la competencia, y la parte de producto en nuestra página de seguimiento de precios.

¿Cómo se montan el límite de velocidad y los reintentos en n8n?

Cuando n8n recibe una lista, si no le indicas otra cosa envía la petición de todos los elementos seguidas y sin esperar. Usar un proxy no vuelve cortés ese comportamiento; solo cambia la dirección desde la que salen las peticiones. La carga que ve el sitio de destino la tienes que limitar tú. La página "Handle rate limits" de la documentación de n8n muestra tres vías integradas:

  • Batching (HTTP Request → Options): con Items per Batch decides cuántas peticiones salen de una vez y con Batch Interval (ms) la espera entre lotes. Es la vía más corta y no requiere código.
  • Loop Over Items + Wait: el montaje que usamos en el ejemplo anterior. Ves de forma explícita la espera tras cada petición y puedes intercalar otros nodos.
  • Retry On Fail (pestaña Settings del nodo): reintenta la petición fallida; con Wait Between Tries (ms) indicas el tiempo entre intentos.

Activar Retry On Fail para cualquier error no es correcto. 429 y 503 se arreglan esperando; 403 y 407 no, y enviar la misma petición cinco veces solo genera tráfico innecesario. En la tabla de Códigos de estado HTTP en web scraping reunimos con qué códigos conviene reintentar y con cuáles parar; la lógica del límite de velocidad está en 429 Too Many Requests. Si quieres bifurcar según el código de estado, activa Include Response Headers and Status y Never Error en la opción Response del HTTP Request y después mira el campo statusCode en un nodo If.

¿Hace falta un nodo aparte o código para la rotación?

Algunas plantillas de scraping para n8n incluyen fragmentos de JavaScript que guardan una lista de proxies en un nodo Code y eligen el siguiente en cada petición. Si lo que tienes es una lista de direcciones IP sueltas, eso hace falta. Con un endpoint rotativo no: te conectas a una sola dirección como pr.proxynet.io:8000 y el proveedor cambia la IP de salida en cada conexión nueva. En el lado de n8n, la dirección del campo Proxy no cambia nunca. El detalle del mecanismo está en Qué es la rotación de IP y cómo funciona, y la parte de producto en la página de Proxies rotativos.

Al revés, también hay trabajos en los que la IP no debe cambiar nunca. Si la API de un socio solo acepta peticiones de direcciones autorizadas y usas n8n Cloud, salir por una dirección fija como Proxies ISP, en lugar de las IP variables de Cloud, resuelve el problema. Tratamos este escenario en IP estática para el acceso a API.

¿Cómo se usa un proxy en el nodo AI Agent?

Al nodo AI Agent de n8n le puedes conectar HTTP Request como herramienta (tool); el modelo la llama cuando hace falta para leer una página o una API. Un HTTP Request conectado como herramienta tiene la misma sección Options, así que la opción Proxy funciona aquí igual. La documentación añade una opción más para este uso: Optimize Response filtra los campos JSON o extrae solo el texto del HTML antes de pasar la respuesta al modelo, y reduce los tokens consumidos.

En un montaje con agente, fíjate en dos puntos. Limita en la definición de la herramienta las direcciones a las que puede ir el agente: en vez de dejar la URL entera en manos del modelo, define un dominio fijo y un parámetro de ruta que el modelo rellene. Las peticiones al proveedor del modelo de lenguaje, en cambio, no pasan por HTTP Request; para ponerlas detrás de un proxy hacen falta variables de entorno en una instalación self-hosted, y conviene probar aparte que el nodo del modelo respeta la variable. Cómo salen los agentes a la web lo explicamos en Agentes de IA: planificación, herramientas y memoria y Acceso web seguro para LLM. Para páginas que exigen un navegador real, consulta Playwright MCP.

¿Cómo se comprueba que el proxy funciona?

Como una dirección mal escrita puede ignorarse sin dar error, prueba siempre el ajuste:

  1. Pon dos nodos HTTP Request en un flujo vacío. La dirección de ambos será un servicio que devuelve la IP desde la que llegó la petición (por ejemplo https://api.ipify.org?format=json).
  2. En el primero deja vacía la opción Proxy; en el segundo, rellénala.
  3. Ejecuta los dos. El primer nodo debe mostrar la IP de tu servidor de n8n (o de Cloud) y el segundo la IP de salida del proxy. Si las dos direcciones coinciden, el proxy no está activo.
  4. Si usas variables de entorno, haz la misma prueba con un nodo con el campo Proxy vacío: si la IP cambió, la variable se está leyendo.

El detalle de los pasos está en Cómo probar un proxy.

Errores frecuentes y qué significan

ErrorDe dónde vieneCausa probableQué hacer
ECONNREFUSEDServidor de n8nPuerto del proxy incorrecto o un cortafuegos cierra la salidaCopia de nuevo la dirección desde el panel y revisa el permiso de salida a ese puerto
407 Proxy Authentication RequiredProxyContraseña incorrecta, carácter especial sin codificar o IP ausente de la lista autorizadaEscribe las credenciales dentro de la dirección y con codificación porcentual
400 Bad Request (solo en destinos HTTPS)ProxyEl cliente envía la petición al proxy tal cual en lugar de abrir un túnelActualiza n8n; mira la nota de abajo
ETIMEDOUT / ECONNRESETRedNo se llega al proxy o el destino es muy lentoSube el valor de Options → Timeout y elige una ubicación de salida más cercana
ENOTFOUNDDNSNombre de host del proxy mal escritoCopia el nombre desde el panel y vuelve a escribirlo
403 / 429 del destinoSitio de destinoEl proxy funciona; el problema es la velocidad o el tipo de IPFrena con Batching y Wait y diagnostica la causa

La fila del 400 cuenta una historia propia de n8n. El nodo HTTP Request usa por debajo la biblioteca Axios, y el soporte de proxy integrado de Axios es conocido por enviar la petición directamente al proxy en destinos HTTPS en lugar de abrir un túnel CONNECT. La incidencia #9169 del repositorio de n8n documenta que este comportamiento provocaba un 400 en el nodo. La incidencia es de 2024. En la versión actual que probamos, el nodo abrió un túnel CONNECT en el proxy para un destino HTTPS y obtuvo la página sin problemas. Si en una versión antigua de n8n las direcciones HTTP pasan por el proxy y las HTTPS devuelven 400, el primer paso es actualizar.

Si en el navegador ves el aviso de que el servidor proxy no responde, el problema no tiene que ver con n8n; consulta El servidor proxy no responde.

Casos de uso

  • Seguimiento de precios y stock: flujos que se ejecutan una vez al día y avisan cuando hay cambios. El montaje es el mismo del ejemplo anterior; la parte de producto está en nuestra página de seguimiento de precios.
  • Control de contenido que cambia según la ubicación: ejecutar el mismo nodo con proxies de salida en distintos países para comparar cómo se ve la misma página. Para una cobertura amplia de países se usan Proxies residenciales.
  • Recopilación de contenido a pequeña escala: titulares de noticias, número de anuncios, catálogos públicos. Cuando la escala crece, es más adecuado pasar a una solución de rastreador web.

Fallos habituales

  • Escribir la contraseña del proxy en la sección Authentication. Esa sección va al sitio de destino. Las credenciales del proxy van dentro de la dirección.
  • No escribir el esquema. Escribe http://pr.proxynet.io:8000 en lugar de pr.proxynet.io:8000; una dirección sin esquema puede ignorarse sin dar error.
  • Olvidar el límite de velocidad al añadir el proxy. Una lista de cien elementos, sin Batching ni Wait, envía cien peticiones a la vez.
  • Automatizar páginas que exigen inicio de sesión o contienen datos personales. Un proxy no vuelve legítimo un flujo que incumple las condiciones de la plataforma o la normativa de protección de datos; resumimos el marco legal en ¿El web scraping es legal?.

Guía de decisión

NecesidadRecomendación
Uso n8n Cloud y quiero que un solo nodo salga por el proxyHTTP Request → Options → Proxy, con usuario y contraseña
En n8n self-hosted quiero que todos los nodos salgan por el proxyHTTP_PROXY, HTTPS_PROXY, NO_PROXY; después, verificación nodo por nodo
Hay un ajuste global, pero un nodo debe salir desde otro paísOpción Proxy en ese nodo; prevalece sobre el ajuste global
Una IP distinta en cada peticiónEndpoint rotativo; no escribas la rotación en un nodo Code
La otra parte va a autorizar mi IPProxy con IP fija (ISP) o tu propio servidor con IP fija
La página carga con JavaScript y el nodo HTML devuelve vacíoHTTP Request no basta; automatización de navegador o el endpoint JSON que el sitio usa por detrás

Preguntas frecuentes

¿Se puede usar un proxy en n8n Cloud?

Sí, la opción Proxy del nodo HTTP Request también existe en Cloud; las variables de entorno, en cambio, no se pueden usar. Como las IP de salida de Cloud no son fijas, conéctate al proxy con usuario y contraseña y no con una lista de IP autorizadas.

¿Para qué sirve N8N_PROXY_HOPS?

Indica cuántos proxies inversos (nginx, Caddy, un balanceador de carga en la nube) hay delante de n8n; su valor por defecto es 0. No tiene relación con las peticiones salientes ni con el ajuste de proxy de este artículo.

¿Qué tiene prioridad, el ajuste Proxy del nodo o la variable de entorno?

El ajuste del nodo. Así lo dice la documentación de n8n; en nuestra prueba local, con la variable de entorno apuntando a un puerto cerrado, el nodo con la opción Proxy rellena salió por su propio proxy.

¿Zapier tiene el mismo ajuste?

No. El paso Webhooks de Zapier tiene campos de dirección, datos, cabeceras y autenticación básica; no hay campo de proxy. Para pasar la petición por un proxy tienes que poner en medio un pequeño servicio propio: Zapier llama a ese servicio y el servicio va al destino a través del proxy.

¿Tengo que guardar la contraseña del proxy en texto plano dentro del flujo?

Si usas la opción del nodo, sí: el campo es texto plano. En una instalación self-hosted, la forma de sacar la contraseña del flujo son las variables de entorno: las credenciales se quedan en la configuración del servidor y no entran en el JSON del flujo. Si tienes un servidor con IP fija, una lista de IP autorizadas elimina la contraseña por completo.

¿Se pueden extraer datos de cualquier sitio con HTTP Request?

No. El nodo no ejecuta JavaScript, así que en páginas cuyo contenido se genera en el navegador el campo que buscas no está en la respuesta. Los sitios con protección contra bots también pueden devolver una página de verificación, con proxy o sin él. En ese caso lo que corresponde no es forzar la protección, sino mirar la API oficial del sitio o sus opciones de acuerdo de datos.

En resumen

En n8n el proxy se define en dos lugares: el campo Proxy de la sección Options del nodo HTTP Request y las variables HTTP_PROXY, HTTPS_PROXY y NO_PROXY de una instalación self-hosted. Las credenciales se escriben dentro de la dirección, el ajuste del nodo prevalece sobre el global y N8N_PROXY_HOPS solo afecta a las instalaciones que están detrás de un proxy inverso. El proxy no sustituye al límite de velocidad: frena con Batching o Wait, espera cuando veas un 429 y elige la API oficial si existe. Puedes comparar los tipos de IP adecuados para tus flujos en la página de nuestros servicios de proxy.