Перейти к содержанию

Диагностика Webhook в n8n: URL, методы и ответы

Обновлено: 2026-05-29

Открыть мой план

Короткий ответ

Если webhook в n8n не работает, сначала определите, какой URL вы проверяете: test URL или production URL. Test URL нужен для отладки и обычно работает только во время тестового прослушивания в редакторе, а production URL должен использоваться для реальных внешних сервисов и требует активированного workflow. Если n8n стоит за reverse proxy, отдельно проверьте WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL и путь, который отдаёт внешний домен. Большинство ошибок webhook — это не проблема ноды, а путаница между test/production URL, неактивированный workflow, неверный HTTP-метод, обрезанный path или неправильный домен за proxy.

Быстрая развилка по симптомам

Симптом Вероятная причина Что проверить первым
404 на production URL workflow не активирован, path изменён, запрос идёт не туда статус workflow и точный production URL
Test URL не принимает запрос редактор не слушает тестовый webhook нажать Listen/Test workflow и повторить запрос
Внешний сервис пишет timeout n8n долго отвечает или proxy рвёт соединение response mode, логи proxy, время выполнения workflow
Запрос виден в proxy, но не в n8n proxy меняет path или host WEBHOOK_URL, location/block proxy
405 Method Not Allowed выбран не тот HTTP method метод в Webhook node и запросе
Ответ пустой или не тот JSON неправильно выбран режим ответа Respond to Webhook или response data

Главное правило: не меняйте сразу ноду, домен и proxy. Сначала воспроизведите проблему минимальным curl, затем сравните, куда реально уходит запрос.

Шаг 1. Зафиксируйте точный URL и метод

Откройте Webhook node и выпишите четыре вещи: HTTP method, path, test URL, production URL. Если path был изменён вручную, скопируйте его заново из интерфейса, а не из старой документации, Telegram-настройки или платежного кабинета.

Минимальная проверка для POST:

curl -i -X POST 'https://n8n.example.ru/webhook/order-created' \
  -H 'content-type: application/json' \
  -d '{"event":"debug","id":"manual-001"}'

Для GET не отправляйте тело запроса:

curl -i 'https://n8n.example.ru/webhook/order-created?debug=1'

Сохраните статус-код, заголовки и первые строки ответа. Это позволит понять, кто отвечает: сам n8n, reverse proxy, CDN, WAF или внешний сервис.

Шаг 2. Test URL и production URL — разные режимы

У Webhook node есть две логики работы. Test URL нужен, когда вы настраиваете workflow и ждёте один или несколько тестовых запросов прямо из редактора. Production URL нужен, когда workflow уже активирован и должен принимать реальные события без открытого редактора.

Типичная ошибка: пользователь копирует test URL в Telegram, CRM или платёжный сервис. В момент настройки всё работает, а через час интеграция “умирает”, потому что тестовый listener больше не ждёт запросы.

Для боевого сервиса используйте только production URL. После сохранения workflow активируйте его, затем отправьте запрос через curl. Если production URL отдаёт 404, проверьте не только path, но и статус workflow: выключенный workflow не должен быть точкой приёма боевых webhook.

Шаг 3. Проверьте reverse proxy и публичный домен

Если n8n работает в Docker или за Nginx/Caddy/Traefik, внешний URL часто собирается не так, как внутренний адрес контейнера. n8n может жить на http://n8n:5678, а пользователю нужен https://n8n.example.ru. Для этого в self-hosted установке обычно фиксируют публичный адрес через переменные окружения.

Проверьте минимум:

N8N_HOST=n8n.example.ru
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.ru/
N8N_EDITOR_BASE_URL=https://n8n.example.ru/

Если сайт открыт по HTTPS, а n8n генерирует webhook с http:// или внутренним портом 5678, внешний сервис может отправлять запрос не туда. После изменения переменных пересоздайте контейнеры, иначе старая конфигурация останется в процессе.

Шаг 4. Убедитесь, что proxy не обрезает path

Webhook path чувствителен к тому, как proxy проксирует URL. Ошибка часто выглядит так: внешний запрос приходит на /webhook/order-created, а до n8n доходит /order-created или наоборот. Особенно внимательно проверяйте конфигурации с поддиректорией, например example.ru/n8n/.

