Выход через прокси не переносит ваш движок JMeter

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

office engine → regional proxy → website

Это полезно для проверки поведения, выбираемого видимым исходным IP. Измеряется путь, включающий участок от офиса до прокси, участок от прокси до сайта и собственную обработку прокси. Это не тот же путь, что у клиента, запущенного рядом с региональным прокси.

Параметры HTTP-прокси в JMeter позволяют выбрать этот посредник. Сохраняйте выбранный endpoint вместе с результатами теста и убедитесь, что используемые сэмплеры действительно применяют нужную настройку. Для разрешённой проверки публичного сайта без учётных данных прокси список HTTP-прокси предлагает HTTP-кандидатов; проверьте наблюдаемый выход, прежде чем интерпретировать региональный результат.

Размещайте движок там, где начинается измерение

Если вопрос касается нагрузки, создаваемой из другого сетевого расположения, используйте движки в нужных местах через поддерживаемую удалённую схему JMeter или независимо управляемые запуски CLI. Расположение контроллера не заменяет сетевые точки старта движков.

Планируйте нагрузку явно. Удалённые движки JMeter выполняют весь тестовый план; контроллер не распределяет одно число потоков между ними автоматически. Несколько движков с одним планом могут создать большую суммарную нагрузку, чем ожидает читатель.

Выбирайте схему исходя из вопроса: видимый выходной IP, региональный сетевой путь пользователя или суммарная нагрузка приложения. Фиксируйте этот выбор, чтобы результат, ограниченный прокси, не выдавался за самостоятельную ёмкость сайта.