Прокси в n8n: узел HTTP Request, глобальные переменные и сценарий парсинга

В n8n прокси подключается в двух местах: в параметре Proxy отдельного узла HTTP Request или через переменные окружения HTTP_PROXY / HTTPS_PROXY на своём сервере — тогда их по умолчанию используют все узлы. Если заданы оба варианта, приоритет у настройки узла, так что можно держать один общий выход и переопределять его только для запросов, которым нужен другой IP.

Обзоры n8n обычно перечисляют сценарии и на этом заканчиваются. Здесь — практика: где именно находится поле прокси и в каком формате его заполнять, как ведут себя глобальные переменные в Docker и как собрать небольшой сценарий парсинга с паузами, повторами и ротацией IP, который не падает на первой же заблокированной странице.

Когда сценарию n8n нужен прокси

Большинству интеграций с API (CRM, мессенджеры, таблицы) прокси не нужен: официальные API узнают вас по токену, а не по IP. Прокси оправдан, если сценарий:

• по расписанию собирает публичные веб-страницы (цены, объявления, вакансии, новости) и упирается в лимиты на один IP;
• должен видеть страницы так, как их видит посетитель из конкретной страны или города, — например, поисковую выдачу или региональный каталог;
• работает в корпоративной сети, где исходящий трафик обязан проходить через прокси компании;
• обращается к сервису с доступом только для разрешённых IP, а адрес вашего сервера n8n меняется.

Если сценарий обращается к чужим сайтам, сверяйтесь с их правилами и robots.txt, собирайте только общедоступные данные и не превышайте разумную частоту запросов. Прокси распределяет нагрузку, но не делает агрессивный обход допустимым. Общие правила описаны в обзоре веб-скрапинга, а типы выходов сравниваются в статье о выборе прокси для парсинга.

Вариант 1. Прокси в узле HTTP Request

Шаг 1. Откройте параметры узла

Добавьте узел HTTP Request, укажите метод и URL, затем прокрутите до блока Options и нажмите Add Option. В списке есть Batching, Ignore SSL Issues, Lowercase Headers, Redirects, Response, Pagination, Proxy и Timeout.

Шаг 2. Введите адрес прокси

Выберите Proxy и вставьте адрес целиком: схема, при необходимости логин и пароль, хост и порт, например http://user-7f3k:s3cret@203.0.113.15:8000. В документации n8n это поле описано как HTTP-прокси, поэтому берите у провайдера HTTP-подключение; поддержка SOCKS5 для этого параметра не описана. Если в пароле есть символы вроде @ или :, закодируйте их для URL.

Шаг 3. Задайте таймаут

В том же списке Options добавьте Timeout (в миллисекундах). Прокси добавляет задержку, и разумный предел в 20–30 секунд не даст одному медленному запросу подвесить весь запуск.

Шаг 4. Включите повторы

Откройте вкладку Settings узла, включите Retry On Fail и задайте Max Tries и Wait Between Tries. С ротируемым пулом каждая повторная попытка часто уходит уже с нового IP, и большая часть разовых блокировок снимается сама.

Вариант 2. Общий прокси для своего сервера n8n

n8n читает стандартные переменные окружения: HTTP_PROXY — для обычных HTTP-запросов, HTTPS_PROXY — для трафика по TLS, ALL_PROXY — запасной вариант и NO_PROXY — список хостов, к которым нужно обращаться напрямую. По документации n8n использует пакет proxy-from-env, в котором имена в нижнем регистре имеют приоритет над заглавными, если заданы оба. Фрагмент Docker Compose может выглядеть так:

services:
  automation:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - HTTPS_PROXY=http://user-7f3k:s3cret@203.0.113.15:8000
      - HTTP_PROXY=http://user-7f3k:s3cret@203.0.113.15:8000
      - NO_PROXY=localhost,127.0.0.1,postgres,api.internal.example

