Запрос к API может закончиться тремя разными результатами: пришли нужные данные, сервер ответил кодом ошибки или ответа вообще не удалось получить. Соберём схему, которая различает эти случаи. Вместо настоящей CRM используем локальный учебный API: он выдаёт заранее известные ответы и не меняет чужие данные.
Результат инструкции
После запуска получите заказ O-101 на 1200 в Success Result. При 401, 429, 500 или 404 получите запись needs_review в HTTP Failure. При тайм-ауте запись попадёт в Transport Failure. Ни одна ошибка не должна превратиться в готовый заказ. Это ручной прототип диагностики, без автоматической рассылки, оплаты и повторов запроса.
Что понадобится
- Windows с запущенным Docker Desktop и локальный n8n; маршрут рассчитан на Docker Desktop, а не n8n Cloud.
- Права создавать новый учебный workflow. Старые схемы менять не нужно.
- PowerShell и свободный локальный порт 18111. Ключи API, AI-модель и платный сервис не требуются.
Установить локальный n8n через Docker
Шаг 1. Проверьте Docker и откройте отдельную папку
Откройте PowerShell. Создайте папку ezgpt-http-errors в удобном месте и перейдите в неё. docker version должен показать раздел Server. Если его нет, запустите Docker Desktop и дождитесь работающего движка. Не останавливайте остальные контейнеры.
docker version
Get-NetTCPConnection -LocalPort 18111 -State Listen -ErrorAction SilentlyContinueВторая команда не должна показать слушающий процесс. Если порт занят, выберите другой и одинаково поменяйте опубликованный порт в шаге 3 и URL в Demo Input. Внутренний порт API оставьте 18111.
Шаг 2. Скачайте учебный API и workflow
В этой отдельной папке выполните команды ниже. Не используйте папку с одноимёнными рабочими файлами: curl сохраняет результат по указанному имени. Первый файл - небольшой сервер с пятью тестовыми маршрутами, второй - схема из семи узлов. В них нет credentials.
curl.exe --fail --location "https://ezgpt.ru/storage/article-files/n8n-errors-mock-api.cjs" --output n8n-errors-mock-api.cjs
curl.exe --fail --location "https://ezgpt.ru/storage/article-files/n8n-http-errors-demo.json" --output n8n-http-errors-demo.jsonОткройте API в текстовом редакторе перед запуском: /ok возвращает заказ, /unauthorized - 401, /limited - 429, /unavailable - 500, /slow задерживает ответ на три секунды. Любой другой путь возвращает 404. Это наш тестовый код, не API платёжного сервиса.
Шаг 3. Запустите API только на локальном порту
Из папки с файлом выполните одну команду. Она использует официальный образ n8n как среду Node.js; второй экземпляр редактора не запускается. Файл подключён только для чтения, порт опубликован на 127.0.0.1, а не на всех сетевых интерфейсах. Внутри контейнера сервер слушает 0.0.0.0 для работы проброса порта.
docker run --rm -d --name ezgpt-http-errors-api -p 127.0.0.1:18111:18111 --mount "type=bind,source=$((Get-Location).Path),target=/demo,readonly" --entrypoint node n8nio/n8n:2.42.4 /demo/n8n-errors-mock-api.cjs
docker logs ezgpt-http-errors-apiВ журнале должна появиться строка Demo API listening on container port 18111. Если имя контейнера уже занято, сначала разберитесь, что это за контейнер; не удаляйте его автоматически.
Шаг 4. Проверьте ответы вне n8n
curl.exe -i "http://127.0.0.1:18111/ok"
curl.exe -i "http://127.0.0.1:18111/limited"Первый ответ содержит HTTP 200 и заказ. Второй - HTTP 429, Retry-After: 2 и error: demo_rate_limit. curl здесь намеренно без --fail: нужно увидеть тело ошибочного HTTP-ответа. Если ответа нет, проверьте контейнер и порт, а не поля workflow.
{
"order_id": "O-101",
"amount": 1200
}Шаг 5. Импортируйте схему в новый workflow
В локальном редакторе n8n создайте новый workflow. В меню с тремя точками выберите Import from File и файл n8n-http-errors-demo.json. Не импортируйте его поверх рабочей схемы. Проверьте семь узлов: Manual Trigger, Demo Input, Fetch Demo, HTTP Success, Success Result, HTTP Failure, Transport Failure. Оставьте ручной запуск; Publish не нужен.
В Demo Input указан http://host.docker.internal:18111/ok. Этот адрес нужен контейнеру n8n на Docker Desktop. localhost внутри такого контейнера указывает на сам n8n, а не на Windows. Если n8n работает непосредственно в Windows без Docker, используйте http://127.0.0.1:18111/ok. Linux и Cloud требуют другой сетевой настройки и в этом упражнении не проверялись.
Почему контейнер не видит localhost: официальная справка n8n
Шаг 6. Проверьте настройки Fetch Demo
Откройте HTTP Request с именем Fetch Demo. Метод GET, Authentication: None; URL в режиме Expression: {{ $json.url }}. В Options проверьте Response и Timeout.
- Include Response Headers and Status: включено.
- Never Error: включено.
- Response Format: JSON.
- Timeout: 1000 миллисекунд.
- В Settings: On Error → Continue (using error output); Retry On Fail выключен.
Never Error здесь позволяет прочитать HTTP 401/429/500 как данные и затем проверить statusCode. Это не делает ошибочный ответ успешным заказом. Если сервер не прислал ответ вовремя, используем отдельный error output. Обычный Continue для этой схемы не подходит: ошибки должны идти отдельной линией.
Параметры Response и Timeout в HTTP Request
Шаг 7. Проверьте условие успешного HTTP-ответа
Откройте If с именем HTTP Success. В режиме All / AND нужны два числовых условия: {{ $json.statusCode }} greater than or equal 200 и {{ $json.statusCode }} less than 300. Преобразование типов не требуется: HTTP Request возвращает числовой код. Соедините true с Success Result, false с HTTP Failure; error output самого Fetch Demo должен вести напрямую в Transport Failure.
Проверка диапазона 2xx - только первый фильтр. Даже HTTP 200 может содержать неверные бизнес-данные. В нашем /ok форма заранее известна; перед подключением настоящего API добавьте проверку схемы, обязательных полей и признака успеха из его документации.
Шаг 8. Проверьте поля успешного результата
В Edit Fields с именем Success Result выберите Manual Mapping и четыре поля ниже. status - Fixed, остальные значения - Expression. Типы status/order_id: String, http_status/amount: Number. Include Other Input Fields выключено.
status: ready
http_status: {{ $json.statusCode }}
order_id: {{ $json.body.order_id }}
amount: {{ $json.body.amount }}Выполните весь workflow с адресом /ok. Success Result должен содержать одну запись: status ready, http_status 200, order_id O-101, amount 1200. HTTP Failure и Transport Failure в этом запуске не должны выполняться.
Шаг 9. Проверьте HTTP-ошибку и сохраните её код
В HTTP Failure оставьте только пять полей. Fixed: status = needs_review, error_kind = http. Expression: http_status = {{ $json.statusCode }}, message = {{ $json.body.error ?? "demo_http_error" }}, retry_after = {{ String($json.headers["retry-after"] ?? "") }}. Тип http_status - Number, остальных - String.
В Demo Input поменяйте только окончание URL на /limited и выполните весь workflow заново. Получится запись ниже. Успешная ветка не выполняется. Значение retry_after только сохранено, никакого ожидания или повторного запроса схема не делает.
{
"status": "needs_review",
"error_kind": "http",
"http_status": 429,
"message": "demo_rate_limit",
"retry_after": "2"
}Для настоящего API имя поля error и формат тела могут быть другими. Не копируйте эту формулу вслепую. Retry-After также может быть HTTP-датой, а не числом секунд; здесь API специально возвращает строку 2.
Шаг 10. Проверьте тайм-аут через error output
В Transport Failure должны быть String-поля status = needs_review, error_kind = transport и message в Expression с формулой ниже. Это отдельная запись о транспортном сбое, без выдуманного http_status: HTTP-ответа с кодом может вообще не быть.
{{ $json.error?.message ?? $json.error ?? "demo_transport_error" }}Поменяйте Demo Input на /slow и запустите всю цепочку. API ждёт три секунды, Timeout в Fetch Demo равен одной секунде. В нашем тесте Transport Failure получил сообщение timeout of 1000ms exceeded. HTTP Failure и Success Result не выполнялись. Точный текст сообщения может отличаться в другой версии.
Это проверка тайм-аута ожидания ответа, не полная проверка DNS, TLS и обрывов во время большой загрузки. Не выключайте проверку сертификатов ради подключения настоящего API.
Шаг 11. Прогоните шесть адресов и восстановите успех
По очереди меняйте только путь в Demo Input и каждый раз выполняйте весь workflow. Проверяйте результаты именно текущего запуска, а не старое OUTPUT или закреплённые данные.
- /ok: Success Result, ready, код 200, заказ O-101 и сумма 1200.
- /unauthorized: HTTP Failure, needs_review, код 401, demo_invalid_token.
- /limited: HTTP Failure, needs_review, код 429, retry_after = "2".
- /unavailable: HTTP Failure, needs_review, код 500, demo_server_error.
- /missing: HTTP Failure, needs_review, код 404, demo_not_found.
- /slow: Transport Failure, needs_review и непустое сообщение. Затем снова /ok: вернётся готовый заказ.
При обработанной ошибке весь workflow может завершиться зелёным статусом: программа дошла до предусмотренной ветки. Бизнес-результат при этом needs_review, не ready. Этот пример показывает данные в OUTPUT, но не пишет их в постоянный журнал и не отправляет уведомление. Для рабочего запуска отдельно подключите хранение результата с ID исходной заявки и ограничьте чувствительные поля.
Шаг 12. Остановите только учебный API
После проверки сохраните ручной workflow без публикации и остановите только контейнер из шага 3. Из-за --rm он будет удалён после остановки; скачанные файлы останутся в вашей папке. Рабочий n8n и остальные контейнеры не затрагиваются.
docker stop ezgpt-http-errors-apiЕсли результат отличается
| Симптом | Причина | Что исправить |
|---|---|---|
| 401 попадает в ошибку узла | Never Error выключен | Включить и проверить If |
| Ошибка названа ready | Ветки If перепутаны | true → успех, false → HTTP Failure |
| Нет statusCode | Не включён полный ответ | Include Response Headers and Status |
| Timeout останавливает схему | Нет отдельного error output | Continue (using error output) |
| Connection refused | API не запущен или неверный адрес | Проверить контейнер, порт и hostname |
| Виден старый ответ | OUTPUT от другого запуска | Снять pin и выполнить всю цепочку |
Почему здесь нет автоматических повторов
Сначала нужно отличать причину сбоя, а затем выбирать действие. Для 401 проверьте credentials; бесконечные повторы не исправят ключ. Для 429 учитывайте лимиты API. Сбой 500 может быть временным, но повтор разрешён не для любой операции. После тайм-аута создания платежа или заказа действие уже могло выполниться на сервере: слепой повтор способен создать дубль.
В этой схеме Never Error превращает HTTP 500 в данные: Retry On Fail не следует считать готовой обработкой таких кодов. Мы оставили его выключенным. Ограниченные повторы, backoff и идемпотентность требуют отдельной настройки и тестов; этот материал их не реализует.
Когда нужен Error Trigger
Отдельный error workflow полезен для необработанных ошибок выполнения. Но в нашем примере HTTP-сбой и тайм-аут сознательно превращены в needs_review, поэтому нельзя ждать от Error Trigger уведомления о каждом таком случае. Для отправки оператору нужно подключать действие к нужной ветке. Уведомления, автоматические триггеры и Error Trigger здесь не настроены.
Обработка ошибок выполнения: официальная документация n8n
Что нельзя подключать в первой версии
Не заменяйте Success Result оплатой, удалением записи или отправкой письма клиенту. Сначала проверьте формат ответа и статус. Не выводите в message весь запрос с токеном или содержимое клиентских документов. Внешнее действие требует своих прав, журналирования и защиты от повторов; зелёная линия на холсте этого не обеспечивает.
Что проверено редакцией
11 октября 2026 года схема выполнена через CLI n8n 2.42.4 в отдельной тестовой базе. Проверены шесть реальных HTTP-сценариев с локальным учебным API: 200, 401, 429, 500, 404 и тайм-аут 1000 мс. Проверки точных данных успеха, кодов и сообщений HTTP-ошибок, Retry-After и отсутствия ready при сбое прошли. Тестовый API остановлен; существующие workflows и основной контейнер n8n не менялись. Ручной запуск в редакторе, Cloud, реальные credentials, DNS/TLS-сбои, автоматические повторы, Error Trigger, уведомления и постоянное хранение журнала не проверялись. Обложка - редакционная иллюстрация, не снимок интерфейса.
Частые вопросы
Почему Never Error не исправляет ошибку API?
Он позволяет получить ошибочный HTTP-ответ как данные. Код всё равно нужно проверить. В этой схеме If направляет 401, 429, 500 и 404 в needs_review, а не в готовый заказ.
Что делать, если n8n не видит localhost?
В контейнере localhost указывает на сам контейнер. Для проверенного маршрута Docker Desktop используется host.docker.internal:18111. Сначала убедитесь, что учебный API запущен и отвечает в PowerShell.
Чем тайм-аут отличается от HTTP 500?
При 500 сервер прислал HTTP-ответ, его код можно сохранить. При тайм-ауте Fetch Demo не дождался ответа и передал ошибку через отдельный error output. В тесте эти случаи попали в разные ветки.
Почему workflow зелёный, хотя получен needs_review?
Ошибка была обработана предусмотренной веткой, поэтому выполнение завершилось. Проверяйте бизнес-статус и данные, а не только цвет: needs_review не является успешным заказом.
Можно ли использовать этот API в n8n Cloud?
Этот маршрут рассчитан на локальный Docker Desktop. Cloud не получает доступ к локальному порту компьютера по host.docker.internal. Не открывайте учебный сервер в интернет ради упражнения; сетевое подключение Cloud нужно проектировать отдельно.
