n8n: проверка подключения проходит, но рабочий процесс выдаёт 404

Успешная проверка учётных данных OpenAI в n8n не доказывает поддержку эндпоинта, используемого рабочим процессом. Проверка может обращаться к списку моделей, а генерация — к другому маршруту. Если провайдер принимает /models, но не выбранный запрос /responses, проверка проходит, а workflow всё равно завершается ошибкой.

Ниже отдельно рассматриваются учётные данные OpenAI, узел действий OpenAI и подузел OpenAI Chat Model. Выводы привязаны к конкретному исходному коду, а не к предположению об одинаковых настройках всех версий n8n. В существующей китайской статье описан исторический локальный тест на подготовленном стенде; эта локализация не выдаёт его за новый тест рабочей среды.

Base URL задаётся в учётных данных

В credentials OpenAI есть поле Base URL для альтернативного корня совместимого API. Укажите корень из документации провайдера, а не полный URL конкретной операции генерации.

Например, корень может оканчиваться на /v1, после чего узел добавляет собственный путь. Если вместо корня вставить полный /chat/completions, при добавлении следующего эндпоинта может получиться неверный путь. Конкретная ошибка зависит от провайдера; один статус 404 не устанавливает причину.

В зафиксированном исходном коде credentials n8n 2.36.9 видны поле Base URL и проверка через /models. Полный запрос генерации чата в рамках этой проверки не отправляется.

Три операции с разными гарантиями

Если провайдер выдаёт список моделей без аутентификации, успешный список мало говорит о корректности ключа. Это не универсальное поведение провайдеров, и ошибка генерации сама по себе не доказывает невалидность ключа. Проверьте требования аутентификации и фактический ответ.

Определите, какой узел завершился ошибкой

В документации узла действий OpenAI перечислены разные операции генерации. OpenAI Chat Model — отдельный подузел, часто подключаемый к AI Agent, со своими настройками. Инструкции для одного нельзя механически переносить на другой.

В n8n 2.36.9 реализация Chat Model показывает настройку Responses для typeVersion 1.3 и выше и задаёт для неё значение true по умолчанию в интерфейсе. Но явные параметры сохранённого workflow и фактическое выполнение также важны. Это утверждение о конкретной версии исходного кода, а не обо всех установках.

Общая документация или старое руководство могут описывать другое значение по умолчанию. Экспортируйте нужный узел, запишите type и typeVersion, проверьте реально сохранённую настройку. Скриншот другого выпуска этого не заменяет.

Соберите минимальный процесс для проверки генерации

Скопируйте проблемный workflow и оставьте копию неактивной. Отключите узлы отправки писем, записи данных, списания денег и публикации. Для начала хватит Manual Trigger и одной генерации OpenAI. Так вызов API отделяется от цикла инструментов агента, памяти и дальнейшего парсинга. Сама генерация всё ещё может расходовать квоту или оплачиваться.

Создайте или выберите OpenAI credential для нужного провайдера, укажите документированный корень API и ключ, сохраните. Если корень — https://provider.example/v1, именно такой вид должен иметь Base URL; домен здесь условный, обращаться к нему не нужно. Не вставляйте /chat/completions или /responses в поле корня и не добавляйте /v1 второй раз из-за чужого примера.

В узле действия выберите операцию для поддерживаемого провайдером эндпоинта. Укажите точный ID модели для этого маршрута, не рекламное название. Если поддерживается Chat Completions, но не Responses, используйте chat-операцию вашей установленной версии узла. Передайте одно сообщение «Reply with ready.» и уберите инструменты, картинки и structured output из первой проверки.

Запустите только эту изолированную цепочку. Критерий успеха — завершённый узел с доступным для просмотра сгенерированным содержимым, а не зелёная отметка credential. Сохраните время, маршрут, статус и форму ответа. Затем возвращайте производственные зависимости по одной. Если базовый вызов работает, а инструмент ломается, исследуйте добавленную функцию, а не уже проверенный Base URL.

Для AI Agent с подузлом OpenAI Chat Model проверяйте сохранённый typeVersion и настройку Responses именно подузла. Успешный узел действия полезен для сравнения, но не меняет конфигурацию агента. После правки проверьте его настоящий исходящий путь: два узла необязательно формируют одинаковые запросы.

Сравните формы запросов, не смешивая поля

Упрощённые тела JSON ниже показывают важность маршрута. Замените MODEL_ID на документированный идентификатор. Это не экспорт workflow n8n и не доказательство поддержки у конкретного провайдера.

Chat Completions использует массив messages:

