Прокси для нагрузочного тестирования в k6 и JMeter

Когда нагрузочный тест упирается в rate-limit, WAF или географическую балансировку, первая мысль — «запущу трафик с разных IP». Звучит логично, но на практике прокси в k6 и JMeter решают узкий набор задач, а остальное всё равно приходится чинить архитектурой теста. В этой статье разберём, как технически подключить прокси к обоим инструментам, какие типы IP для этого подходят и где заканчивается зона ответственности прокси-сервера.

Зачем нагрузочному тесту разные IP

По умолчанию k6 и JMeter отправляют весь трафик с одного IP-адреса — сервера, на котором запущен тест (или облачной машины в CI/CD). Это нормально для 90% сценариев, но в нескольких случаях одного IP недостаточно:

Rate-limiting на уровне IP. Многие API и балансировщики (nginx limit_req, AWS WAF, Cloudflare) ограничивают число запросов с одного адреса в секунду. Реальные пользователи приходят с тысяч разных IP, а ваш тест с одного — и упирается в лимит раньше, чем в реальный бутылочное горлышко приложения.
Тестирование гео-зависимой логики. CDN, таргетированный контент, региональные цены, geo-блокировки — всё это нужно проверять с IP из конкретных стран, а не из дата-центра, где физически стоит ваш тестовый раннер.
Проверка балансировщика и anycast-сети. Если инфраструктура распределяет трафик по регионам на основе IP клиента, тест с одного адреса проверит только один маршрут, а не всю сеть.
Имитация реального распределения трафика. У продакшен-трафика IP распределены по провайдерам, подсетям, иногда по мобильным операторам — это влияет на поведение CDN, кэшей и edge-логики.

Важно сразу разграничить: если вы тестируете производительность бэкенда (сколько RPS выдержит ваш API), прокси почти никогда не нужны — там важна чистая нагрузка, а не разнообразие источников. Прокси нужны, когда тестовый сценарий зависит именно от IP-адреса клиента.

Какие прокси подходят: datacenter, residential, mobile

Выбор типа прокси напрямую влияет на то, что именно вы тестируете — пропускную способность инфраструктуры или поведение системы под «живыми» IP.

Тип прокси	Задержка и скорость	Когда использовать в нагрузочных тестах
Прокси дата-центров	Низкая задержка, высокая пропускная способность	Проверка rate-limit, обход лимита «N запросов с IP», генерация большого объёма RPS с разных подсетей
Резидентные прокси	Задержка выше, скорость ограничена каналом реального пользователя	Тест гео-логики, проверка CDN и anti-bot систем, которые доверяют residential-диапазонам больше, чем datacenter
Мобильные прокси	Самая высокая задержка, нестабильная скорость	Нишевые сценарии: тест мобильного API, поведение при частой смене IP (операторы меняют адрес клиента динамически)

Для чистой проверки RPS и rate-limit почти всегда достаточно прокси дата-центров — они дают стабильную низкую задержку и не искажают результаты теста посторонней сетевой нестабильностью. Резидентные и мобильные IP добавляют реалистичности в гео-тестах, но вносят собственную задержку, которую придётся учитывать при анализе метрик — иначе легко перепутать «тормозит сеть прокси» с «тормозит ваш сервер».

Настройка прокси в k6

k6 — это инструмент на JavaScript (движок написан на Go, скрипты пишутся на JS), и по умолчанию встроенной поддержки HTTP-прокси через опции скрипта нет: прокси в k6 задаётся через переменные окружения или системные настройки, потому что под капотом k6 использует Go HTTP-клиент.

Самый простой способ — переменные окружения:

export HTTP_PROXY="http://login:password@proxy-host:port"
export HTTPS_PROXY="http://login:password@proxy-host:port"

k6 run script.js

Этот способ направит весь трафик теста через один прокси — подходит, если вам нужно просто уйти с «белого» IP сервера. Но если задача — распределить виртуальных пользователей (VU) по разным IP, нужен список прокси и логика выбора на уровне скрипта. Напрямую k6 не поддерживает per-VU прокси «из коробки», поэтому распространённый обходной путь — запускать несколько процессов k6 параллельно, каждый со своей переменной окружения и своим прокси из пула:

