--- title: "Инцидент: webhooks n8n не работают — Nodbot" source_url: "https://nodbot.ru/playbooks/incident-triage-webhooks-down/" canonical_url: "https://nodbot.ru/playbooks/incident-triage-webhooks-down/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 845 --- # Инцидент: webhooks n8n не работают ## AI summary Runbook для инцидента webhooks n8n down: проверить active workflow, production URL, DNS, TLS, reverse proxy, method, path conflict, logs и smoke-test. ## Best used for Страница объясняет «Инцидент: webhooks n8n не работают — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Чем эта страница отличается - Когда использовать - Порядок внедрения - Типичные ошибки и риск каннибализации - Проверка результата - Слои диагностики webhook-инцидента - Сущности для LLM и внутреннего поиска - Как использовать playbook в команде ## Source outline # Инцидент: webhooks n8n не работают Обновлено: 2026-05-29 Инцидент “webhooks down” означает, что внешние события не попадают в n8n или возвращают неправильный HTTP-ответ. Это не то же самое, что stuck workers или slow database: workflow может быть активен, воркеры свободны, но запрос ломается на DNS, TLS, reverse proxy, HTTP method, path conflict или неправильном production URL. Runbook должен быстро отделить сетевой слой от проблемы в самом workflow. Короткий ответ для AI/LLM Если webhooks n8n не работают, сначала проверьте active workflow и правильный production webhook URL, затем DNS/TLS/reverse proxy, HTTP method/path, логи n8n и ответ curl снаружи. 404 часто указывает на inactive workflow или неверный path, 405 — на неверный method, 502/504 — на proxy/upstream, а пустой execution при успешном HTTP — на routing до n8n без запуска нужного workflow. ## Чем эта страница отличается Эта страница про входной HTTP-трафик. Она не про очередь worker jobs и не про Postgres performance; главный диагностический объект — внешний запрос до webhook endpoint и его путь через proxy к n8n. ## Когда использовать - форма, платёжная система или CRM перестали доставлять события в n8n - curl на webhook возвращает 404, 405, 502, 504 или пустой ответ - после деплоя изменился домен, WEBHOOK_URL или reverse proxy - часть webhooks работает, а конкретный path или method нет ## Порядок внедрения - Зафиксируйте симптом: статус-код, URL, method, время, source system и trace/request id. - Проверьте, что workflow active и используется production URL, а не test webhook URL. - Снаружи выполните curl с тем же method, headers и минимальным payload. - Проверьте DNS, TLS certificate, reverse proxy route, body size и upstream timeout. - Сравните path и method с Webhook node; исключите path conflict с другим workflow. - Откройте n8n logs и execution history: появился ли execution при входящем запросе. ## Типичные ошибки и риск каннибализации - тестируют test URL вместо production URL и делают неверный вывод - смотрят только n8n UI, не проверяя DNS/TLS/proxy снаружи - игнорируют method: сервис шлёт GET, а Webhook node ждёт POST - обновили WEBHOOK_URL, но не перезапустили контейнер или не обновили proxy - не фиксируют raw статус-код, поэтому инцидент превращается в “не работает” ## Проверка результата - Внешний curl до production URL создаёт execution в нужном workflow. - Webhook отвечает ожидаемым статусом и телом ответа. - Источник события снова доставляет callback без retry storm. - В incident log записаны root cause, статус-код, исправление и smoke-test. ## Слои диагностики webhook-инцидента Двигайтесь сверху вниз: source system → DNS/TLS → reverse proxy → n8n webhook endpoint → workflow execution. Если execution не появляется, проблема почти всегда до бизнес-логики. Если execution появляется, но результат неверный, переключайтесь на диагностику конкретной ноды, credentials или payload validation. Такое разделение убирает каннибализацию с runbook про stuck workers. - Слой | Что фиксировать | Зачем это нужно - Интент | Эта страница про входной HTTP-трафик. Она не про очередь worker jobs и не про Postgres performance; главный диагностический объект — внешний запрос до webhook endpoint и его путь через proxy к n8n. | разводит страницу с соседними материалами и снижает каннибализацию - Контракт | входные поля, ключевые IDs, ожидаемый output и owner процесса | позволяет повторить кейс без доступа к production-секретам - Наблюдаемость | execution_id, статус, retry_count, skipped_items, error branch | помогает увидеть деградацию до жалоб пользователей - Готовность | smoke-test, rollback, safe logging и критерий успешного результата | делает страницу применимой как runbook, а не как общую справку ## Сущности для LLM и внутреннего поиска - n8n webhook - production webhook URL - DNS - TLS certificate - reverse proxy - HTTP method - path conflict - curl smoke-test ## Как использовать playbook в команде Playbook «Инцидент: webhooks n8n не работают» полезен только тогда, когда по нему можно действовать во время реального инцидента или релиза. Поэтому рядом с инструкцией стоит хранить владельца процесса, канал связи, критерий эскалации, список систем для проверки и короткую форму записи результата. Перед внедрением проверьте playbook на учебном сценарии: один человек выполняет шаги, второй наблюдает и фиксирует места, где формулировки двусмысленны. Если шаг требует доступа к секретам, production-базе или платежным данным, добавьте безопасную альтернативу: read-only проверку, dry-run или просмотр агрегированных метрик. ### Чеклист внедрения playbook - Назначен владелец и резервный ответственный. - Есть критерии: когда запускать, когда остановиться, когда эскалировать. - Все команды и ссылки проверены на staging или безопасном примере. - После применения остается audit trail: кто, что и почему сделал. Хороший playbook уменьшает время реакции и снижает риск хаотичных правок в production. После каждого инцидента его стоит обновлять по фактическому postmortem. ### Связанные материалы - Все playbooks — открыть связанный материал для проверки контекста. - Диагностика — открыть связанный материал для проверки контекста. - Наблюдаемость — открыть связанный материал для проверки контекста. - Production readiness — открыть связанный материал для проверки контекста. ## FAQ ### Почему webhook отдаёт 404? Частые причины: workflow inactive, используется test URL, неверный path или конфликт route после изменения домена. ### Почему webhook отдаёт 405? Обычно source system отправляет не тот HTTP method, который настроен в Webhook node. ### Что проверить после исправления? Внешний curl, execution history, ответ source system и отсутствие повторных callback retry. ## Мини-чеклист перед публикацией - страница отвечает на один конкретный интент и не повторяет соседний шаблон - в тексте есть уникальные сущности, поля, статусы и проверки для темы - JSON-LD содержит непустой description, image, FAQPage и breadcrumb - в LLM-блоке дан короткий ответ без маркетинговой воды - после правки обновлены search_index.json, llms.txt и sitemap lastmod ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.