Две оговорки. Во-первых, внесите в NO_PROXY все внутренние хосты (база данных, Redis, собственные API), иначе n8n попробует ходить к ним через прокси и получит ошибку. Во-вторых, общий выход направляет через прокси все интеграции, в том числе те, где важен постоянный IP сервера, поэтому многие команды предпочитают настройку на уровне узла. В n8n Cloud переменные окружения недоступны, и остаётся только параметр узла.

Сценарий парсинга по узлам

Ниже — компактный конвейер для мониторинга цен. Адреса и селекторы замените на свои.

Список адресов

Узел Code, который возвращает по одному элементу на страницу, упрощает остальную часть сценария:

const pages = [
  'https://shop.example.com/item/1001',
  'https://shop.example.com/item/1002',
  'https://shop.example.com/item/1003',
];
return pages.map(link => ({ json: { link } }));

В узле HTTP Request укажите в поле URL выражение {{ $json.link }}.

Извлечение данных

В узле HTML выберите операцию Extract HTML Content, укажите поле с телом ответа и добавьте значения для извлечения: имя ключа, CSS-селектор и что возвращать (текст, HTML или атрибут). Если цены на странице подставляет JavaScript, поля останутся пустыми — для таких сайтов нужен сервис с headless-браузером или собственный источник данных сайта.

Темп запросов

Используйте параметр Batching в HTTP Request (Items per Batch и Batch Interval в миллисекундах) или узел Wait внутри цикла. Распределение запросов во времени важнее количества IP — почему, объясняет статья о том, как снизить риск блокировки при парсинге.

Ротация IP в n8n

Рабочих схем две.

Ротирующий шлюз. Провайдеры ротируемых прокси выдают один хост и порт, за которыми IP выхода меняется на каждый запрос или на каждую сессию. В Proxy вставляется один адрес, а ротация происходит на стороне провайдера. Для многошаговых цепочек (открыть страницу, затем следующую) включайте «липкую» сессию, чтобы соседние запросы шли с одного адреса.

Собственный список. Если у вас несколько статических адресов, добавьте их к элементам в узле Code и сошлитесь на поле в параметре Proxy через выражение:

const exits = [
  'http://user-7f3k:s3cret@203.0.113.15:8000',
  'http://user-7f3k:s3cret@203.0.113.16:8000',
];
return $input.all().map((entry, n) => ({
  json: { ...entry.json, exitUrl: exits[n % exits.length] },
}));

Затем укажите в Proxy {{ $json.exitUrl }}. Проверьте, что в вашей версии n8n параметр Proxy принимает выражения; если нет, разделите сценарий на ветки с фиксированным прокси в каждой. Подробнее о логике смены адресов — в материале о ротации IP.

Проверка прокси

Прежде чем запускать сценарий на реальном сайте, выполните узел HTTP Request один раз с включённым прокси на сервисе, который возвращает IP, например https://httpbin.org/ip. В ответе должен быть адрес прокси. С ротирующим шлюзом запустите узел дважды: IP должен смениться, если вы не включали «липкую» сессию.

Частые ошибки

407 Proxy Authentication Required. Неверные логин или пароль либо незакодированные спецсимволы в пароле. Введите данные заново или закодируйте пароль.

ECONNREFUSED или таймаут на каждом запросе. Ошибка в хосте или порте либо в HTTP-параметр указан порт, работающий только по SOCKS5. Запросите у провайдера HTTP-подключение.

После HTTPS_PROXY перестали работать внутренние узлы. Добавьте хосты базы данных, кэша и внутренних API в NO_PROXY.

403 или страница с капчей вместо HTML. Сайт реагирует на характер запросов, а не только на IP. Снизьте частоту, передавайте реалистичные заголовки и попробуйте резидентские прокси вместо дата-центровых.

Пустой результат извлечения. Данные рисует JavaScript или селектор изменился. Сначала посмотрите сырой ответ.