Proxies en n8n y Make: Guía de Integración Completa

Por qué usar proxies en n8n y Make

Si llevas tiempo montando automatizaciones web, esto ya te habrá pasado: un día el flujo funciona, y al siguiente empiezan los bloqueos de IP, captchas, límites de peticiones. Integrar proxies en n8n y en Make (antes Integromat) es la forma más eficaz de que tus flujos de scraping, monitorización de precios o publicación automatizada sigan funcionando sin sustos. Aquí va el proceso paso a paso, con ejemplos reales y algún consejo de seguridad que aprendí por las malas.

Tanto n8n como Make son plataformas potentes, sí. Pero sus nodos HTTP lanzan las peticiones desde las IP de sus servidores. Y cuando el volumen crece, los sitios de destino detectan ese patrón y bloquean. Un proxy dedicado (como los de ProxySEO, con IP española, tráfico ilimitado y soporte HTTP/s y SOCKSv5) te deja rotar la identidad de salida y mantener todo operativo.

Qué necesitas antes de empezar

Nada complicado. Solo esto:

Un proxy dedicado: evita los compartidos; con uno dedicado (como los de ProxySEO) esa IP es solo tuya, y reduces bastante el riesgo de acabar en una blacklist.
Credenciales de acceso: usuario, contraseña, IP o host del proxy y puerto (por ejemplo, proxy.proxyseo.es:8080).
El protocolo adecuado: HTTP/s para tráfico web estándar, SOCKSv5 si necesitas más flexibilidad (tráfico no HTTP, por ejemplo).
Acceso a tu instancia de n8n (mejor self-hosted, porque en n8n Cloud hay limitaciones para proxies a nivel de instancia) o a tu cuenta de Make.

Consejo: usa siempre proxies dedicados con autenticación por usuario y contraseña. Los proxies abiertos y gratuitos registran tu tráfico y comprometen las credenciales de tus APIs y cuentas. De verdad, no lo hagas.

Cómo configurar proxies en n8n

Opción 1: Variable de entorno global (self-hosted)

¿Ejecutas n8n en tu propio servidor o en Docker? Pues la vía más directa es definir las variables de entorno HTTP_PROXY y HTTPS_PROXY, que n8n respeta para todas las peticiones salientes:

HTTP_PROXY=http://usuario:contraseña@proxy.proxyseo.es:8080
HTTPS_PROXY=http://usuario:contraseña@proxy.proxyseo.es:8080

En Docker, añádelas en la sección environment de tu docker-compose.yml. Ojo con un detalle: esto aplica el proxy a todo el tráfico de la instancia, incluidas las llamadas a webhooks internos. Valora si necesitas excluir rangos con NO_PROXY. Un descuido aquí te puede romper media instancia sin que sepas por qué.

Opción 2: Proxy por nodo HTTP Request

Para control más fino, mejor no depender del proxy global y pasar el proxy solo donde haga falta. Dos caminos habituales:

Usar el nodo HTTP Request con opción de proxy: en versiones recientes de n8n, el nodo permite configurar autenticación y, mediante parámetros adicionales, dirigir la petición a través de un proxy.
Llamar a una librería con Code node: en un nodo de código (con axios o got y el paquete https-proxy-agent), construyes la petición a mano.

