Describe el problema/error/pregunta
Estoy cursando la n8n Academy N8N102 Sección 2 (Webhook Assessment) y no puedo pasar la validación del primer webhook.
El Academy Webhook Tester reporta:
“webhook_url is not valid. Please ensure your hostname resolves and is publicly accessible. Status Code: 500”
Sin embargo, mi webhook es públicamente accesible y funciona correctamente cuando lo pruebo manualmente con curl.
He verificado lo siguiente:
Se está usando la URL del webhook de producción (no la URL de prueba).
El flujo de trabajo está publicado.
n8n se ejecuta en un VPS público detrás de Nginx con HTTPS.
DNS y SSL funcionan correctamente.
Reutilicé la misma credencial de API Key de n8n Academy de la Sección 1.
La autenticación del webhook está configurada en Header Auth.
curl alcanza exitosamente el webhook.
Cuando el webhook está configurado para Respond Immediately, recibo:
{
“message”: “Workflow was started”
}
Cuando está configurado para Respond using Respond to Webhook Node, recibo:
{
“code”: 0,
“message”: “No Respond to Webhook node found in the workflow”
}
El probador de Academy sigue reportando que la URL del webhook es inválida.
¿Alguien ha experimentado esto con el Academy Webhook Tester, o hay algo específico que el probador espera que difiera de un webhook normal?
¿Cuál es el mensaje de error (si hay alguno)?
Por favor comparte tu flujo de trabajo
Comparte el resultado devuelto por el último nodo
Información sobre tu configuración de n8n
- Versión de n8n: 2.31.6
- Base de datos (predeterminada: SQLite): no aplica
- Configuración de n8n EXECUTIONS_PROCESS (predeterminada: own, main): Predeterminada
- Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio): Docker en Ubuntu VPS detrás de Nginx
- Sistema operativo: Ubuntu 24.04 LTS
La captura de pantalla de curl es la pista clave aquí. Esto ya no parece DNS, SSL o Nginx, porque la solicitud está llegando a n8n y n8n es quien devuelve el 500.
El error específico dice: «No Respond to Webhook node found in the workflow».
Eso generalmente significa que el nodo Webhook está configurado para «Respond using Respond to Webhook Node», pero para esta ejecución n8n no puede alcanzar ningún nodo Respond to Webhook desde esa ruta Webhook.
Si tu flujo de trabajo real tiene más nodos que el compartido, comprueba que el nodo Respond to Webhook esté realmente conectado y siempre se alcance para esta solicitud POST. Para una validación rápida, añade un nodo Respond to Webhook directamente después del Webhook y devuelve una respuesta 200 simple, luego ejecuta curl de nuevo. Una vez que curl devuelva 200 en lugar de 500, el probador de Academy debería dejar de tratar la URL como inválida.
El mensaje del hostname del probador es engañoso aquí: el HTTP 500 y la respuesta No Respond to Webhook node found demuestran que la solicitud ya pasó DNS, TLS, Nginx y el nodo Webhook. Si la autenticación de encabezados fuera el problema, normalmente verías 401/403 en lugar de este 500 a nivel de flujo de trabajo.
Con Using Respond to Webhook Node, un nodo Respond debe ser accesible en cada ruta de ejecución posible. Un nodo Respond que está desconectado, deshabilitado o solo presente en la otra rama IF es equivalente a no tener ninguno para esa solicitud.
Lo aislaría con una ruta temporal:
Webhook (mismo POST + autenticación de encabezado) -> Respond to Webhook (JSON fijo, estado 200)
Elimina todas las ramas IF/base de datos para esta prueba y envía una solicitud curl que coincida con el método, encabezado y cuerpo del probador de Academy. Confirma que la ejecución alcanza visiblemente el nodo Respond y que curl recibe 200. Luego restaura la lógica de validación y termina cada rama de éxito/error con su propia respuesta accesible. Si el probador de Academy sigue reportando 500 después de que la ruta mínima devuelva 200, compara la marca de tiempo del probador con el registro de acceso de Nginx para confirmar que está golpeando la misma URL de producción.