// run-with-proxies.sh
PROXIES=("proxy1:port" "proxy2:port" "proxy3:port")

for proxy in "${PROXIES[@]}"; do
  HTTP_PROXY="http://user:pass@$proxy" \
  HTTPS_PROXY="http://user:pass@$proxy" \
  k6 run --vus 50 --duration 5m script.js &
done
wait

Такой подход хорошо масштабируется в связке с k6 Cloud или оркестрацией через Kubernetes/Docker Compose — каждый контейнер поднимается с собственной прокси-переменной. Если нужна ротация IP внутри одного запуска скрипта, логичнее брать прокси с ротацией на стороне самого прокси-провайдера (sticky session с TTL), а не городить ротацию внутри JS-кода.

Настройка прокси в JMeter

В JMeter прокси настраивается нативно, без переменных окружения, через элемент HTTP Request Defaults или прямо в настройках HTTP Request Sampler:

Добавьте элемент конфигурации HTTP Request Defaults в Thread Group.
В полях Proxy Server укажите хост и порт прокси.
Если прокси требует авторизации — добавьте элемент HTTP Authorization Manager с логином и паролем для этого хоста.
Все HTTP Request Samplers внутри Thread Group автоматически унаследуют настройки прокси.

Для распределения нагрузки по нескольким прокси в JMeter удобно использовать CSV Data Set Config — файл со списком прокси подставляется в переменные хоста и порта для каждого потока:

proxy_host,proxy_port,proxy_user,proxy_pass
proxy1.example.com,8000,user1,pass1
proxy2.example.com,8000,user2,pass2
proxy3.example.com,8000,user3,pass3

Подключите CSV Data Set Config к Thread Group, укажите переменные ${proxy_host} и ${proxy_port} в полях Proxy Server/Proxy Port сэмплера — каждый поток JMeter возьмёт свою строку из файла и пойдёт через свой IP. Для запуска через командную строку (headless-режим, что рекомендуется для реальных нагрузочных прогонов) прокси также можно передать флагами:

jmeter -n -t test_plan.jmx -l results.jtl \
  -H proxy-host -P port \
  -u username -a password

Этот способ задаёт один общий прокси для всего теста — для многопроксийных сценариев всё равно придётся использовать CSV Data Set Config или Distributed Testing (несколько JMeter-слейвов, каждый со своим прокси в конфиге).

Ротация IP и распределение нагрузки

Есть два принципиально разных подхода к распределению IP в нагрузочном тесте:

Статичное закрепление IP за потоком/VU. Каждый виртуальный пользователь получает один и тот же IP на всю сессию — имитирует реального пользователя с одним адресом. Настраивается через sticky-session прокси или просто фиксированный список в CSV/переменных окружения.
Ротация IP на каждый запрос. Прокси меняет исходящий адрес на каждый HTTP-запрос — полезно для проверки защиты от rate-limit, но слабо отражает реальное поведение пользователей, у которых IP не меняется каждую секунду.

Для реалистичного нагрузочного теста в 90% случаев правильнее закреплять IP за VU/потоком на всю сессию — так тест честно отражает поведение множества независимых пользователей, а не создаёт искусственный шум. Ротацию на каждый запрос имеет смысл включать только в узких сценариях — например, при целевой проверке срабатывания rate-limit правила.

Чего прокси точно не заменят

Здесь ключевой момент статьи: прокси решают проблему «с какого IP приходит запрос», но не решают проблемы, которые на самом деле проверяет нагрузочное тестирование.

