Webhook tester reports "webhook_url is not valid (500)" even though the production webhook is publicly accessible and works with curl

Describe the problem/error/question

I’m doing the n8n Academy N8N102 Section 2 (Webhook Assessment) and I’m unable to pass the very first webhook validation.
The Academy Webhook Tester reports:
“webhook_url is not valid. Please ensure your hostname resolves and is publicly accessible. Status Code: 500”
However, my webhook is publicly accessible and works correctly when tested manually with curl.
I have verified the following:
Production webhook URL is being used (not the test URL).
Workflow is published.
n8n is running on a public VPS behind Nginx with HTTPS.
DNS and SSL are working.
Reused the same n8n Academy API Key credential from Section 1.
Webhook authentication is set to Header Auth.
curl successfully reaches the webhook.
When the webhook is configured to Respond Immediately, I receive:
{
“message”: “Workflow was started”
}
When configured to Respond using Respond to Webhook Node, I receive:
{
“code”: 0,
“message”: “No Respond to Webhook node found in the workflow”
}
The Academy tester still reports the webhook URL as invalid.
Has anyone experienced this with the Academy Webhook Tester, or is there something specific the tester expects that differs from a normal webhook?

What is the error message (if any)?

Please share your workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 2.31.6
  • Database (default: SQLite): not applied
  • n8n EXECUTIONS_PROCESS setting (default: own, main): Default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker on Ubuntu VPS behind Nginx
  • Operating system: Ubuntu 24.04 LTS

The curl screenshot is the key clue here. This does not look like DNS, SSL or Nginx anymore, because the request is reaching n8n and n8n is the one returning the 500.

The specific error says: “No Respond to Webhook node found in the workflow”.

That usually means the Webhook node is set to “Respond using Respond to Webhook Node”, but for this execution n8n cannot reach any Respond to Webhook node from that Webhook path.

If your real workflow has more nodes than the one shared, I’d check that the Respond to Webhook node is actually connected and always reached for this POST request. For a quick validation, add a Respond to Webhook node directly after the Webhook and return a simple 200 response, then run curl again. Once curl returns 200 instead of 500, the Academy tester should stop treating the URL as invalid.

The tester’s hostname message is misleading here: the HTTP 500 and No Respond to Webhook node found response prove that the request already passed DNS, TLS, Nginx, and the Webhook node. If header authentication were the problem, you would normally see 401/403 rather than this workflow-level 500.

With Using Respond to Webhook Node, a Respond node must be reachable on every possible execution path. A Respond node that is disconnected, disabled, or only present on the other IF branch is equivalent to having none for that request.

I would isolate it with one temporary path:

Webhook (same POST + header auth) -> Respond to Webhook (fixed JSON, status 200)

Remove all IF/database branches for this test and send a curl request that matches the Academy tester’s method, header, and body. Confirm the execution visibly reaches the Respond node and curl receives 200. Then restore the validation logic and end every success/error branch with its own reachable response. If the Academy tester still reports 500 after the minimal path returns 200, compare the tester timestamp with the Nginx access log to confirm it is hitting the same production URL.