n8n не принимает webhook: причины и решение

MAATRIX

Сценарий собран, тестовый запуск проходит, а внешний сервис шлёт запрос в пустоту: n8n webhook не работает, в списке выполнений тишина. Проблема почти никогда не в самом n8n — рвётся одно из звеньев между отправителем и нодой Webhook. Ниже — как найти нужное звено: тексты ошибок, конфиг nginx, переменные.

Диагностика за пять минут: где рвётся цепочка

Путь запроса: отправитель → DNS → облако → фаервол → nginx → docker-proxy → n8n → регистрация вебхука → workflow. Чинить наугад бессмысленно. Снаружи, с другой машины:

curl -i -X POST https://n8n.example.com/webhook/crm-lead \
  -H 'Content-Type: application/json' -d '{"ping":1}'

На сервере, мимо nginx и фаервола, плюс проверка процесса:

curl -i -X POST http://127.0.0.1:5678/webhook/crm-lead -d '{"ping":1}'
curl -s http://127.0.0.1:5678/healthz
{"status":"ok"}

Внутренний работает, внешний нет — рвётся между интернетом и nginx. Оба отвечают одинаково — дело внутри n8n. Смотрим, доходит ли запрос до nginx:

grep ' /webhook/' /var/log/nginx/access.log | tail -5
203.0.113.17 - - [28/Aug/2026:11:04:12 +0000] "POST /webhook/crm-lead HTTP/1.1" 404 226 "-" "GitHub-Hookshot/8a1c3f2"

Строка есть — долетел; нет — не дошёл. Дальше по коду ответа:

404: «The requested webhook is not registered»

Самый частый ответ, который видит отправитель:

{"code":404,"message":"The requested webhook \"POST crm-lead\" is not registered.","hint":"The workflow must be active for a production URL to run successfully..."}

Этот JSON отдаёт сам n8n: значит сеть, TLS и прокси в порядке. Причин четыре.

Workflow не активен. У ноды два адреса: тестовый /webhook-test/<path> и боевой /webhook/<path>. Тестовый живёт, только пока в редакторе нажат «Execute workflow»: около двух минут и один запрос. Боевой работает лишь при включённом переключателе Active. Классика: отладили на тестовом, отдали боевой, активировать забыли.

Метод не совпал. В кавычках сообщения указан пришедший метод: "GET crm-lead" при ноде на POST означает, что отправитель шлёт не тем. Сверяйтесь с access-логом, а не со словами интегратора.

Путь отличается. Важен регистр и лишний сегмент, а дефолтный UUID-путь ноды часто остаётся в чужой документации. Ещё ловушка — префикс: при N8N_ENDPOINT_WEBHOOK=hooks боевой адрес станет /hooks/crm-lead, а /webhook/crm-lead вернёт тот же 404.

Путь занят. Второй workflow с тем же путём не активируется: «The URL path that the Webhook node uses is already taken». Не подошло — добавьте N8N_LOG_LEVEL=debug: в docker compose logs -f n8n при активации видно, какие пути регистрируются.

Запрос не доходит: фаервол, Docker, Cloudflare и TLS

UFW не блокирует опубликованные порты Docker. Docker пишет правила в цепочку DOCKER таблицы nat, минуя ufw: ports: - "5678:5678" открывает порт всему интернету, даже когда ufw status показывает deny. Правильно:

    ports:
      - "127.0.0.1:5678:5678"

Проверьте, на чём висит слушатель:

ss -tlnp | grep 5678
LISTEN 0 4096 127.0.0.1:5678 0.0.0.0:* users:(("docker-proxy",pid=1142,fd=4))

Наружу нужны только ufw allow 80/tcp и ufw allow 443/tcp.

IPv6 в одну калитку. У домена есть AAAA-запись, отправитель идёт по IPv6, а nginx слушает только listen 443 ssl; без listen [::]:443 ssl;. Снаружи это таймаут без строки в логах: добавьте IPv6-слушатель или снимите AAAA.