Что проверить в proxy:

  • нет ли rewrite-правил, которые удаляют /webhook;
  • не подменяется ли Host;
  • передаются ли X-Forwarded-Proto и X-Forwarded-Host;
  • не режется ли body большого payload;
  • достаточно ли большой timeout для долгих workflow;
  • нет ли отдельного location, который перехватывает /webhook/.

Если proxy отдаёт свой 404, в логах n8n запроса не будет. Если n8n получил запрос и вернул ошибку, execution должен появиться в истории workflow.

Шаг 5. Проверьте response mode

Webhook может отвечать сразу, после последней ноды или через отдельную ноду Respond to Webhook. Если внешний сервис ждёт быстрый 200 OK, а workflow обрабатывает заказ 40 секунд, сервис может считать webhook неуспешным и отправить повтор. Для платежей, CRM и Telegram-ботов часто безопаснее быстро принять событие, записать его в очередь или базу, а тяжёлую обработку выполнить отдельно.

Для API-сценария наоборот нужен управляемый ответ: статус, JSON, сообщение об ошибке. Тогда используйте Respond to Webhook и явно задайте body:

{
  "ok": true,
  "received": "={{ $json.event }}",
  "requestId": "={{ $json.id }}"
}

Не смешивайте “быстрый приём события” и “публичный API” в одной статье/странице: это разные UX и разные требования к ответу.

Шаг 6. Проверьте дубли webhook и старые настройки во внешнем сервисе

У webhook-интеграций часто есть скрытая проблема: внешний сервис хранит старый URL. Workflow уже переименовали, path сменили, домен переехал, а Telegram, Stripe/YooKassa, CRM или собственный backend продолжает слать события на прежний адрес.

Сделайте простой аудит:

  1. Скопируйте production URL из текущей ноды.
  2. Откройте внешний сервис и сравните URL посимвольно.
  3. Проверьте HTTP method.
  4. Отправьте тестовое событие из кабинета сервиса.
  5. Сравните время события с execution list в n8n.
  6. Удалите старые webhook endpoints, если сервис позволяет.

Если сервис поддерживает подпись запроса, не отключайте её “для проверки” на production. Лучше создать отдельный тестовый endpoint с тестовым секретом.

Контрольный smoke-test после исправления

После правки сделайте короткий тест, который можно повторить при каждом релизе:

curl -i -X POST 'https://n8n.example.ru/webhook/health-check' \
  -H 'content-type: application/json' \
  -d '{"source":"smoke-test","ts":"2026-05-29"}'

Проверьте пять вещей: статус 2xx, правильный body, наличие execution, отсутствие ошибки в логах n8n и отсутствие ошибки в логах proxy. Затем выключите тестовый workflow или защитите его секретным path, чтобы не оставить публичную диагностическую ручку.

Что не делать

Не публикуйте test URL в production-сервисах. Не меняйте path без обновления внешних интеграций. Не используйте длинный workflow как синхронный webhook для сервисов с коротким timeout. Не отдавайте в ответ сырой payload с токенами. Не делайте один публичный webhook для всех событий без валидации типа события и источника.

FAQ

Почему production URL отдаёт 404, а test URL работает?
Чаще всего workflow не активирован или внешний сервис вызывает старый production URL. Test URL и production URL — разные режимы, их нельзя считать взаимозаменяемыми.

Почему webhook срабатывает два раза?
Внешний сервис может повторять доставку, если не получил быстрый успешный ответ. Добавьте идемпотентность по event_id и проверьте response mode.

Почему n8n показывает неправильный домен webhook?
Обычно не настроены публичные переменные окружения для self-hosted установки за reverse proxy. Проверьте WEBHOOK_URL, N8N_HOST и N8N_PROTOCOL.

Как понять, кто вернул 404 — proxy или n8n?
Сравните body ответа, заголовок server и логи. Если в n8n нет execution и в логах пусто, запрос, скорее всего, не дошёл до n8n.

Можно ли использовать один webhook для нескольких событий?
Можно, если в payload есть тип события и вы валидируете источник. Для сложных интеграций удобнее разделить endpoint по критическим сценариям.