{"model":"MODEL_ID","messages":[{"role":"user","content":"Reply with ready."}]}

Responses использует input:

{"model":"MODEL_ID","input":"Reply with ready."}

Провайдер может реализовать один маршрут, оба или только часть функций. Отправка тела Responses на chat URL не превращает его в chat-запрос. Парсер для choices[0].message.content тоже не начинает автоматически понимать output-item структуру Responses. Отличайте сырой ответ провайдера от нормализованного результата узла n8n.

Чтобы исключить поведение специализированного узла при диагностике, можно создать отдельный HTTP Request с документированным методом, полным URL операции, аутентификацией и JSON. Секреты храните через механизм credentials n8n. Сравните один безопасный вызов с неудачным узлом, но не заменяйте весь production workflow лишь на основании этого успеха. Исходному узлу могут дополнительно требоваться streaming, вызовы инструментов или другая функция.

Проследите путь неудачного запроса

1. Запишите версию n8n, тип узла, typeVersion и операцию.
2. Проверьте корень Base URL и точный ID модели, не раскрывая ключ.
3. В обезличенном журнале или трассировке провайдера выясните, пошёл ли запрос в /responses или /chat/completions.
4. Сопоставьте маршрут с поддержкой конкретной модели у провайдера.
5. Если для модели документирован Chat Completions, выберите эту операцию или измените настройку Chat Model, затем снова проверьте фактический путь.

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

Не запускайте повторно рабочий процесс с внешними действиями только ради проверки URL. Изолируйте вызов модели с безвредным вводом и отключите инструменты, отправляющие сообщения или меняющие записи. Минимальный пример должен позволять непосредственно изучить ответ.

Изучите фактический URL до очередной правки credentials

Это диагностические признаки, а не утверждения о формировании URL во всех выпусках. Трасса провайдера, журнал reverse proxy или разрешённая трассировка приложения надёжнее догадок по общему сообщению обёртки. Перед сохранением и передачей удалите заголовки авторизации.

Если провайдер вообще не видит запрос, проверьте DNS, TLS, прокси и доступность сети из среды исполнения n8n. Успешное открытие на ноутбуке не доказывает доступ из контейнера или удалённого worker. Не делайте отключение проверки сертификатов стандартным решением; сохраняйте фактическую транспортную ошибку.

После маршрута проверьте поток данных

Начните с одного входного item, затем возьмите два различимых: «Return ALPHA» и «Return BETA». Проверьте, какой промпт реально отправляется. Выражения подузлов могут разрешаться иначе, чем у обычных узлов. Перед предположением о независимой обработке каждого item прочитайте документацию Chat Model. Так выявляется другой сбой: запрос успешен, но обрабатывает не тот вход.

Далее верните только нужные функции. Для structured extraction проверьте поля, для инструментов — вызов и результат, для streaming — сбор итогового текста. Сохраните простой текстовый запрос как базу, чтобы связать последующий сбой с только что добавленной функцией.

В конце сохраните обезличенную конфигурацию и рабочую копию. Зафиксируйте версию n8n, node typeVersion, операцию, корень API, ID модели и значимые настройки, но не значение ключа. После обновления n8n повторите этот маленький тест до включения всей автоматизации. Это проверка поведения, а не доверие зелёному значку или старому скриншоту.

Минимальная запись для поддержки

Версия n8n:
Тип узла и typeVersion:
Выбранная операция / настройка Responses:
Корень API провайдера:
Точный ID модели:
Наблюдаемые HTTP-метод и путь:
HTTP-статус и обезличенное тело ошибки:
ID запроса, если предоставлен:

Не публикуйте ключ API, заголовок авторизации или полный экспорт приватного workflow. Сохраняйте в обезличенном примере маршрут и поля ошибки, удаляя учётные данные и чувствительные запросы.

В историческом issue #21651 описаны успешная проверка credentials и ошибка 404 при выполнении через стороннего провайдера в n8n 1.118.2. Это подтверждает существование симптома, но не доказывает сохранение той же старой ошибки в вашей версии.

Не ограничивайтесь первым объяснением

404 также может возникать из-за неверного ID модели, особого маршрута провайдера, лишнего сегмента пути или обратного прокси. Если ошибку выдаёт сам /chat/completions, сохраните ответ и проверьте эти варианты, прежде чем считать Responses единственной причиной.

Руководство по model-not-found (на английском) разбирает доступ к моделям и идентификаторы. Инструкция по миграции API объясняет смену провайдера шире. Ни одна из них не заменяет проверку точного эндпоинта, используемого сейчас.