Respuesta directa: si un webhook de n8n devuelve 404, comprueba primero si has copiado la URL de prueba o la de producción, si existe un receptor de prueba o una versión publicada, y si coinciden método HTTP y ruta. Hazlo antes de revisar credenciales o nodos que todavía no se han ejecutado.
Enlace de afiliación: la guía incluye un enlace asociado a n8n Cloud; FloxoLab puede recibir una comisión sin coste adicional para ti. Los ejemplos utilizan direcciones y datos ficticios de prueba, no endpoints reales de un cliente.
Empieza por el síntoma
| Síntoma | Qué revisar primero |
|---|---|
| La URL de prueba devuelve 404 | Selecciona Listen for test event y vuelve a enviar |
| La URL de producción devuelve 404 | Publica el flujo y copia de nuevo su URL |
| Funciona desde el navegador, pero no desde la app | Compara GET y POST |
| El nodo muestra dominio, puerto o protocolo incorrectos | Revisa la URL pública y el proxy del alojamiento propio |
| No aparecen datos en el editor | En producción, abre Executions |
Un 404 suele indicar que la petición no encontró la ruta registrada. Un error posterior dentro del flujo es otro problema. Conserva código, cuerpo de respuesta, fecha y método sin publicar secretos; esa evidencia permite localizar la etapa que falla.
URL de prueba: necesitas un receptor de prueba activo
En el nodo Webhook selecciona Test URL y después Listen for test event. La documentación actual indica que el registro de prueba dura 120 segundos. Envía el evento mientras está activo para ver los datos en el editor.
Abrir o guardar el flujo no registra indefinidamente la URL de prueba. Si el tiempo expira, vuelve a activar el receptor de prueba y repite. No configures esa URL temporal en un servicio que deba llamar al flujo a cualquier hora.
URL de producción: publica el flujo
Cuando el flujo esté listo, selecciona Production URL, copia el valor completo y publica el flujo. La documentación actual utiliza la acción Publish. Guardar un borrador no equivale a actualizar la versión que atiende llamadas de producción.
Los datos de una ejecución de producción no aparecen como una entrada de prueba en el lienzo. Abre Executions para comprobar si la llamada generó una ejecución y revisar su entrada. La falta de datos visibles en el editor no demuestra un fallo de recepción.
Comprueba método y ruta antes de los datos enviados
El emisor debe utilizar un método que el nodo tenga registrado. Pegar una URL en el navegador envía GET; una app puede enviar POST. Que uno funcione no demuestra que el otro deba hacerlo.
Compara también la ruta completa: errores de escritura, guiones, parámetros y cambios posteriores a configurar el emisor. Después de modificar Path, copia la URL otra vez; no edites únicamente el último segmento a mano.
Una combinación de ruta y método debe ser única entre los webhooks registrados. Si otro flujo publicado ya utiliza esa combinación, identifica el propietario antes de despublicar nada. Cambiar una ruta puede dejar integraciones existentes apuntando a una dirección antigua.
Prueba con una petición mínima
Para separar n8n de la aplicación emisora, utiliza una entrada de prueba sin datos privados. El siguiente comando usa POST. Sustituye la URL por la copiada del nodo y adapta el método si tu Webhook espera otro.
curl --request POST 'https://n8n.example.com/webhook/example-path' \
--header 'Content-Type: application/json' \
--data '{"event":"webhook-test","id":"demo-001"}'Con Test URL activa el receptor de prueba justo antes de enviar; con Production URL publica primero. No ejecutes una petición contra un flujo con acciones reales sin entender sus consecuencias. Para el diagnóstico inicial conviene un flujo aislado o una ruta sin efectos externos.
Si la petición mínima funciona y la app no, compara la URL guardada por la app, método, cabeceras, autenticación y acceso de red. No cambies varias capas a la vez: perderías la posibilidad de explicar qué resolvió el problema.
Proxy inverso y URL pública
Esta sección corresponde al alojamiento propio. Si el editor anuncia HTTP, un nombre interno o un puerto incorrecto, revisa cómo se construye la dirección pública. Un proxy puede exponer HTTPS mientras n8n escucha en una dirección interna diferente.
WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1Son valores ilustrativos, no una configuración para copiar sin comprobar. Usa tu base HTTPS real y el número efectivo de proxies. El último proxy debe transmitir de forma adecuada la información de host, protocolo y cliente. Revisa los cambios con quien opera el servicio y vuelve a copiar la URL generada tras aplicar la configuración.
No asumas que un error del proxy se arregla modificando el contenido del flujo. Si aún decides dónde alojarlo, la comparación de Cloud y alojamiento propio identifica las responsabilidades operativas.
Lista de comprobación de errores 404
- Copia de nuevo la URL desde el nodo, sin notas antiguas.
- Confirma Test o Production.
- Activa el receptor de prueba o publica la versión de producción.
- Comprueba el método HTTP exacto.
- Compara ruta y posibles conflictos con otro flujo.
- En alojamiento propio, revisa base pública y proxy.
- Una vez registrada la ejecución, investiga errores posteriores por separado.
Detente cuando la petición alcance n8n. Si el primer nodo recibe los datos, las credenciales o expresiones de otro nodo ya pertenecen a otra etapa del diagnóstico.
Qué guardar para la entrega a producción
Documenta qué sistema conserva la URL de producción, qué método y formato envía y quién revisa las ejecuciones. Guarda una entrada saneada y una respuesta esperada. No pegues en documentación pública parámetros secretos ni cabeceras de autenticación.
Define qué hace el emisor ante una respuesta no satisfactoria. Si reintenta, necesitas una identidad estable de evento para evitar operaciones duplicadas. La guía de reintentos e idempotencia explica por qué un timeout no demuestra que el destino no haya actuado.
Asigna una persona responsable de las alertas y la recuperación. Una ruta puede funcionar hoy y dejar de hacerlo al cambiar el emisor, la publicación o la infraestructura. La persona que recibe una alerta necesita saber dónde mirar y qué operaciones puede repetir.
Prueba, producción y herramientas de revisión
Antes del cambio final, verifica una entrada en modo de prueba, pasa a la URL de producción, publica y actualiza el emisor. Confirma después una ejecución segura en Executions. Las modificaciones del borrador no se convierten automáticamente en la nueva versión publicada.
El n8n Workflow Checker de FloxoLab, en inglés revisa patrones estáticos de un JSON exportado. No puede saber si el receptor de prueba está activo, si la versión está publicada, si el proxy funciona o si una credencial es válida. No lo uses como sustituto de estas comprobaciones de ejecución.
Si los conceptos aún son nuevos, consulta qué es n8n. Entender el disparador evita investigar pasos que nunca llegaron a iniciarse.
Preguntas frecuentes
¿Por qué funcionó ayer la Test URL?
El receptor de prueba es temporal. Vuelve a registrarlo o configura una URL de producción para uso continuo.
¿Por qué veo una ejecución, pero no datos en el lienzo?
La producción se revisa en Executions; el editor no muestra esas entradas como si fueran un evento de prueba.
¿Un 404 significa que las credenciales están mal?
No necesariamente. Si la ruta no registra la llamada, las credenciales de nodos posteriores todavía no intervienen.
Fuentes revisadas
13 de noviembre de 2026: nodo Webhook, pruebas y producción y URL pública detrás de un proxy. Consultar n8n Cloud mediante el enlace asociado.