Пропускную способность вашего тестового раннера. Если генератор нагрузки (сама машина с k6/JMeter) упирается в CPU, память или сетевую карту — прокси это не исправят. Прокси добавляют лишний сетевой хоп и свою задержку, а не снимают нагрузку с раннера.
Реальную пропускную способность тестируемого сервера. Сервер либо выдерживает нагрузку, либо нет — IP-адрес клиента на это не влияет, кроме случаев явного rate-limit по IP.
Достоверность метрик времени отклика. Прокси добавляют собственную задержку (особенно residential и mobile), которая попадёт в ваши отчёты как часть времени ответа. Если не вычесть задержку прокси отдельно, итоговый latency-отчёт будет искажён и непригоден для сравнения с продакшен-метриками.
Масштабирование инфраструктуры под реальный трафик. Нагрузочный тест с прокси показывает поведение под определённым паттерном запросов, но не заменяет capacity planning, автоскейлинг и нагрузочные профили, построенные на реальных продакшен-логах.
Проверку корректности бизнес-логики под нагрузкой. Race conditions, блокировки в БД, деградация очередей — это находится тестами на конкурентность и профилированием, а не сменой исходящего IP.

Прокси — это инструмент для частной задачи «эмулировать трафик с разных IP», а не универсальный усилитель нагрузочного теста. Если цель — понять, сколько RPS выдержит бэкенд, прокси в большинстве случаев вообще не нужны: достаточно нескольких тестовых раннеров без прокси, с правильно настроенным keep-alive и пулом соединений.

Типичные ошибки при тестировании через прокси

На практике большинство проблем с прокси в нагрузочных тестах сводится к нескольким повторяющимся ошибкам.

Смешивание задержки прокси с задержкой тестируемого сервиса. Без baseline-замера (прямой запрос без прокси) невозможно понять, сколько миллисекунд добавляет сам прокси-сервер.
Использование мобильных или residential прокси там, где нужна чистая пропускная способность. Такие прокси ограничены реальным каналом конечного устройства и физически не выдержат десятки тысяч RPS — для чистой нагрузки нужны прокси дата-центров.
Недостаточный пул IP для большого числа VU. Если на 5000 виртуальных пользователей приходится 10 прокси-адресов, тест всё равно упрётся в тот же rate-limit, просто с задержкой — сервис быстро увидит паттерн «10 IP, тысячи запросов».
Игнорирование таймаутов на стороне прокси. При высокой конкурентной нагрузке прокси-сервер может сам начать отклонять соединения — важно заранее уточнить лимиты одновременных сессий у провайдера прокси.
Запуск теста без проверки whitelisting/авторизации. Если прокси требует авторизацию по IP, а тест запускается из CI/CD с динамическим адресом раннера — запросы будут падать с 407 Proxy Authentication Required, и результаты теста окажутся бессмысленными.

Чек-лист перед запуском теста

Определили, действительно ли задача требует разных IP, или достаточно теста с одного адреса.
Выбрали тип прокси под задачу: дата-центр для RPS и rate-limit, residential/mobile для гео-логики.
Сделали baseline-замер без прокси, чтобы отделить задержку сети от задержки прокси.
Проверили лимиты одновременных соединений у прокси-провайдера под нужный уровень VU.
Настроили авторизацию прокси (логин/пароль или whitelisting IP раннера).
Решили, нужна ли sticky-сессия на VU или ротация на каждый запрос.
Запустили тест на коротком интервале (1-2 минуты) перед полным прогоном, чтобы проверить конфигурацию.

Заключение

Прокси в k6 и JMeter — рабочий способ эмулировать трафик с разных IP-адресов, проверить поведение rate-limit и гео-зависимой логики. Но это не замена грамотному планированию нагрузочного теста: пропускную способность сервера, стабильность бэкенда под конкурентной нагрузкой и реальное capacity planning прокси не проверяют и не улучшают. Используйте их точечно — там, где тест действительно зависит от IP-адреса клиента, а не как универсальный инструмент «для честности».

Если задача — проверить лимиты по IP и сымитировать массовый трафик с высокой пропускной способностью, разумно начать с прокси дата-центров — они дают минимальную задержку и выдерживают большое число одновременных сессий. Для тестов, завязанных на гео-логику и доверие anti-bot систем к происхождению трафика, лучше подойдут резидентные прокси, а для нишевых сценариев с мобильным трафиком — мобильные IP.