Публікація webhook-тригера n8n: від тестового URL до виправлення 404
Як перевести webhook-тригер n8n із тестового URL на робочий, з покроковою інструкцією та діагностикою помилок 404.
Перевірено за наведеними джерелами .
Мета й передумови
У вас уже є робочий процес, що починається з вузла Webhook, і він працює, коли ви натискаєте Listen for test event. Тепер його має викликати зовнішній сервіс по-справжньому. Цей туторіал переводить webhook-тригер n8n із тестового URL, доступного лише в редакторі, на робочий (production) URL, який можна роздавати, а далі показує перевірки, які варто зробити, коли цей робочий URL відповідає помилкою 404 про незареєстрований webhook.
Щоб виконувати кроки, вам потрібні: інстанс n8n, у якому ви можете публікувати робочі процеси, вузол Webhook з HTTP-методом і шляхом, які ви контролюєте, та спосіб надсилати запити. Документація n8n показує curl як ручний спосіб викликати URL webhook тим методом, який налаштований у вузлі; вузол HTTP Request у другому робочому процесі працює так само добре. Тестовий URL відповідає лише після того, як ви спершу запустите робочий процес.
Кожен вузол Webhook показує два URL — тестовий і робочий — угорі панелі вузла з перемикачем між ними. Вони поводяться по-різному навмисно, і більшість проблем із webhook у n8n виникає через те, що один сприймають як інший.
| Тип URL | Реєструється через | Слухає | Де з'являються дані |
|---|---|---|---|
| Тестовий | Listen for test event або запуск неопублікованого робочого процесу | 120 секунд | На полотні редактора |
| Робочий | Публікацію робочого процесу | Доки робочий процес не знято з публікації | Вкладка Executions |
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs
Кроки публікації webhook-тригера n8n
Пройдіть кроки по порядку, щоб запустити свій webhook-тригер n8n. Кожен з них усуває поширену причину невдалого робочого виклику ще до того, як ви поділитеся URL.
- Розробляйте з тестовим URL: натисніть Listen for test event, надішліть запит і прочитайте вхідні дані на полотні. Слухач залишається відкритим 120 секунд, тому вмикайте його знову, якщо запит надходить повільно.
- Задайте стабільний шлях і точний HTTP-метод, який використовуватиме ваш виклик, замість випадкового шляху за замовчуванням.
- Збережіть робочий процес і опублікуйте його. Рекомендація n8n для production — переходити на робочий URL лише після того, як процес збережено та опубліковано.
- Надішліть той самий запит знову, цього разу на робочий URL, і підтвердьте очікувану відповідь за допомогою curl.
- Відкрийте вкладку Executions і переконайтеся, що запуск там є, бо робочі дані не показуються в редакторі.
Поле Path за замовчуванням має випадково згенероване значення, щоб нові вузли не конфліктували з наявними. Замініть його якнайраніше на свідомий, стабільний шлях, за потреби з параметрами маршруту, щоб URL, який ви даєте зовнішньому сервісу, витримав перезбирання вузла. Точно збігайтеся і з HTTP-методом: за замовчуванням вузол приймає один метод, а Allow Multiple HTTP Methods у Settings вузла додає більше, типово GET і POST.
Після публікації робочий webhook слухає, доки ви не знімете робочий процес із публікації. У self-hosted n8n можна також публікувати з CLI сервера за ID робочого процесу; зауважте, що n8n 2.0 замінив перемикач active/inactive на publish та unpublish, а зміни через CLI набувають чинності лише після перезапуску n8n.
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Use the command line | Deploy | n8n Docs
Як читати 404 «webhook not registered»
Тіло помилки корисніше, ніж здається. У описаному випадку на n8n Cloud Starter, зафіксованому як GitHub issue у квітні 2026 року на n8n 2.13.4, робочий webhook-тригер n8n повертав тіло 404 із назвою методу та шляху, які не були зареєстровані, тоді як тестовий URL продовжував працювати. Та сама відповідь містить власну підказку n8n: робочий процес має бути активним, щоб робочий URL виконувався, а робочі виклики з'являються лише у списку виконань. Це дві перевірки, які треба зробити першими.
Далі перевірте сам URL. n8n будує URL webhook із налаштовуваних шляхів endpoint, де N8N_ENDPOINT_WEBHOOK типово має значення webhook, а N8N_ENDPOINT_WEBHOOK_TEST — webhook-test. Запит, надісланий на тестовий шлях, не збігатиметься з опублікованим робочим webhook, і навпаки. Також переконайтеся, що ніщо інше не володіє тією ж комбінацією: n8n дозволяє лише один webhook на шлях і HTTP-метод, тож конфлікт означає, що треба зняти з публікації інший процес або змінити свій шлях чи метод.
Порядок діагностики 404 для робочого webhook
- Прочитайте тіло: Зверніть увагу на метод і шлях, які n8n називає незареєстрованими, та на підказку, що процес має бути активним.
- Підтвердьте публікацію: Перевірте, що робочий процес збережено й опубліковано, а не лише збережено.
- Перевірте сегмент шляху: Переконайтеся, що URL використовує робочий endpoint webhook, а не тестовий.
- Перевірте конфлікт: Лише один webhook може володіти певною комбінацією шляху та HTTP-методу.
- Перебудуйте реєстрацію: Зніміть з публікації й опублікуйте знову або перезапустіть інстанс у self-hosted — як описані обхідні шляхи.
Якщо конфігурація виглядає правильною, то, можливо, бракує самої реєстрації. У self-hosted звіті від липня 2026 року на n8n 2.29.8 у Docker із PostgreSQL 16 описано активацію робочого процесу через публічний API, отримання 200 із active = true — і все одно 404, бо робочий webhook не був зареєстрований у службі webhook n8n, що працює в пам'яті. Обхідні шляхи автора звіту — перезапуск контейнера n8n або деактивація та повторна активація процесу, щоб перебудувати цей стан. Обидва випадки — окремі issue від користувачів на конкретних версіях, а не задокументована поведінка чи виміряна частота відмов, тож сприймайте їх як варіанти для спроби, а не як очікуваний результат.
Ще одне розрізнення зберігає час: якщо ви обмежили тих, хто викликає, IP-списком дозволених адрес, адреса поза ним отримає 403, а не 404. 403 указує на правила доступу; 404 — на реєстрацію.
Sources: Webhook | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Endpoints | Deploy | n8n Docs, All production webhook URLs return 404 "not registered" on n8n Cloud (Starter) · Issue #27976 · n8n-io/n8n · GitHub, Active workflow production webhook URL not registered after activate API call · Issue #34038 · n8n-io/n8n · GitHub
Несподіванки лише в production і посилення захисту
Деякі проблеми з'являються лише тоді, коли ваш webhook-тригер n8n викликає реальний клієнт. За reverse proxy N8N_WEBHOOK_URL задає базовий URL і для тестових, і для робочих webhook; WEBHOOK_URL вважається застарілим з n8n 2.35.0 і пише попередження про застарілість. Якщо дозволені клієнти не можуть підключитися, n8n радить перевірити наявність reverse proxy і встановити N8N_PROXY_HOPS у кількість проксі, за якими стоїть n8n. У n8n Cloud Cloudflare завершує запит статусом 524, якщо webhook не відповідає протягом 100 секунд, тож довгі задачі потребують шаблону «старт плюс опитування» на двох webhook.
Для вузла Webhook на localhost у self-hosted інстансі n8n документує запуск n8n у режимі tunnel, щоб зовнішні клієнти могли до нього дістатися. Сторінка встановлення через Docker, стабільна версія 2.39.8 на момент отримання, описує повний стек із cloudflared-тунелем, який запускає n8n і cloudflared разом і виводить URL тунеля під час старту; для встановлення через npm є варіант лише зі сервісами, який запускає cloudflared окремо й записує базовий URL webhook і значення proxy hops у .env, що читає n8n, — усе одно потребуючи Docker для cloudflared, а встановлення через npm вважається застарілим з n8n 3.0. Документація називає тунелі зручністю для локальної розробки, а не тим, що варто використовувати як робочий URL.
Перш ніж публікувати URL, яким плануєте поділитися, посильте його захист. Пройдіть цей список один раз для кожного webhook.
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Endpoints | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs, Install with Docker | Deploy | n8n Docs, Install with npm | Deploy | n8n Docs