Con axios, por ejemplo: instancias el agente con new HttpsProxyAgent(‘http://usuario:contraseña@proxy.proxyseo.es:8080’) y lo pasas en la opción httpsAgent. La ventaja es clara: puedes usar proxies dedicados distintos según el flujo, o incluso rotar entre varias IP españolas para repartir la carga.

Dato útil: si tu flujo hace scraping intensivo, combina proxies dedicados con un nodo Wait entre peticiones (1-3 segundos) y cabeceras User-Agent realistas. Reducirás drasticamente los captchas.

Cómo usar proxies en Make

Aquí la cosa cambia. Make vive en la nube, así que no puedes instalar un proxy a nivel de plataforma como en n8n self-hosted. ¿Alternativas? Hay varias.

Opción 1: Servicios intermedios con soporte de proxy

Usa módulos como HTTP → Make a request apuntando a un servicio intermedio propio (un endpoint en tu VPS con Scrapy, Puppeteer o una API de scraping, algo pequeño) que a su vez tire de tus proxies dedicados de ProxySEO. Make orquesta; las peticiones salen por tu IP española.

Opción 2: Webhooks hacia n8n o un worker propio

Un patrón muy habitual, y con buena razón: Make detecta el trigger (nuevo dato en Sheets, un formulario…), envía un webhook a n8n self-hosted, y n8n ejecuta la parte que requiere proxy con la configuración de antes. Lo mejor de ambos mundos: la comodidad de las apps de Make y el control de red de n8n.

Opción 3: Proxies residenciales vía módulos HTTP de terceros

Algunos conectores premium permiten definir proxies directamente. Revisa la documentación del módulo concreto que uses; en Make, el módulo HTTP genérico no expone configuración de proxy de forma nativa. Por eso existe la recomendación del intermediario.

Integración con agentes IA y MCP

Cada vez más flujos combinan n8n o Make con agentes de IA que navegan, extraen datos o interactúan con webs. Si tu agente usa el protocolo MCP (Model Context Protocol) para acceder a herramientas de navegación o fetching, puedes configurar el proxy en la capa del servidor MCP: todas las herramientas expuestas al agente heredarán la salida por tu IP dedicada. Importante, porque evita que el agente queme la IP de tu servidor o exponga tu infraestructura.

ProxySEO soporta este tipo de integraciones sin complicación: al ser proxies HTTP/s y SOCKSv5 con autenticación estándar, cualquier cliente MCP, SDK o framework de agentes los acepta sin código adicional.

Buenas prácticas de seguridad y mantenimiento

Nunca guardes credenciales en el flujo: usa las variables de entorno de n8n o las credenciales cifradas del nodo.
Monitoriza la salud del proxy: un flujo que cada hora consulte un endpoint de chequeo de IP y te avise por Slack o email si la IP de salida cambia o falla. Sencillo y salva vidas (de automatizaciones, digo).
Rota entre varias IP dedicadas en flujos de scraping de alto volumen: repartir peticiones reduce el riesgo de bloqueos temporales.
Respeta robots.txt y los términos de uso de los sitios que automatizas; el proxy no te exime de la responsabilidad legal.
Registra los errores HTTP 403/429 en un almacén de datos para detectar patrones de bloqueo a tiempo.

Errores comunes al configurar proxies en n8n y Make

Credenciales mal codificadas: si tu contraseña lleva caracteres especiales (@, :, /), codifícalos en URL (la @ pasa a ser %40, por ejemplo).
Proxy HTTP para tráfico HTTPS sin soporte CONNECT: comprueba que tu proveedor soporta túneles HTTPS; los dedicados de ProxySEO lo hacen de serie.
Olvidar el NO_PROXY: en n8n self-hosted, si aplicas proxy global, excluye localhost y rangos internos. Si no, romperás los webhooks.
Usar proxies compartidos para login: si automatizas inicios de sesión, una IP compartida previamente abusada provocará verificaciones de seguridad constantes. Insufrible.

Conclusión

Integrar proxies en n8n y Make es más fácil de lo que parece, y marca la diferencia entre una automatización que se cae cada dos días y otra que aguanta a escala. En n8n self-hosted tienes control total mediante variables de entorno o configuración por nodo; en Make, el patrón del intermediario o del webhook hacia n8n resuelve la limitación nativa. Y si trabajas además con agentes IA, enrutar el tráfico de tus servidores MCP por proxies dedicados añade una capa extra de privacidad y estabilidad.

Mi recomendación: elige siempre proxies dedicados, con IP española si tu público o los sitios que automatizas son españoles. ProxySEO ofrece proxies HTTP/s y SOCKSv5 dedicados, anónimos, con tráfico ilimitado y soporte especializado para montar esta infraestructura en minutos. Empieza con un solo flujo. Valida resultados. Y escala con confianza.