¿Webhook de n8n funciona en pruebas pero está en silencio en producción? Así encuentra la causa: activación, WEBHOOK_URL, conflictos de ruta.
Un webhook de n8n que se dispara de forma fiable en pruebas pero deja de recibir solicitudes en producción casi siempre tiene una de estas tres causas: el workflow no se activó, por lo que la URL de producción nunca se registró; la variable de entorno WEBHOOK_URL está mal configurada o no se ha definido detrás de un reverse proxy; o hay una confusión entre la URL de prueba y la URL de producción, que n8n emite por separado para cada nodo webhook. La búsqueda del error sigue lógicamente un orden fijo: primero comprobar cuál de las dos URL está registrada en la aplicación externa, después el estado de activación del workflow, y luego la configuración del proxy y de las variables de entorno. Estado: julio de 2026.
n8n crea dos URL independientes para cada nodo webhook que se comportan de forma diferente a nivel técnico. La URL de prueba solo se activa cuando hace clic en "Listen for test event" en el editor, y según la documentación de n8n permanece lista para recibir solo durante 120 segundos, mostrando los datos entrantes directamente en el editor. La URL de producción, en cambio, solo se registra cuando el workflow se publica y se activa. Después funciona de forma permanente, pero ya no muestra los datos entrantes en el editor, solo en la pestaña Executions. Quien conecte por error una aplicación externa, como un CRM, una herramienta de formularios o una plataforma de pago, a la URL de prueba dejará de recibir respuestas a más tardar tras 120 segundos, aunque todo funcionara en las pruebas.
El motivo más frecuente de un webhook de producción silencioso es un workflow que no está activado. La URL de producción solo se registra cuando guarda el workflow y lo publica mediante el interruptor de activación en el editor; solo entonces n8n acepta solicitudes en esa dirección. Si el workflow se edita más tarde, se desactiva para hacer pruebas o se apaga por accidente, la URL de producción desaparece sin previo aviso, sin ningún mensaje de error para la aplicación externa; la llamada simplemente no llega a ningún sitio. Por eso, compruebe primero el estado de activación arriba a la derecha en el editor de workflows antes de investigar más a fondo la configuración del proxy o de la red.
Un segundo motivo, notado con menos frecuencia, está en la asignación de ruta y método. Según la documentación, n8n solo permite el registro de un único webhook por cada combinación de ruta y método HTTP; si dos workflows activos están configurados con la misma ruta, el que se registró primero bloquea al segundo. Un método HTTP incorrecto también provoca errores: por defecto, un nodo webhook solo acepta GET o POST, no ambos a la vez, a menos que active la opción "Allow Multiple HTTP Methods" en la configuración del nodo. Si el servicio externo cambia su método de solicitud, la conexión se interrumpe sin ningún mensaje de error reconocible en el workflow.
Cuando n8n está autoalojado y se ejecuta detrás de un reverse proxy como Nginx, Traefik o Caddy, una WEBHOOK_URL mal configurada es la causa técnica más frecuente. n8n normalmente construye la dirección del webhook automáticamente a partir de las variables N8N_PROTOCOL, N8N_HOST y N8N_PORT; según la documentación de n8n esto no funciona detrás de un proxy, porque n8n se ejecuta internamente en el puerto 5678, mientras que el proxy expone la aplicación externamente a través del puerto 443. Por eso debe configurar WEBHOOK_URL manualmente, además de fijar la variable N8N_PROXY_HOPS con el número de proxies situados delante y transmitir en el último proxy las cabeceras X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Si falta N8N_PROXY_HOPS, las reglas de lista blanca de IP para webhooks también pueden fallar, porque n8n no detecta correctamente la IP real del remitente. Para las empresas que no quieren mantener ellas mismas esta configuración de forma continua, NordFlux se encarga de la configuración del servidor y del proxy como parte de un proyecto a precio fijo dentro de su servicio de automatización con n8n.
Antes de entrar en el detalle, ayuda una comparación rápida de las cuatro causas más probables en un orden lógico.
Solo cuando se hayan confirmado los cuatro puntos y el webhook siga sin responder merece la pena buscar en las reglas del firewall, en las entradas DNS o con el proveedor de hosting.
Probablemente porque todavía se está usando la URL de prueba: permanece lista para recibir solo 120 segundos después de hacer clic en "Listen for test event". Para un funcionamiento permanente necesita la URL de producción, que solo se registra tras activar el workflow. Sustituya la URL registrada y compruebe el estado de activación en el editor.
Sí, la URL de producción solo se registra cuando el workflow se ha guardado y activado, es decir, publicado. Sin este paso, n8n no acepta ninguna solicitud en esa dirección, incluso si el workflow ya funcionaba sin errores en las pruebas. Después de cada cambio de contenido en el nodo webhook, debe volver a guardar el workflow y comprobar la activación.
No, n8n solo registra un webhook por cada combinación de ruta y método HTTP. Si un segundo workflow activo está configurado con la misma ruta y el mismo método, el workflow registrado primero bloquea al segundo. En ese caso, asigne rutas únicas o desactive el workflow que ya no sea necesario.
Configure manualmente la variable de entorno WEBHOOK_URL con el dominio accesible públicamente, ya que de lo contrario n8n construye la dirección internamente a partir del protocolo, el host y el puerto, usando el puerto interno 5678 en lugar de la dirección pública. Además, configure N8N_PROXY_HOPS con el número de proxies situados delante y asegúrese de que el último proxy transmite las cabeceras X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Tras el cambio, n8n debe reiniciarse.
Fundador de NordFlux. Siete años de experiencia, desde la web y el SEO hasta la automatización a escala de grupo, hoy de forma pragmática para las pymes y con soberanía de datos alemana.
Certificaciones
n8n también funciona vía Docker en la Raspberry Pi (ARM64). Explicado con honestidad: para qué es suficiente el hardware y dónde la RAM y la CPU alcanzan sus límites con los workflows de IA.
Las variables de entorno de n8n más relevantes en la práctica para instalaciones autoalojadas alemanas: host, URL de webhook, zona horaria, seguridad y base de datos de un vistazo.
Resumen de todos los tipos de trigger de n8n: Schedule, Webhook, Polling, Manual y Chat, incluyendo recomendación de uso para cada escenario.
El estado de activación, los conflictos de ruta y la WEBHOOK_URL detrás del reverse proxy son las trampas clásicas cuando un webhook funciona en pruebas pero queda en silencio en producción. NordFlux se encarga de la operación gestionada de n8n, incluyendo configuración de webhooks, montaje del reverse proxy y monitorización continua, para que sus procesos de producción no dependan de una mala configuración silenciosa. En la primera conversación revisamos su cadena de webhook, desde la URL hasta la activación.
