Если n8n webhook не работает, начинать стоит не с переустановки сервера и не с правки самого workflow, а с одного сохранённого запроса. Нужны URL, метод, заголовки, тело, идентификатор события, полученный HTTP-код и запись выполнения в n8n. По этой связке видно, где обрывается путь: отправитель, адрес, активность workflow, разбор JSON или повторная доставка.
Webhook-нода запускает workflow по событию от внешнего сервиса и может возвращать данные, сгенерированные в конце работы Webhook | Nodes | n8n Docs. Это важно для диагностики: успешный ответ и запуск workflow — не то же самое, что выполненное действие в целевой системе.
Ниже разобраны четыре учебные трассы и полный диагностический журнал. Учебный пример полностью вымышлен: это не клиентский кейс и не выполненный тест на работающем n8n. Все входы и эталон заданы заранее, читатель сверяет с ними свои наблюдения.
Зафиксируйте участок сбоя
Начните с записи того, что реально пришло и что реально произошло. Сохраните: URL, на который ушёл запрос; HTTP-метод; заголовки, включая Content-Type; тело; идентификатор события; HTTP-код ответа; идентификатор выполнения в n8n, если оно было. Если отправитель показывает свой журнал доставки, сохраните и его: там видно, повторялась ли отправка.
Эта запись нужна, чтобы не спорить о гипотезах. Один и тот же код ответа может возникать по разным причинам. HTTP 404 не говорит сам по себе, что workflow неактивен, и не говорит, что адрес неверный. Различает причины только сопоставление запроса с настройками ноды и с записью выполнения.
Сначала сохраните запросы, ответы и журнал выполнения, затем меняйте конфигурацию.
Различите test и production
У Webhook-ноды два адреса: test и production Webhook | Nodes | n8n Docs. Test URL регистрируется, когда вы выбираете прослушивание тестового события или запускаете workflow, если он неактивен. Production URL регистрируется при публикации workflow. При работе через production URL данные не отображаются прямо в редакторе; их видно на вкладке выполнений.
Test-адрес слушает ограниченное время и показывает данные в интерфейсе, production работает до снятия публикации и данных в редакторе не показывает Common issues | Nodes | n8n Docs. Это разные режимы, а не два варианта одного и того же адреса. Отправитель, настроенный на production URL, не попадёт в test-listener, даже если тот в этот момент слушает.
Названия кнопок и вкладок зависят от версии n8n. Сверяйте действия по официальной документации своей версии, а не по скриншотам из чужой статьи.
Практическое правило: пока проверяете один запрос, используйте тот адрес, который соответствует режиму работы отправителя. Если отправитель настроен на production, проверяйте через production и смотрите выполнения. Если нужен разбор в редакторе, временно направьте отправителя на test-адрес и держите прослушивание открытым.
Проверьте один запрос
Полный шаблон для ручной проверки одного события. Замените адрес, путь и тело на свои; значения ниже — учебные.
curl -i --request POST 'https://automation.example.test/webhook/lead-check' \
--header 'Content-Type: application/json' \
--data '{"event_id":"E1","lead_ref":"L7"}'
Флаг -i показывает заголовки ответа вместе с телом — по ним видно HTTP-код. Метод в шаблоне — POST; если в ноде задан другой метод, шаблон нужно поменять. Официальная документация приводит примеры с GET и советует использовать метод, заданный в HTTP Method Common issues | Nodes | n8n Docs.
JSON-тело содержит два поля: event_id и lead_ref. Идентификатор события нужен, чтобы отличить повторную доставку от новой. Ссылка на лид нужна, чтобы downstream-действие можно было сверить с конкретной записью, а не с количеством HTTP-ответов.
После запуска найдите соответствующее выполнение в n8n и посмотрите, что нода получила на входе. Если выполнение есть, сравните разобранное тело с отправленным: совпадают ли event_id и lead_ref. Если соответствующее выполнение не найдено, сначала подтвердите правильный workflow и окно поиска, затем по журналу отправителя и фактическому ответу проверьте URL, метод и публикацию. При отсутствии доказанного участка причина остаётся неизвестной: проверьте настроенную аутентификацию и доступ через прокси по официальной документации Webhook | Nodes | n8n Docs, Common issues | Nodes | n8n Docs.
Если по документации нужна аутентификация, добавьте её в запрос согласно официальному описанию выбранного метода Webhook | Nodes | n8n Docs. Защита и подпись зависят от отправителя, поэтому сверяйтесь с его официальной документацией отдельно. Не отключайте проверки ради того, чтобы запрос прошёл.
Разберите четыре трассы
Все трассы — вымышленный учебный вход. Общая настройка: метод POST, путь lead-check, Content-Type application/json, ожидаемое тело event_id=E1, lead_ref=L7, режим ответа — немедленный. Ниже таблица наблюдений по каждой трассе.
| Трасса | Метод отправителя | Режим URL | Workflow опубликован | HTTP | Выполнение в n8n | Наблюдаемое тело / действие |
|---|---|---|---|---|---|---|
| T1 | GET | production | да | 404 | нет | тела нет |
| T2 | POST | production | нет | 404 | нет | тело E1/L7 отправлено |
| T3 | POST | production | да | 200 | X1 | тело E1/L7 разобрано, downstream: created L7 |
| T4 | POST | production | да | 200 | X2 | тело E1/L7 разобрано, downstream: skipped duplicate |
Диагностический журнал по трассам:
- T1. Метод отправителя не совпал с POST в ноде. HTTP 404 здесь не доказывает, что workflow неактивен. Следующая проверка: повторить тот же endpoint с POST и посмотреть, появится ли выполнение.
- T2. Production workflow в этой трассе не опубликован или неактивен. Тело отправлено, но выполнения нет. Следующая проверка: сверить фактическую версию и адрес; публиковать — только разрешённым действием.
- T3. Приём прошёл по учебному журналу: execution X1, разобраны
event_id=E1иlead_ref=L7, downstream показывает created L7. HTTP 200 само по себе не подтверждает это действие — нужна отдельная запись о результате. - T4. Повторная доставка того же E1: execution X2, разобраны те же
E1иL7, downstream показывает skipped duplicate. Новое выполнение не обязано создавать второй лид.
Две причины одного кода 404 здесь разные: несовпадение метода и неопубликованный workflow. Решение принимается по входным данным и журналу, а не по одному коду ответа. Повтор E1 отличается тем, что execution другой, а идентификатор события тот же.
Журнал по участкам пути на примере T3:
| Участок | Что проверяем | Данные T3 |
|---|---|---|
| Отправитель | URL, метод, Content-Type, тело, event_id | production / POST / application/json / E1 |
| Прокси | Доступ и HTTP | 200 |
| Нода Webhook | Выполнение и разобранное тело | X1 + E1/L7 |
| Downstream | Независимый результат действия | created L7 |
| Повтор | Тот же event_id не создаёт второй лид | T4: X2 + skipped duplicate |
Итог по учебному набору: одно уникальное событие E1, два выполнения X1 и X2, один созданный лид L7. Двух выполнений недостаточно, чтобы сделать вывод о двух лидах, — считать нужно уникальные события и подтверждённые действия.
Два ограничения по официальной документации. n8n разрешает регистрировать только один webhook на сочетание пути и метода Common issues | Nodes | n8n Docs; при конфликте нужно снять публикацию конфликтующего workflow или изменить путь либо метод. Если n8n Cloud не ответил за 100 секунд, запрос падает с кодом 524 Common issues | Nodes | n8n Docs.
Подтвердите конечное действие
HTTP 200 и разобранное тело — только промежуточные свидетельства. Конечное действие подтверждается независимым наблюдением: запись в целевой системе, запись в её журнале, ответ её API с идентификатором созданной записи. Сравнивайте по ключу lead_ref, а не по количеству HTTP-ответов.
Дедупликация тоже требует подтверждения. Учебный набор показывает, как это выглядит: одно событие E1, два выполнения, один лид. Такой итог получается, только если механизм дедупликации действительно сохранён и проверен. Сохранённый ли ключ, видно по журналу решения; одна строка «skipped duplicate» в выполнении ещё не доказывает, что запись в целевой системе не появилась.
Если передаёте логи ИИ для разбора, помните границу: модель объясняет предоставленные записи и не имеет скрытого доступа к вашему n8n или к целевой системе. Она не может подтвердить действие, которого нет в переданных данных. Чем конкретнее вход — трасса, код, тело, идентификатор выполнения, — тем проверяемее вывод. О типичных ошибках ботов и проверке их ответов читайте в материале ИИ-бот выдумывает ответы, а общий разбор инструментов — в статье Нейросети для маркетинга.
Порядок, который стоит удержать: зафиксировать запрос и выполнение; разделить test и production; проверить один запрос с полным телом; разобрать трассы по участкам; подтвердить конечное действие отдельно от HTTP-кода и от факта запуска workflow. Код ответа сам по себе не локализует сбой.
Учебный пример
Ниже полный вход, копируемый промпт и эталон результата. Это вымышленный набор данных, а не эксперимент на работающем n8n.
Входные данные (учебные):
{
"configured": {
"method": "POST",
"path": "lead-check",
"test_url": "https://automation.example.test/webhook-test/lead-check",
"production_url": "https://automation.example.test/webhook/lead-check",
"content_type": "application/json",
"expected_body": {"event_id": "E1", "lead_ref": "L7"},
"response_mode": "immediately",
"deduplication_key": "event_id"
},
"traces": [
{"id": "T1", "sender_method": "GET", "url_mode": "production", "published": true, "proxy_status": 404, "n8n_execution": null, "body": null},
{"id": "T2", "sender_method": "POST", "url_mode": "production", "published": false, "proxy_status": 404, "n8n_execution": null, "body": {"event_id": "E1", "lead_ref": "L7"}},
{"id": "T3", "sender_method": "POST", "url_mode": "production", "published": true, "proxy_status": 200, "n8n_execution": "X1", "parsed_body": {"event_id": "E1", "lead_ref": "L7"}, "delivery_event": "E1", "downstream_action": "created L7"},
{"id": "T4", "sender_method": "POST", "url_mode": "production", "published": true, "proxy_status": 200, "n8n_execution": "X2", "parsed_body": {"event_id": "E1", "lead_ref": "L7"}, "delivery_event": "E1", "downstream_action": "skipped duplicate"}
]
}
Копируемый промпт:
Ты аналитик интеграции n8n webhook. По предоставленным учебным данным определи участок сбоя в каждой трассе и подтверди конечное действие. Не придумывай данных, которых нет во входе. Не имей скрытого доступа к n8n или целевой системе.
Настройка: method=POST, path=lead-check, test_url=https://automation.example.test/webhook-test/lead-check, production_url=https://automation.example.test/webhook/lead-check, content_type=application/json, expected_body={event_id:E1, lead_ref:L7}, response_mode=immediately, deduplication_key=event_id.
Трассы:
T1: GET, production, published=true, HTTP=404, execution=null, body=null.
T2: POST, production, published=false, HTTP=404, execution=null, body={event_id:E1, lead_ref:L7}.
T3: POST, production, published=true, HTTP=200, execution=X1, parsed_body={event_id:E1, lead_ref:L7}, downstream=created L7.
T4: POST, production, published=true, HTTP=200, execution=X2, parsed_body={event_id:E1, lead_ref:L7}, downstream=skipped duplicate.
Правила вывода:
1. Сравнивай метод отправителя с method ноды и URL с test/production режимом.
2. HTTP 404 сам по себе не доказывает неактивный workflow.
3. HTTP 200 и разобранное тело не заменяют независимое подтверждение downstream-действия.
4. Считай уникальные события по event_id и подтверждённые действия, а не число HTTP-ответов и не число выполнений.
5. Для каждой трассы укажи участок сбоя или успеха, причину и следующую проверку.
Верни JSON:
{
"traces": [{"id": "T1|T2|T3|T4", "fault": "строка или null", "next_check": "строка"}],
"stage_log": [{"stage": "sender|proxy|Webhook node|downstream|repeat", "check": "строка", "result": "строка"}],
"totals": {"unique_events": число, "executions": число, "created_leads": число},
"limitations": ["строка"]
}
Эталон результата:
{
"traces": [
{"id": "T1", "fault": "Метод не совпал с POST ноды.", "next_check": "Повторить тем же endpoint с POST; 404 сам по себе не доказывает неактивный workflow."},
{"id": "T2", "fault": "Production workflow не опубликован/неактивен в заданной трассе.", "next_check": "Проверить фактическую версию и production URL; публиковать только разрешённым действием."},
{"id": "T3", "fault": "Приём прошёл по учебному журналу.", "next_check": "Сверить event_id=E1, lead_ref=L7 и отдельное подтверждение действия created L7, а не только HTTP 200."},
{"id": "T4", "fault": "Повторная доставка E1; новый execution не обязан создавать второй лид.", "next_check": "Дедупликация по E1 пропускает повтор; проверить сохранённый ключ и журнал решения."}
],
"stage_log": [
{"stage": "sender", "check": "URL, method, Content-Type, body, event_id", "result": "production/POST/application-json/E1"},
{"stage": "proxy", "check": "доступ и HTTP", "result": "200"},
{"stage": "Webhook node", "check": "выполнение и разобранное тело", "result": "X1 + E1/L7"},
{"stage": "downstream", "check": "независимый результат", "result": "created L7"},
{"stage": "repeat", "check": "тот же event_id не делает второй лид", "result": "X2 + skipped duplicate"}
],
"totals": {"unique_events": 1, "executions": 2, "created_leads": 1},
"limitations": [
"Учебные трассы не эксперимент на реальном n8n; 200 и body не доказывают действие CRM.",
"Защита и подпись зависят от отправителя; проверять по его официальным docs отдельно."
]
}
Как проверить эталон:
- Одинаковый 404 в T1 и T2 объяснён разными причинами, а не одним кодом ответа.
- T3: HTTP 200 не подменяет downstream-подтверждение created L7.
- T4: другой execution ID при том же E1; двух выполнений недостаточно для вывода о двух лидах.
- В наборе нет реальных токенов, endpoint и CRM; live-тест не выполнялся.
Учебный пример показывает полный ожидаемый разбор заданных трасс. Он не доказывает, что у читателя сбой именно в одном из этих мест: свои данные нужно собрать и сверить с тем же журналом участков.
Автор метода «Машиночитаемый маркетинг»