Cloudflare. Оранжевое облако проксирует лишь часть портов — для HTTPS это 443, 2053, 2083, 2087, 2096 и 8443, так что вебхук на 5678 не пройдёт. Bot Fight Mode отдаёт HTML-челлендж 403 вместо JSON, и GitHub его не проходит: спасает WAF Skip для /webhook/* или DNS-only. Плюс лимит ответа около 100 секунд, дальше — 524.

Telegram и порты. Если на setWebhook приходит

{"ok":false,"error_code":400,"description":"Bad Request: bad webhook: Webhook can be set up only on ports 80, 88, 443 or 8443"}

вы дали адрес с портом 5678: Telegram принимает только 80, 88, 443 и 8443 и требует валидный сертификат, то есть только через nginx. Кстати, ошибка SSL certificate problem: unable to get local issuer certificate у отправителя означает, что в nginx указан cert.pem вместо fullchain.pem.

Реверс-прокси: 413, 504 и потерянный POST

Сначала map в секцию http файла nginx.conf — иначе отвалится вебсокет редактора:

map $http_upgrade $connection_upgrade { default upgrade; '' close; }

Дальше сам сайт, /etc/nginx/sites-available/n8n.conf:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name n8n.example.com;
    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;   # 1.3-only отсекает старых клиентов вроде 1С
    client_max_body_size 32m;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 300s;
    }
}

Применяем: nginx -t && systemctl reload nginx. Что здесь важно.

client_max_body_size по умолчанию 1 мегабайт: вебхук с вложением получает 413, а в error-логе nginx — client intended to send too large body: 3145728 bytes. Лимит поднимают и в n8n: N8N_PAYLOAD_SIZE_MAX=32 (в мегабайтах, по умолчанию 16).

proxy_read_timeout по умолчанию 60 секунд: если нода отвечает после выполнения сценария, а тот идёт дольше минуты, отправитель ровно на шестидесятой секунде получает 504 и upstream timed out (110: Connection timed out) в логе. Ответ 502 с connect() failed (111: Connection refused) — наоборот: nginx жив, контейнер лежит.

Слэш в proxy_pass. Адрес пишем без завершающего слэша: с ним внутри location /webhook/ префикс срежется, n8n получит /crm-lead и вернёт 404.

Редирект на HTTPS. Дали интегратору http://-адрес при return 301 https://... — многие клиенты не повторяют POST после редиректа: часть меняет метод на GET, часть теряет тело. Давайте сразу https://.

WEBHOOK_URL и остальные переменные

n8n формирует адрес вебхука не из заголовка Host, а из своих переменных. Разошлись с реальностью — интерфейс покажет ссылку вида http://localhost:5678/webhook/..., её и передадите интегратору.

Значение N8N_PROTOCOL=https заставляет n8n поднимать TLS самому и требовать N8N_SSL_CERT с N8N_SSL_KEY; за прокси оставляйте http, а адрес задавайте через WEBHOOK_URL со слэшем на конце. N8N_PROXY_HOPS=1 нужен, чтобы n8n доверял X-Forwarded-For и видел IP отправителя, а не 172.17.0.1. Проверять надо не файл, а то, что видит процесс:

docker compose exec n8n printenv | grep -E '^(WEBHOOK_URL|N8N_PROTOCOL)='

Расходятся значения по двум причинам: docker compose restart не перечитывает .env (нужен up -d), а при переменной сразу в .env и в блоке environment: выигрывает environment:. Итог покажет docker compose config. Базовая настройка — в статье про установку n8n на VPS.

Отдельный случай — очередь. При EXECUTIONS_MODE=queue и N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true боевые вебхуки обслуживает процесс n8n webhook, и nginx обязан разводить трафик: location /webhook/ { proxy_pass http://127.0.0.1:5679; }. Забудете — 404 при живом сценарии. Честно: очередь нужна от сотен выполнений в час, большинству хватает одного контейнера.

Вебхук приходит, но результат не тот

403 вместо запуска. Ответ {"code":403,"message":"Authorization data is wrong!"} означает, что на ноде включена Header Auth или Basic Auth, а отправитель не прислал заголовок либо ошибся в имени. Это авторизация ноды, а не логин в панель, — их постоянно путают.

Тело приходит пустым. n8n раскладывает запрос на body, headers, query и params. Если отправитель шлёт Content-Type: text/plain или не ставит заголовок вовсе, JSON не разбирается и в body оказывается строка или пустой объект. Лечит опция Raw Body или просьба выставить application/json.

Таймаут отправителя и дубли. У ноды три режима ответа: onReceived отвечает мгновенно телом {"message":"Workflow was started"} и работает дальше в фоне, lastNode держит соединение до конца сценария, responseNode отдаёт ответ ноды Respond to Webhook. Окна короткие: GitHub рвёт соединение через 10 секунд, платёжные шлюзы ждут 20–30, и сценарий с парой запросов к внешним API туда не укладывается. Не получив 2xx вовремя, отправитель повторяет доставку — вот и три одинаковых заказа. Шаблон: onReceived, тяжёлая работа после ответа, дедупликация по идентификатору события.

200 есть, выполнения не видно. Боевые запуски не рисуются на холсте, только во вкладке Executions. Хуже другое: при EXECUTIONS_DATA_SAVE_ON_SUCCESS=none успешные выполнения не сохраняются вообще, и список пуст.

Не туда смотрите. Предупреждение про N8N_RUNNERS_ENABLED к вебхукам отношения не имеет, а Wait и Form Trigger живут на префиксах /webhook-waiting/<executionId> и /form/<path>. Прочее — в статье про частые ошибки n8n.

Какой сервер нужен под n8n с вебхуками

Вебхуки требуют того, чего нет у локального n8n: белый статический IP, корректный HTTPS на 443 и запас на пик, когда отправитель за минуту выгружает накопившуюся очередь.

Минимум — 2 vCPU, 2 ГБ RAM, 20 ГБ NVMe. Хватает для n8n на SQLite, десятка сценариев и редких вебхуков без вложений. Минус назову прямо: с N8N_PAYLOAD_SIZE_MAX=32 пара параллельных выполнений с крупным JSON выносит контейнер по памяти. Выглядит как остановка без ошибок в логах, а причина — в журнале ядра:

dmesg -T | grep -i 'out of memory'
[Fri Aug 28 11:12:40 2026] Out of memory: Killed process 1187 (node) total-vm:2913204kB

Комфортный вариант — 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. n8n с PostgreSQL 16 в соседнем контейнере, параллельные выполнения и вложения. В покое по docker stats контейнер n8n занимает около 320 МБ, база — под 100 МБ, остальное уходит на пики. Диск съедает история выполнений: включайте очистку сразу, EXECUTIONS_DATA_PRUNE=true и EXECUTIONS_DATA_MAX_AGE=336 (в часах, то есть 14 дней). Расчёт памяти — в материале про требования n8n к серверу.

Локация. Для вебхуков от зарубежных SaaS — GitHub, Stripe, HubSpot, Notion, европейских CRM и платёжных систем — берите UK, Лондон: у большинства из них европейские точки выхода, RTT Лондон — Франкфурт держится в районе 10–15 мс, Лондон — Нью-Йорк около 75–80 мс, а европейский IP реже попадает под бот-фильтры. Плюс GDPR-соседство. Оговорка: когда отправители российские — amoCRM, Битрикс24, 1С, банковские колбэки, — берите RU: короче путь и меньше сюрпризов с фильтрацией. Если вебхук триггерит обращения к OpenAI или Anthropic — US с чистым IP.

В MAATRIX сервер под n8n поднимается за несколько минут, с белым статическим IP и любой из локаций UK, US, FR или RU, а оплатить можно картой российского банка, по СБП, криптой или токеном MAAT — иностранная карта не нужна даже для Лондона. Не уверены в конфигурации — опишите нагрузку: сколько сценариев, какие отправители, есть ли вложения. Про AI-сценарии — в статье про n8n с моделями на сервере.

Частые вопросы