Как настроить прокси для n8n: маршрут исходящих запросов задаётся переменными окружения HTTP_PROXY, HTTPS_PROXY и ALL_PROXY, а для отдельного узла HTTP Request прокси указывается в его параметрах. Обратный прокси настраивается отдельно — через N8N_WEBHOOK_URL, N8N_PROXY_HOPS и заголовки X-Forwarded-*. Ниже — документированный порядок, учебный пример и диагностика типовых ошибок.
Прямой ответ и границы продукта
n8n — платформа автоматизации, которая выполняет рабочие процессы на вашем сервере или в облаке вендора. Прокси в ней решает две разные задачи, и их важно не смешивать.
Первая задача — исходящий трафик. Узлы n8n обращаются к внешним API, и эти обращения можно направить через прокси-сервер. В документации проекта (n8n-docs на GitHub) перечислены переменные окружения HTTP_PROXY, HTTPS_PROXY, ALL_PROXY и NO_PROXY. HTTP_PROXY задаёт URL для проксирования незашифрованных HTTP-запросов, HTTPS_PROXY — для TLS/SSL-шифрованных, ALL_PROXY применяется, когда более конкретные переменные не заданы, а NO_PROXY содержит список хостов, которые идут напрямую.
Вторая задача — входящий трафик. Когда n8n стоит за обратным прокси (nginx, Apache, haproxy), меняются публичные адреса редактора и вебхуков. Документация проекта описывает это в отдельном разделе про настройку webhook URL с обратным прокси.
Границы: переменные окружения управляют исходящими запросами узлов. Прокси для одного узла HTTP Request задаётся в его собственных параметрах. Обратный прокси — это инфраструктура перед n8n. В сообществе n8n на форуме участник отметил, что встроенного механизма перенаправления всех запросов через http/https прокси у продукта нет, и предложил использовать переменные окружения HTTP_PROXY и HTTPS_PROXY для исходящих вызовов.
Если вы только начинаете с автоматизацией, посмотрите историю Алексея Ханипова — она показывает, как устроен вход в профессию.
Условия доступа и источник актуальных требований
Актуальные требования живут в документации проекта. Страница deployment.md в репозитории n8n-docs перечисляет переменные развёртывания для самостоятельно размещённого экземпляра: адреса доступа, шаблоны, шифрование и параметры сервера. Там же приведён блок «Proxy variable priorities».
Приоритет переменных задаёт пакет proxy-from-env, который n8n использует для обработки переменных окружения с суффиксом _PROXY. Документация проекта указывает: строчные версии (например, http_proxy) имеют приоритет над прописными (HTTP_PROXY), когда заданы обе. Это объясняет частую ситуацию, когда прописанная переменная в верхнем регистре игнорируется — рядом оказалась строчная.
Что нужно до начала настройки:
- адрес прокси-сервера и порт;
- логин и пароль, если прокси требует аутентификацию;
- список хостов, которые должны идти напрямую (внутренние API, базы данных, локальные сервисы);
- способ запуска n8n: Docker, docker-compose, systemd или облако вендора.
Для облачного варианта n8n переменные окружения недоступны — там работает только настройка прокси в узле HTTP Request. Это следует из обзора на proxymonkey.io, где отдельный раздел посвящён n8n Cloud и указано, что опция узла остаётся единственным переключателем.
Переменные окружения задаются в docker-compose, в файле окружения или в systemd-юните. Документация проекта приводит пример экспорта: N8N_WEBHOOK_URL и N8N_PROXY_HOPS задаются командой export в оболочке.
Документированный порядок действий
Порядок для глобальной настройки исходящего прокси.
- Определите, какой трафик нужно проксировать. Для незашифрованного HTTP — HTTP_PROXY, для HTTPS — HTTPS_PROXY, для обоих сразу — ALL_PROXY.
- Задайте переменные в окружении процесса n8n. В docker-compose это секция environment, в systemd — директива Environment.
- Проверьте регистр. Если заданы обе версии переменной, строчная переопределит прописную.
- Перечислите хосты, которые должны идти напрямую, в NO_PROXY через запятую. Документация проекта указывает: при использовании HTTP_PROXY, HTTPS_PROXY или ALL_PROXY n8n подключается напрямую к хостам из этого списка.
- Перезапустите n8n и выполните тестовый запрос через узел HTTP Request.
Порядок для настройки прокси в отдельном узле HTTP Request.
- Откройте узел HTTP Request в редакторе.
- Откройте Options → Add option → Proxy.
- Введите полный URL прокси в формате
http://USER:PASS@IP:PORT, подставив свои реквизиты. - Сохраните узел и выполните рабочий процесс.
Порядок для обратного прокси.
- Задайте N8N_WEBHOOK_URL вручную, чтобы n8n показывал корректный адрес вебхука в редакторе и регистрировал его во внешних сервисах. Документация проекта отмечает: N8N_WEBHOOK_URL заменяет WEBHOOK_URL, который устарел начиная с версии 2.35.0, и n8n пишет предупреждение об устаревании при использовании старой переменной.
- Установите N8N_PROXY_HOPS равным 1.
- На последнем прокси в цепочке запроса настройте передачу заголовков X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto.
- Если через тот же обратный прокси работает MCP-сервер экземпляра, обеспечьте пересылку его заголовков.
Документация проекта объясняет причину: n8n формирует адрес вебхука из N8N_PROTOCOL, N8N_HOST и N8N_PORT, и при работе за обратным прокси этот способ даёт неверный результат, поскольку n8n слушает порт 5678 внутри, а прокси публикует его на 443.
| Задача | Инструмент | Где задаётся |
|---|---|---|
| Исходящий трафик всех узлов | HTTP_PROXY, HTTPS_PROXY, ALL_PROXY | Окружение процесса |
| Исключения из прокси | NO_PROXY | Окружение процесса |
| Прокси одного узла | Параметры узла HTTP Request | Редактор n8n |
| Публичный адрес вебхука | N8N_WEBHOOK_URL | Окружение процесса |
| Число прокси в цепочке | N8N_PROXY_HOPS | Окружение процесса |
| Передача исходного адреса | X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto | Обратный прокси |
Учебный пример и критерии проверки
Разберём сценарий: n8n в Docker обращается к внешнему API, а прямой выход в интернет закрыт. Запросы должны идти через корпоративный прокси, внутренний сервис базы данных — напрямую.
Шаг первый. В docker-compose добавляем переменные в секцию environment сервиса n8n: HTTP_PROXY и HTTPS_PROXY с адресом прокси, NO_PROXY со списком внутренних хостов.
Шаг второй. Перезапускаем контейнер.
Шаг третий. Собираем тестовый рабочий процесс: узел HTTP Request делает запрос к внешнему сервису, второй узел HTTP Request обращается к внутреннему хосту из NO_PROXY.
Шаг четвёртый. Запускаем процесс и смотрим результат каждого узла.
Критерии самостоятельной проверки:
- Запишите результат внешнего запроса и сопоставьте его с записью о том же обращении в журнале прокси.
- Для внутреннего запроса проверьте запись хоста в NO_PROXY и подтвердите прямой маршрут по журналам вашей сети.
- Внешний запрос падает с ошибкой соединения — проверьте адрес и порт прокси, а также регистр переменных.
- Внутренний запрос идёт через прокси и падает — проверьте формат списка NO_PROXY: хосты разделяются запятыми.
Для проверки того, что запрос действительно ушёл через прокси, полезно смотреть логи прокси-сервера: успешный внешний запрос оставит там запись с адресом назначения. Для дополнительной проверки используйте отдельный тестовый запрос и меняйте переменную, соответствующую его протоколу: HTTP_PROXY для HTTP или HTTPS_PROXY для HTTPS. Перед интерпретацией результата проверьте строчную версию переменной, NO_PROXY и собственный параметр Proxy узла, поскольку они меняют выбор маршрута.
Отдельный учебный сценарий — прокси для одного узла. Соберите процесс из двух узлов HTTP Request: у первого пропишите прокси в параметрах узла, у второго оставьте глобальные переменные. Сравните поведение при отключённом глобальном прокси. Критерий: узел с собственными параметрами прокси работает независимо от окружения.
Если вы подключаете к n8n языковые модели, пригодятся материалы по Gemini и по Qwen: там разобраны схемы соединения, которые тоже проходят через сетевой маршрут.
Смежные варианты и выбор по задаче
Вариантов настройки четыре, и выбор определяется задачей.
Глобальные переменные окружения. Подходят, когда весь исходящий трафик n8n должен идти через один прокси. Плюс: одна точка настройки. Минус: затрагивает все узлы сразу, включая те, которым прокси не нужен.
Прокси в узле HTTP Request. Подходит, когда прокси нужен выборочно. Работает и в облачной версии, где переменные окружения недоступны. Минус: настраивается для каждого узла отдельно.
Обратный прокси. Решает задачу публикации n8n наружу: адреса редактора и вебхуков, передача исходного адреса клиента. К исходящему трафику отношения не имеет.
Комбинация. Глобальные переменные для исходящих запросов плюс обратный прокси для входящих. Типовая схема самостоятельно размещённого экземпляра.
| Вариант | Когда выбирать | Ограничение |
|---|---|---|
| Переменные окружения | Весь исходящий трафик через один прокси | Требует перезапуска, недоступно в облаке |
| Параметры узла HTTP Request | Выборочное проксирование | Настройка для каждого узла |
| Обратный прокси | Публикация редактора и вебхуков | Не влияет на исходящие запросы |
| Комбинация | Самостоятельное размещение с внешними API | Больше точек настройки |
Отдельно стоит вопрос ротации адресов. В обзоре на proxymonkey.io разбирается выбор между ротирующими резидентными адресами и статическим IP для рабочих процессов n8n: ротация уместна при массовых однотипных запросах, статический адрес — когда внешний сервис привязывает доступ к конкретному IP.
Типичные проблемы и диагностика
Ошибка 407 Proxy Authentication Required. Прокси требует аутентификации, а учётные данные не переданы или переданы неверно. Проверьте формат адреса с логином и паролем и корректность самих данных.
Ошибка ECONNRESET. Соединение сброшено. Проверьте доступность прокси-сервера с машины, где работает n8n, и его способность пропускать нужный протокол.
Таймауты. Запрос не получает ответа за отведённое время. Проверьте, что прокси отвечает на тестовый запрос, и что целевой хост доступен через него.
Переменная задана, но не работает. Первое, что проверяют, — регистр. Документация проекта указывает приоритет строчных версий над прописными. Второе — место задания переменной: она должна быть в окружении самого процесса n8n, из которой вы запускаете команды.
Вебхуки содержат неверный адрес. Признак работы за обратным прокси без N8N_WEBHOOK_URL. Документация проекта описывает эту ситуацию прямо: n8n собирает адрес из протокола, хоста и порта, и за прокси такой адрес оказывается нерабочим.
Ошибка про заголовок X-Forwarded-For. Зафиксируйте полный текст ошибки и проверьте N8N_PROXY_HOPS вместе с заголовками X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto на последнем прокси. Документация требует согласованной настройки этих параметров при работе за обратным прокси.
Запрос к внутреннему сервису уходит через прокси. Хост не попал в NO_PROXY. Проверьте список и разделители.
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| 407 | Нет данных аутентификации | Логин и пароль в адресе прокси |
| ECONNRESET | Прокси недоступен или блокирует | Доступность и правила прокси |
| Таймаут | Медленный или недоступный маршрут | Тестовый запрос через прокси |
| Переменная игнорируется | Регистр или место задания | Строчная версия, окружение процесса |
| Неверный адрес вебхука | Нет N8N_WEBHOOK_URL | Значение переменной |
| Внутренний хост через прокси | Нет записи в NO_PROXY | Список хостов и запятые |
Порядок диагностики: сначала проверьте доступность прокси-сервера с машины n8n, затем — подхватилась ли переменная, затем — проходит ли тестовый запрос, и только после этого разбирайте ошибки конкретного узла.
Частые вопросы
Как задать прокси для одного узла в n8n?
Откройте узел HTTP Request и укажите параметры прокси в его настройках: адрес, порт и учётные данные. Такая настройка действует только для этого узла и не затрагивает остальные. Этот способ работает и в облачной версии, где переменные окружения недоступны. В обзоре на proxymonkey.io он описан как основной вариант для n8n Cloud.
Почему переменная окружения с прокси не работает?
Первая причина — регистр: документация проекта указывает, что строчные версии переменных имеют приоритет над прописными, когда заданы обе. Вторая — место задания: переменная должна быть в окружении процесса n8n. Третья — перезапуск: после изменения окружения процесс нужно перезапустить. Проверьте эти три пункта по порядку.
Как сделать, чтобы глобальный прокси не ломал вебхуки?
Исходящие HTTP_PROXY и HTTPS_PROXY и входящий обратный прокси настраиваются отдельно. Если n8n работает за обратным прокси, задайте публичный N8N_WEBHOOK_URL, настройте N8N_PROXY_HOPS по документации и передачу X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto на последнем прокси. Для описанной в руководстве схемы N8N_PROXY_HOPS равен 1.
Нужен ли ротирующий прокси для n8n?
Зависит от задачи. Ротация адресов уместна при массовых однотипных запросах к внешним сервисам. Статический адрес нужен, когда сервис привязывает доступ к конкретному IP. В обзоре на proxymonkey.io этот выбор разобран отдельно для рабочих процессов n8n. Для обычной интеграции с API ротация не требуется.
Как проверить, что прокси действительно используется?
Сопоставьте тестовый запрос с записью о нём в журнале прокси. При отдельном тесте HTTP_PROXY проверяет HTTP, а HTTPS_PROXY — HTTPS. Учитывайте строчные переменные, исключения NO_PROXY и собственный параметр Proxy узла, прежде чем делать вывод о применении глобального окружения.