HTTPS для n8n: настройка обратного прокси с Caddy или Nginx

Вы настраиваете HTTPS для n8n, размещая обратный прокси, такой как Caddy или Nginx, перед экземпляром n8n. Прокси берет на себя SSL-шифрование во внешнем контуре и передает запросы внутри без шифрования на n8n. Чтобы это работало, сам n8n должен знать, по какому публичному адресу он доступен, иначе приложение показывает неверные URL вебхуков, а триггеры из внешних сервисов не срабатывают. Отвечающие за это переменные называются WEBHOOK_URL и N8N_PROXY_HOPS. Состояние: июль 2026.

Почему одного обратного прокси недостаточно?

Одного обратного прокси недостаточно, потому что n8n по умолчанию формирует свои URL из переменных N8N_PROTOCOL, N8N_HOST и N8N_PORT, которые по умолчанию указывают на http, localhost и внутренний порт 5678. Если n8n работает за Caddy или Nginx, приложение внутри по-прежнему видит только HTTP-соединение на порту 5678, тогда как пользователи и внешние сервисы обращаются к экземпляру через HTTPS на порту 443 под вашим собственным доменом. Прокси должен передать это расхождение между внутренним и внешним представлением в n8n. Официальная документация n8n по URL вебхуков за обратными прокси описывает именно эту проблему как отправную точку конфигурации.

Что такое ловушка WEBHOOK_URL?

Ловушка WEBHOOK_URL возникает, когда n8n доступен по HTTPS, но интерфейс и регистрация новых вебхуков по-прежнему используют внутренний или неверный адрес. Для вас как оператора это часто сначала выглядит безобидно, поскольку редактор в браузере загружается нормально. Однако как только внешний сервис, например инструмент для форм или платежная платформа, пытается вызвать зарегистрированный вебхук, запрос завершается ошибкой, потому что сохраненный URL недоступен извне. Согласно документации, вы решаете это, вручную установив WEBHOOK_URL на ваш полный внешний адрес, например https://n8n.ваш-домен.ru/, и N8N_PROXY_HOPS на количество предшествующих прокси, то есть 1 в настройках с одним прокси.

Какие заголовки должен передавать ваш прокси в n8n?

Ваш прокси должен передавать в n8n как минимум три заголовка, чтобы настройка WEBHOOK_URL вообще вступила в силу. Документация n8n конкретно называет для этого следующие заголовки.

• X-Forwarded-Proto: сообщает n8n, поступил ли исходный запрос на прокси по HTTP или HTTPS.
• X-Forwarded-Host: передает имя хоста, к которому обратился пользователь, то есть ваш настоящий домен вместо внутреннего имени.
• X-Forwarded-For: передает реальный IP-адрес клиента, который иначе исчез бы за IP-адресом прокси.

Если эти заголовки отсутствуют или N8N_PROXY_HOPS настроен неверно, n8n игнорирует переданную информацию и возвращается к внутренним значениям по умолчанию, даже если WEBHOOK_URL задан.

Caddy или Nginx: что подходит для вашей настройки n8n?

Для самого n8n не имеет значения, используете ли вы Caddy или Nginx в качестве обратного прокси, при условии, что указанные заголовки поступают корректно и заданы WEBHOOK_URL и N8N_PROXY_HOPS. Разница заключается в трудозатратах на обслуживание: Caddy выпускает и обновляет сертификаты автоматически, тогда как в Nginx вы сами организуете выпуск сертификата, например через Certbot, и вручную прописываете заголовки в конфигурации сервера. Альтернативно документация n8n по настройке SSL описывает также способ вообще без отдельного обратного прокси: вы задаете N8N_SSL_CERT и N8N_SSL_KEY, чтобы n8n сам напрямую считывал сертификат и ключ. В этом случае, однако, вы сами несете ответственность за своевременное обновление, что при использовании Caddy обычно происходит автоматически.

Почему вход в систему иногда не работает, несмотря на правильный сертификат?

Вход в систему иногда не работает, несмотря на правильный сертификат, потому что n8n по умолчанию помечает сессионные cookie как "secure", что управляется через N8N_SECURE_COOKIE со значением по умолчанию true. Cookie, помеченный как secure, браузер передает исключительно через действительно зашифрованное HTTPS-соединение. Если информация об HTTPS не доходит до n8n через X-Forwarded-Proto, n8n считает соединение внутри незашифрованным и отклоняет cookie, из-за чего форма входа завершается ошибкой без явного сообщения об ошибке. WEBHOOK_URL, заголовки прокси и N8N_SECURE_COOKIE технически взаимосвязаны и поэтому их всегда следует проверять вместе.

Если для продуктивного использования это кажется вам слишком подверженным ошибкам, в NordFlux мы берем на себя настройку хостинга в рамках наших услуг по n8n по фиксированной цене, включая описанную здесь настройку HTTPS и вебхуков.

Часто задаваемые вопросы о HTTPS для n8n

Нужно ли мне вручную задавать WEBHOOK_URL, если мой прокси уже терминирует SSL?

Да, вам нужно вручную задавать WEBHOOK_URL почти в любой настройке обратного прокси, потому что иначе n8n не знает внешний адрес. Прокси действительно терминирует шифрование, но это не меняет того, что n8n внутри по-прежнему использует значения по умолчанию из N8N_PROTOCOL, N8N_HOST и N8N_PORT. Только явно заданный WEBHOOK_URL гарантирует, что зарегистрированные вебхуки содержат действительно доступный адрес.

В чем разница между обратным прокси и прямыми SSL-сертификатами в n8n?

Разница в том, кто терминирует шифрование: при обратном прокси, таком как Caddy или Nginx, прокси берет на себя сертификат, а связь с n8n внутри осуществляется по HTTP. При прямых сертификатах n8n сам считывает сертификат и ключ через N8N_SSL_CERT и N8N_SSL_KEY, а обновление вы управляете самостоятельно.

Сколько прокси-переходов указывать в N8N_PROXY_HOPS, если перед Caddy или Nginx работает Cloudflare?

При одном обратном прокси перед n8n укажите 1, при дополнительном уровне впереди, таком как Cloudflare, соответственно выше. Значение должно точно соответствовать количеству станций, через которые проходит запрос, иначе n8n неверно интерпретирует заголовки X-Forwarded. В случае сомнений проверьте с помощью входящего вызова вебхука, какой IP-адрес клиента n8n фактически регистрирует.

Могу ли я запустить n8n по HTTPS без собственного домена?

Технически Caddy и большинство бесплатных удостоверяющих центров требуют домен с публичной DNS-записью, простого IP-адреса для этого на практике недостаточно. Для продуктивных вебхуков от внешних сервисов вам в любом случае нужен стабильный, публично доступный адрес, поэтому собственный поддомен для n8n рекомендуется также независимо от темы сертификата.