Как настроить и принять HTTPS для n8n на своём сервере

Self-hosted n8n должен открываться для сотрудников и принимать webhook по предсказуемым защищённым адресам. Для приёмки недостаточно увидеть значок замка в браузере: нужно зафиксировать путь запроса, проверить публичный URL webhook и провести безопасное тестовое событие через фактический прокси.

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

Какую рабочую задачу решает HTTPS

HTTPS шифрует транспортное соединение на проверяемом участке и позволяет клиенту проверить имя сервера по сертификату. В этой задаче защищённый адрес нужен двум маршрутам:

• сотрудник открывает редактор n8n;
• внешний сервис отправляет событие на webhook.

Успешное соединение по HTTPS не доказывает безопасность всей инсталляции. Оно не проверяет роли, SSO, хранение секретов, публичный API, выполнение кода, журналы, резервные копии и исходящие соединения. Эти вопросы требуют отдельного разбора, например при проверке доступа и данных в n8n.

Практический результат этого этапа — не формулировка «HTTPS включён», а описанный маршрут с ответственными и проверяемыми условиями.

Зафиксировать домен, маршруты и точку завершения TLS

Начните со схемы из четырёх элементов:

1. Внешний клиент или сервис отправляет запрос.
2. Публичный домен указывает на доступную точку входа.
3. Reverse proxy или балансировщик принимает соединение.
4. n8n обрабатывает запрос во внутреннем контуре.

Для каждого участка запишите адрес, протокол и владельца настройки. Отдельно укажите:

Документация n8n описывает два способа поддержки TLS: поставить reverse proxy или сетевой балансировщик перед n8n либо передать сертификат приложению напрямую. n8n рекомендует вариант с reverse proxy, но эта рекомендация не делает его обязательным для любой инфраструктуры. Она также не подтверждает защиту внутреннего участка между прокси и приложением — его проверяют отдельно.

Выбрать способ работы с сертификатом

Сравните два документированных варианта с фактической архитектурой.

При прямом TLS пути к файлам сертификата и ключа задают через N8N_SSL_CERT и N8N_SSL_KEY. Эти имена подтверждены текущей документацией, но она не определяет подходящие права на файлы, место хранения и процедуру выпуска для вашей среды. Не публикуйте закрытый ключ, значения секретов и реальные внутренние адреса.

Reverse proxy может взять на себя работу с продлением сертификата, если такая возможность настроена в выбранном прокси. Для приёмки всё равно нужен конкретный владелец процесса. Запишите, кто:

• выпускает и устанавливает сертификат;
• следит за сроком действия;
• получает наблюдаемый сигнал при ошибке;
• проверяет продление;
• восстанавливает доступ после неудачного обновления.

Согласовать внешний адрес n8n и webhook

Внутренний адрес приложения и публичный адрес могут различаться. Например, n8n работает внутри контура на порту 5678, а reverse proxy публикует домен через порт 443. Поэтому адрес, который n8n собирает из внутренних параметров, может не подойти внешнему сервису.

При работе за reverse proxy документация требует вручную задать публичный адрес webhook через N8N_WEBHOOK_URL. Тогда n8n может показывать его в редакторе и регистрировать корректный URL во внешнем сервисе.

Имя WEBHOOK_URL объявлено устаревшим начиная с n8n 2.35.0; вместо него документация использует N8N_WEBHOOK_URL. Перед изменением проверьте установленную версию n8n и актуальную для неё документацию. Не переносите параметр из примера вслепую в другую версию.

В листе приёмки сопоставьте три значения:

Передать n8n сведения об исходном запросе

За reverse proxy приложение видит не исходное соединение, а запрос от посредника. Последний прокси на маршруте должен передать n8n сведения об исходном клиенте, хосте и протоколе через заголовки:

• X-Forwarded-For;
• X-Forwarded-Host;
• X-Forwarded-Proto.

В документированном примере с одним прокси используется N8N_PROXY_HOPS=1. Значение 1 нельзя считать универсальной настройкой: число доверенных переходов зависит от реальной цепочки. Зафиксируйте все прокси и балансировщики на пути, определите последний доверенный узел и проверьте, какие посредники могут создавать или менять forwarded-заголовки.

Такая запись помогает избежать двух ошибок: доверять заголовкам от непредусмотренного источника или указать число переходов, которое не соответствует архитектуре.

Условный маршрут без рабочих последствий

Ниже — синтетический проектный пример. Это не клиентский кейс Switch On AI и не результат выполненного теста.

Условная компания разместила n8n во внутреннем контейнере и публикует automation.example.ru через reverse proxy. TLS завершается на прокси. По проектному требованию внутренний порт n8n не должен быть напрямую доступен из интернета. В конфигурации задан внешний HTTPS-адрес webhook, а последний прокси передаёт сведения об исходном протоколе и хосте.

Безопасная учебная последовательность выглядит так:

1. Внешний отправитель обращается к тестовому webhook по HTTPS.
2. Reverse proxy принимает TLS-соединение и передаёт запрос n8n.
3. Тестовый workflow принимает искусственное событие без записи в CRM и отправки писем.
4. n8n возвращает заранее согласованный контролируемый ответ.

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

Пример ожидаемого результата:

Как проверить настройку перед запуском

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

Добавьте негативные сценарии, но не связывайте их с опасными рабочими действиями:

• неверный путь не запускает тестовый workflow;
• неподходящий хост не попадает на разрешённый маршрут;
• повтор события обрабатывается по заранее записанному правилу;
• недоступный backend не выглядит как успешная обработка;
• просроченный или не соответствующий имени сертификат выявляется в контролируемой среде.

Не задавайте произвольное число тестов ради отчёта. Каждый сценарий должен проверять конкретный риск. Для результата сохраните входное событие, ожидаемое поведение, фактическое поведение и найденное расхождение. Общий подход к такой проверке описан в сценариях приёмки автоматизации.

Ограничения, эксплуатация и следующий шаг

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

Перед запуском должен остаться короткий эксплуатационный паспорт:

• публичный домен и назначение маршрутов;
• точка завершения TLS и внутренняя схема соединения;
• версия n8n и используемые имена параметров;
• фактическая цепочка прокси и число доверенных переходов;
• владелец сертификата и процедура продления;
• сигнал об ошибке и порядок восстановления;
• тестовый workflow и журнал последней приёмки.

Если нужно спроектировать такой маршрут и подготовить критерии приёмки, Switch On AI занимается разработкой и внедрением автоматизации. Для первого обсуждения подготовьте внешний домен, схему размещения n8n и прокси, перечень будущих webhook и сведения о текущем управлении сертификатами. Мы разберём процесс, согласуем ограниченный прототип и требования, а объём внедрения, стоимость, сроки и сопровождение зафиксируем отдельно в предложении и договоре.