OAuth, secure cookie и доступ к n8n: домен, HTTPS, callback URL и ошибки входа ¶

Обновлено: 2026-05-29

Большая часть проблем с OAuth в self-hosted n8n появляется не из-за самой интеграции, а из-за адреса, по которому n8n видит себя. Пользователь открывает редактор по HTTPS-домену, контейнер внутри Docker слушает HTTP на 5678, reverse proxy меняет заголовки, а OAuth-провайдер сравнивает callback URL буквально. Если где-то остался localhost, http вместо https или старый домен, credentials не подключатся.

Эта статья разбирает доступ к n8n снаружи: WEBHOOK_URL, N8N_EDITOR_BASE_URL, OAuth callback, secure cookie, SameSite, Cloudflare Access и типовые ошибки входа.

Минимальная схема адресов ¶

N8N_HOST=n8n.example.ru
N8N_PROTOCOL=https
N8N_PORT=5678
WEBHOOK_URL=https://n8n.example.ru/
N8N_EDITOR_BASE_URL=https://n8n.example.ru/
N8N_PROXY_HOPS=1
N8N_SECURE_COOKIE=true
N8N_SAMESITE_COOKIE=lax

Если n8n открыт по HTTPS, N8N_SECURE_COOKIE=true — нормальное значение. Ставить false стоит только для локального HTTP-теста, а не для публичного сервера. Иначе вы снижаете безопасность cookies и маскируете проблему reverse proxy.

OAuth callback URL: что копировать в кабинет сервиса ¶

В credentials n8n показывает OAuth Redirect URL. Именно его надо копировать в Google, Microsoft, Zoom, Todoist, amoCRM или другой кабинет. Для многих self-hosted инстансов callback выглядит примерно так:

https://n8n.example.ru/rest/oauth2-credential/callback

Не придумывайте callback вручную, если n8n показывает готовый URL. Сначала настройте домен и WEBHOOK_URL, перезапустите n8n, потом открывайте credentials и копируйте актуальный callback.

Разбор частых ошибок ¶

Nginx-заголовки, без которых ломается HTTPS-логика ¶

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Если X-Forwarded-Proto не передаётся, n8n может считать соединение небезопасным или строить URL не так, как ожидает OAuth-провайдер.

Cloudflare и доступ из РФ ¶

Если n8n стоит за Cloudflare, проверьте две вещи. Во-первых, внешний домен должен открываться стабильно из сети ваших пользователей и сервисов, которые отправляют webhook. Во-вторых, Cloudflare Access не должен требовать интерактивный вход там, где внешний сервис делает машинный callback или webhook.

Для редактора n8n можно включить дополнительную защиту, но production webhook path обычно оставляют доступным с проверкой подписи, токена, IP allowlist или secret path. Иначе Tilda, ЮKassa, amoCRM, Telegram и другие сервисы не смогут доставить события.

Порядок диагностики за 10 минут ¶

1. Откройте n8n только по одному домену: без www/без localhost.
2. Проверьте WEBHOOK_URL и N8N_EDITOR_BASE_URL.
3. Перезапустите контейнер n8n после изменения env.
4. Откройте credential и скопируйте OAuth Redirect URL заново.
5. Вставьте его в кабинет провайдера.
6. Пройдите OAuth в новом приватном окне браузера.
7. Если проблема осталась, посмотрите response headers и cookies.

Когда не надо отключать secure cookie ¶

Не отключайте secure cookie, если n8n публичный, используется командой или подключён к CRM/почте/платежам. Отключение может “починить” вход только потому, что браузер перестаёт требовать HTTPS для cookie. Это не исправляет неверный proxy, домен или callback URL.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Связанные материалы ¶

• WEBHOOK_URL, HTTPS и reverse proxy
• Nginx, Traefik и Cloudflare Tunnel
• Ошибка OAuth redirect URI
• Диагностика OAuth