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, проверьте реально сохранённую настройку. Скриншот другого выпуска этого не заменяет.

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

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

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

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

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

Версия 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 объясняет смену провайдера шире. Ни одна из них не заменяет проверку точного эндпоинта, используемого сейчас.