OAuth redirect ведёт на localhost: исправляем учётные данные Google/Microsoft

Если n8n при подключении аккаунта Google или Microsoft показывает ошибку redirect_uri_mismatch, или вы после нажатия «Sign in» неожиданно попадаете на http://localhost:5678/..., это почти всегда происходит из-за того, что n8n всё ещё формирует адрес обратного вызова (callback) для входа через OAuth из значений по умолчанию localhost и порта 5678, вместо вашего реального публичного домена. Google или Microsoft сравнивают этот redirect URI, отправленный сервером n8n, со списком, который вы сохранили в Google Cloud Console либо в регистрации приложения Microsoft, и отклоняют вход, как только эти значения не совпадают в точности. Решение состоит в том, чтобы правильно задать переменные окружения N8N_HOST, N8N_PROTOCOL и, прежде всего, WEBHOOK_URL или N8N_EDITOR_BASE_URL со значением публичного домена, а затем ввести у провайдера OAuth без изменений redirect URI, показанный в форме учётных данных n8n. По состоянию на: июль 2026 года.

Почему n8n вообще формирует redirect URI из localhost?

По умолчанию n8n автоматически вычисляет адреса редактора и вебхуков из трёх переменных, и без собственной настройки при этом, согласно документации n8n о переменных окружения для развёртывания применяются значения по умолчанию: http в качестве N8N_PROTOCOL, localhost в качестве N8N_HOST и 5678 в качестве N8N_PORT. Пока вы тестируете n8n только локально на своём компьютере, это не проблема, потому что браузер действительно обращается через localhost. Но как только n8n запускается на сервере, в Docker или за reverse proxy, Google или Microsoft всё равно обращаются к тому же самому автоматически вычисленному значению localhost, потому что n8n снаружи не знает, под каким доменом он на самом деле доступен.

Как правильно настроить N8N_HOST, WEBHOOK_URL и N8N_EDITOR_BASE_URL?

Наиболее надёжное решение - вручную задать WEBHOOK_URL с полным публичным доменом, так как эта переменная, согласно документации n8n о настройке webhook-адресов за reverse proxy перезаписывает весь автоматически вычисленный URL и отображается как в редакторе, так и регистрируется у внешних сервисов.

• WEBHOOK_URL: задать полный публичный адрес с завершающим слэшем, например https://n8n.вашдомен.ru/, чтобы n8n использовал этот домен вместо localhost.
• N8N_HOST: задать только сам домен без протокола, например n8n.вашдомен.ru, так как n8n использует это значение вместе с N8N_PROTOCOL и N8N_PORT для автоматического вычисления URL.
• N8N_PROTOCOL: задать значение https, как только ваш сервер станет доступен по SSL, так как значение по умолчанию согласно документации - http.
• N8N_EDITOR_BASE_URL: публичный URL, по которому пользователи открывают редактор; согласно документации, он также используется для писем от n8n и в качестве redirect URL при входе через SAML.
• N8N_PROXY_HOPS: задать значение 1, если перед сервисом стоит reverse proxy, чтобы n8n корректно обрабатывал заголовки перенаправления.

После задания этих переменных процесс или контейнер n8n необходимо перезапустить, так как n8n считывает переменные окружения только при запуске.

Как конкретно устранить ошибку redirect_uri_mismatch?

Ошибка возникает из-за того, что n8n при запуске OAuth-потока отправляет Google или Microsoft параметр redirect_uri, который не совпадает с redirect URI, сохранённым у провайдера, поэтому вам нужно вручную сверить обе стороны. После перезапуска n8n снова откройте затронутые учётные данные и отобразите текущий OAuth redirect URL, который n8n формирует по пути /rest/oauth2-credential/callback. Скопируйте этот адрес без изменений в список авторизованных redirect URI вашего OAuth-клиента Google или регистрации приложения Microsoft и сохраните там. Для подключений Google документация n8n по проблемам с Google Drive прямо указывает, что N8N_EDITOR_BASE_URL и WEBHOOK_URL должны использовать полностью определённые (fully qualified) домены, чтобы избежать именно этого redirect URI mismatch. После этого заново подключите учётные данные в n8n, чтобы был получен обновлённый токен.

Что ещё важно, если n8n работает за reverse proxy или в Docker?

Если n8n работает в контейнере за nginx, Traefik или Cloudflare Tunnel, простого задания переменных иногда недостаточно, потому что прокси должен передавать n8n исходные заголовки, такие как X-Forwarded-Proto и X-Forwarded-Host, чтобы сервис внутри знал, что запрос действительно пришёл через https и публичный домен. Поэтому дополнительно к настройке прокси проверьте, задана ли переменная N8N_PROXY_HOPS, потому что без этого значения n8n не доверяет заголовкам перенаправления от прокси и внутренне снова переходит на значения по умолчанию. Тот, кто хочет использовать инстанс n8n в продуктивной среде с несколькими OAuth-подключениями и не хочет заново перенастраивать redirect URI при каждом переезде сервера, выигрывает от аккуратно задокументированной настройки; это один из моментов, в которых NordFlux при настройке n8n оказывает поддержку, чтобы автоматизации с немецким суверенитетом данных стабильно работали и после обновления.

Часто задаваемые вопросы о проблемах с OAuth redirect в n8n

Нужно ли перезапускать n8n после задания переменных?

Да, перезапуск обязателен, так как n8n считывает переменные окружения только при запуске процесса или контейнера. Без перезапуска старый redirect URI на основе localhost остаётся активным, даже если WEBHOOK_URL или N8N_HOST уже заданы правильно.

Достаточно ли задать только WEBHOOK_URL?

В большинстве случаев да, так как, согласно документации n8n, WEBHOOK_URL перезаписывает весь автоматически вычисленный URL и тем самым также исправляет адрес OAuth callback. Дополнительно N8N_EDITOR_BASE_URL нужен только в том случае, если ссылки в автоматически отправляемых письмах или SAML-редиректах всё ещё отображаются неверно.

Почему redirect_uri_mismatch иногда возникает и в n8n Cloud?

Ошибка может возникать и в n8n Cloud, если redirect URL, показанный в диалоге учётных данных, больше не совпадает точно с адресом, сохранённым у провайдера, например после смены домена workspace. В этом случае помогает снова скопировать текущий отображаемый redirect URI и обновить его в Google Cloud Console или в регистрации приложения Microsoft.

Действует ли то же решение и для учётных данных Microsoft?

Да, принцип для подключений Microsoft или Azure идентичен, так как и там требуется точное совпадение между redirect URI, отправляемым n8n, и reply URL, сохранённым в регистрации приложения. Поэтому задайте те же переменные N8N_HOST, N8N_PROTOCOL и WEBHOOK_URL и внесите адрес, показанный в учётных данных n8n, в список reply URL вашей регистрации приложения Azure.