Nota revisada y reescrita el 18 de octubre de 2026: la versión original tenía errores y datos sin fuente.
Un webhook de n8n que funciona cuando pulsas Listen for test event y luego, en producción, devuelve 404 o no hace nada. En una instancia autoalojada las causas son pocas y se pueden revisar en orden.
1. URL de test o URL de producción
Cada nodo Webhook tiene dos URLs:
- Test:
https://tu-n8n/webhook-test/.... Solo escucha mientras el editor está esperando un evento, y para una sola llamada. - Producción:
https://tu-n8n/webhook/.... Solo responde si el workflow está activo.
Si has pegado la de test en Stripe, en un formulario o en otro servicio, funcionará mientras pruebas y fallará después. Es la causa más común.
2. El workflow no está activo, o lo activo es otra versión
En n8n 2.x guardar no es lo mismo que publicar: los cambios se guardan como borrador y los triggers siguen ejecutando la última versión publicada. Si editas el workflow y no pulsas Publish, el webhook de producción sigue corriendo el código anterior (o ninguno, si nunca se publicó).
Para comprobarlo, en Executions abre una ejecución de producción y mira qué nodos tiene: si no coinciden con lo que ves en el editor, estás ejecutando otra versión.
3. La URL pública detrás de un proxy
Por defecto, n8n construye las URLs de los webhooks con N8N_PROTOCOL, N8N_HOST y N8N_PORT. Detrás de Nginx, Caddy o Traefik eso no funciona: n8n escucha internamente en el puerto 5678 y el proxy sirve en el 443, así que la URL que te enseña el editor (y la que registra en servicios externos) no es la que se ve desde fuera. Se arregla con:
N8N_WEBHOOK_URL=https://n8n.tudominio.com/
N8N_PROXY_HOPS=1
N8N_WEBHOOK_URL es la URL pública con la que n8n construye las URLs de los webhooks. En versiones anteriores se llamaba WEBHOOK_URL: sigue funcionando, pero está obsoleta y n8n avisa en el log. N8N_PROXY_HOPS=1 le indica que hay un proxy delante, para que se fíe de las cabeceras X-Forwarded-*.
El último proxy de la cadena tiene que enviar X-Forwarded-For, X-Forwarded-Host y X-Forwarded-Proto. Además tiene que dejar pasar WebSocket para el editor, o la interfaz pierde la conexión cada poco:
location / {
proxy_pass http://127.0.0.1:5678;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
}
4. El que llama se cansa de esperar
Por defecto el nodo Webhook responde cuando termina el workflow (Respond: When Last Node Finishes). Si el workflow llama a una IA o a una API lenta, el servicio que envió el webhook puede cortar antes: muchos esperan solo unos segundos y reintentan, y tú acabas con ejecuciones duplicadas.
Si el que llama no necesita el resultado, cambia Respond a Immediately: n8n contesta 200 al momento y sigue trabajando. Si sí lo necesita, usa Using 'Respond to Webhook' Node y responde en cuanto tengas lo mínimo.
5. Mirar antes de tocar
- Executions del workflow: si la ejecución aparece y falla, el webhook llega y el problema está dentro. Si no aparece, la petición no está llegando a n8n.
curl -i -X POST https://n8n.tudominio.com/webhook/tu-ruta -H 'Content-Type: application/json' -d '{}'desde fuera del servidor. Un 404 con el mensaje webhook is not registered es el caso 1 o el 2. Un 502 o un timeout apunta al proxy o a que el contenedor no está levantado.- Los logs del proxy y de n8n (
docker logs n8n) en el momento de la llamada.