2ª solicitud HTTP secuencial en la misma ejecución falla con ECONNREFUSED, independientemente del destino

Preguntas
1

En mi instancia de Cloud (die.app.n8n.cloud), cuando encadeno 2+ nodos HTTP Request secuencialmente en la misma ejecución de flujo de trabajo, el primero siempre tiene éxito, pero el segundo siempre falla con ECONNREFUSED.
Esto ocurre incluso cuando las dos solicitudes apuntan a dominios completamente no relacionados — lo confirmé dirigiendo la segunda solicitud a https://jsonplaceholder.typicode.com/posts (una API de prueba pública, no relacionada con mi caso de uso principal), y aun así falló de la misma manera, con la IP correcta de Cloudflare resuelta (188.114.96.3) pero conexión rechazada.
Versión de n8n: 2.31.5 (Cloud)
Tipo de nodo: HTTP Request, versión 4.2
Error: NodeApiError: El servicio rechazó la conexión - quizás está sin conexión / connect ECONNREFUSED [ip]:443

Describe el problema/error/pregunta

¿Cuál es el mensaje de error (si lo hay)?

Por favor, comparte tu flujo de trabajo

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)

Comparte el resultado devuelto por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (predeterminado: SQLite):
  • Configuración EXECUTIONS_PROCESS de n8n (predeterminado: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:
2

Hola @Dorian_BRIANCON, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@Buggy_Arbor, @MutedJam - ya han ayudado con problemas similares antes, ¿pueden echarle un vistazo?

Sugerido automáticamente por el bot de comunidad de n8n. Es un piloto - comparte tu opinión aquí.

3

¡Hola @Dorian_BRIANCON! ¡Bienvenido!
ECONNREFUSED es un reinicio activo de TCP en la conexión, no un tiempo de espera o un bloqueo de cortafuegos, y el edge de Cloudflare no rechaza el 443 desde n8n Cloud. La solicitud no sale de donde crees que lo hace, lo que apunta al nodo en lugar de la ejecución. Verifica Options en el nodo que falla para una entrada Proxy. Un proxy configurado allí anula todo lo demás y rechaza en la conexión sin importar qué host apuntes, mientras que el error aún imprime la IP de destino resuelta, que coincide con lo que viste con jsonplaceholder.
Para confirmar que es el nodo y no la posición, intercambia los dos nodos HTTP Request para que el que falla se ejecute primero. Si el fallo sigue al nodo, es la configuración de ese nodo. Si se queda en la segunda posición, es del lado de la instancia, así que envía a help@n8n.io el ID de ejecución y la marca de tiempo de una ejecución fallida.

4

Hola @Dorian_BRIANCON

ECONNREFUSED generalmente indica un rechazo a nivel de red. Como ocurre en dominios no relacionados y solo en el segundo nodo secuencial, probablemente no sea un problema de DNS o del servidor de destino, sino un agotamiento de sockets o conflicto en el pooling de conexiones dentro del contenedor de ejecución específico asignado a tu instancia de Cloud.

La causa más común de ECONNREFUSED secuencial en entornos compartidos es la apertura y cierre rápido de sockets. Agregar un pequeño retraso entre solicitudes generalmente limpia el estado del socket.

  • Acción: Inserta un nodo Wait entre el primer y segundo nodo HTTP Request.
  • Configuración: Establece el tiempo de espera en 1 o 2 segundos​.
  • Por qué: Esto permite que el event loop de Node.js subyacente y el proxy de red de la instancia de Cloud liberen completamente la conexión anterior antes de intentar la siguiente.

Si estás procesando una lista de elementos, evita encadenar nodos HTTP en una secuencia lineal. En su lugar, usa un nodo Split In Batches o un Loop para manejar las solicitudes.

  • Acción:
    1. Usa un nodo Split In Batches (Batch Size: 1).
    2. Coloca el nodo HTTP Request dentro del loop.
    3. Vuelve al nodo Split In Batches.
  • Por qué: Esto obliga a n8n a manejar la ejecución en fragmentos distintos, lo que puede prevenir la “acumulación” de intentos de conexión que desencadena el rechazo.

Si las solicitudes están vinculadas lógicamente, puedes evitar la sobrecarga de múltiples envoltorios de nodos de n8n usando un único nodo Code con axios o fetch.

  • Acción: Reemplaza los dos nodos HTTP Request con un nodo Code.
  • Fragmento:
const axios = require('axios');

const res1 = await axios.get('https://api.first.com/data');
const res2 = await axios.get('https://jsonplaceholder.typicode.com/posts');

return {
  firstRequest: res1.data,
  secondRequest: res2.data
};
  • Por qué: Esto utiliza un único contexto de proceso Node.js para ambas solicitudes, que es significativamente más eficiente que el traspaso de nodo a nodo de n8n.

¿Te ayuda?

6

Hola,

Una rápida actualización: la solución que funcionó fue reemplazar completamente los nodos HTTP Request con un nodo Code usando this.helpers.httpRequest para las llamadas secuenciales, envuelto en un bucle await con un retraso de 1s entre solicitudes. Esto ejecutó 5 solicitudes GET secuenciales al mismo dominio (100 elementos cada una, ~423 elementos en total) exitosamente en la misma ejecución — sin ECONNREFUSED.

Así que para delimitarlo aún más: el bug parece ser específico del nodo HTTP Request en sí (v4.2, probablemente vinculado a sus internals basados en request heredados como se menciona en el stack trace — useStream, resolveWithFullResponse, etc.), no de la capa de redes de n8n Cloud en su totalidad. this.helpers.httpRequest desde dentro de un nodo Code utiliza lo que asumiría es el mismo cliente HTTP subyacente, sin embargo funcionó perfectamente cada vez — por lo que posiblemente el problema está específicamente en cómo el nodo HTTP Request (como nodo visual independiente) gestiona su estado de conexión/socket entre ejecuciones separadas de nodos en la misma ejecución de flujo de trabajo, en lugar de ser un problema a nivel de redes/instancia.

Esto podría ayudarte a reproducir/aislarlo: no se trata del destino, la carga útil o el tiempo — es específicamente sobre encadenar 2+ nodos HTTP Request (el nodo visual) secuencialmente. Envolver la misma lógica en un único nodo Code lo evita completamente.

Espero que esto ayude a delimitar la causa raíz para otros que se encuentren con el mismo obstáculo. ¡Gracias por la orientación!

7

Dos puntos en las respuestas merecen separarse. Un nodo Wait puede ser útil como experimento, pero no prueba que Node.js necesitara tiempo para liberar un socket. Estos nodos HTTP ya se ejecutan secuencialmente. Mover las llamadas a un nodo Code no es una opción en n8n Cloud tampoco. El nodo Cloud Code no puede realizar solicitudes HTTP ni importar axios.

Reduciría esto a un flujo de trabajo mínimo con un Manual Trigger y dos nodos HTTP Request. Apunta ambos nodos de solicitud al mismo endpoint HTTPS público estable e dale la misma configuración. Ejecuta primero el segundo nodo solo. Luego conecta la primera solicitud a la segunda y repite invirtiendo su orden.

Si el fallo se queda con un nodo, compara sus Options y credenciales contra la copia que funciona. Si alguno de los nodos falla solo cuando se ejecuta segundo, guarda el ID de ejecución con su marca de tiempo y envía el flujo de trabajo mínimo al soporte de Cloud. Eso aísla la posición de ejecución del destino y de tu API original.

La IP resuelta de Cloudflare te dice que DNS tuvo éxito. ECONNREFUSED significa que la conexión TCP fue rechazada activamente. Un retraso puede ocultar el síntoma, pero no explica un fallo determinista de segunda solicitud.

Referencia de errores de n8n: Common Issues | Nodes | n8n Docs

Límites del nodo Cloud Code de n8n: Code | Nodes | n8n Docs