El webhook funciona en pruebas pero no en producción: la checklist

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.

¿Por qué son distintas la URL de prueba y la URL de producción?

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.

¿Está realmente activado el workflow?

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.

¿Bloquea la solicitud un conflicto de ruta o de método?

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.

¿Está WEBHOOK_URL configurada correctamente detrás del reverse proxy?

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.

¿En qué orden se deben comprobar las causas?

Antes de entrar en el detalle, ayuda una comparación rápida de las cuatro causas más probables en un orden lógico.

• Tipo de URL: ¿Está realmente registrada la URL de producción en la aplicación externa, y no la URL de prueba?
• Activación: ¿Está activado el workflow en el editor y se guardó de nuevo tras el último cambio?
• Conflicto de ruta: ¿Ningún otro workflow activo utiliza la misma ruta y el mismo método HTTP?
• WEBHOOK_URL: ¿Está configurada manualmente la variable de entorno cuando se opera detrás de un reverse proxy, y coincide con el dominio público?

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.

Preguntas frecuentes sobre los webhooks de n8n en producción

¿Por qué deja de responder el webhook a las solicitudes tras unos dos minutos?

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.

¿Tengo que guardar el workflow antes de que funcione la URL de producción?

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.

¿Pueden dos workflows usar la misma ruta de webhook?

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.

¿Qué hacer si n8n se ejecuta detrás de Nginx o Traefik y la URL de webhook mostrada es incorrecta?

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.