Как провести нагрузочное тестирование API за брандмауэром

26 октября 2026 г.

Ваши функциональные тесты успешно проходят при каждой сборке. Затем вы запускаете нагрузочное тестирование на стейджинге и получаете стену из ошибок 403, потому что брандмауэр никогда раньше не видел IP-адрес генератора нагрузки.

Чтобы провести нагрузочное тестирование API за брандмауэром, ваша конечная точка должна быть видна генераторам нагрузки, которые создают ее с удаленного IP-адреса. Для этого желательно, чтобы такая нагрузка поступала из стандартного списка статических IP-адресов, которые можно внести в белый список. Таким образом, вы можете сначала проверить тест на машине, которой доверяете, а затем масштабировать его из источника из белого списка.

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

Почему нагрузочный тест оказывается за брандмауэром?

Представьте, что вы руководите командой, отвечающей за API оформления заказа. Вы хотите установить простое правило: при 500 одновременных пользователях задержка 90-го перцентиля (p90) остается ниже 500 мс, а количество ошибок остается ниже 1%. Если стейджинг не справляется с этим, сборка не попадает в продакшн.

Это означает, что ваш нагрузочный тест должен запускаться на вашей стейджинг-инфраструктуре, где сетевые требования наиболее жесткие. Здесь staging-api.example.com имеет публичный адрес, но его брандмауэр веб-приложений (WAF) пропускает только корпоративную сеть и шлюз трансляции сетевых адресов (NAT) раннеров непрерывной интеграции (CI). Все остальное получает 403.

Функциональные тесты проходят нормально, потому что они поступают от этих разрешенных CI-раннеров, таких как Private runner в Postman. Нагрузочный тест — это проблема: один CI-раннер не может воспроизвести 500 виртуальных пользователей, а облачный генератор нагрузки отправляет трафик с адресов, которые WAF никогда не видел.

Как команды обычно пропускают нагрузку через брандмауэр?

Существует четыре распространенных подхода. Каждый из них разумен в определенных ситуациях.

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

Как проводить нагрузочное тестирование API за брандмауэром шаг за шагом?

В остальной части этой статьи рассматривается такая настройка в Postman с использованием коллекции команды оформления заказа. Postman запускает тест производительности из той же коллекции, которую вы используете для функциональных тестов. Порядок запросов, скрипты перед запросом и после ответа, а также утверждения pm.test() выполняются под нагрузкой точно так же, как и при одиночном запуске.

1. Начните с уже имеющейся у вас коллекции

Коллекция выполняет вход в систему, добавляет товар в корзину и размещает заказ. Каждый запрос уже содержит свои утверждения:

Никакого отдельного скрипта нагрузки не требуется.

2. Проведите дымовое тестирование локально

Прежде чем тратить средства на облачные мощности, убедитесь, что сам тест надежен. В Collection Runner установите для параметра Run type значение Performance, а для Run method — App, затем запустите от 10 до 20 виртуальных пользователей на несколько минут. Аналогичная проверка из терминала выглядит следующим образом:

Следите за системными метриками во время работы. Если ваш CPU близок к пределу, видимая вами задержка частично обусловлена вашим ноутбуком. Цель здесь — выявить поврежденные переменные, падающие утверждения и очевидные медленные эндпоинты, а не измерять емкость. Подробнее о перенесении теста с ноутбука в облако читайте в статье Облачное тестирование производительности с Postman: от ноутбука до CI.

3. Добавьте статические IP-адреса Postman в белый список

Попросите вашу службу безопасности добавить статические IP-адреса Postman в правило WAF или группу безопасности, защищающую стейджинг. Адреса зависят от региона вашего аккаунта Postman: по умолчанию US или EU для планов с размещением данных в ЕС. Скопируйте текущий список для вашего региона из раздела со статическими IP в документации по тестам производительности, а не из этой публикации, так как список может изменяться.

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

4. Запустите в Postman Cloud со статических IP-адресов

Измените параметр Run method на Cloud. Установите 500 виртуальных пользователей, выберите профиль нагрузки Ramp up (плавное увеличение), чтобы API прогрелся перед пиком, и задайте длительность. В разделе Egress routing strategy выберите Static IPs. В поле Pass test if установите p90 менее 500.

Postman распределяет нагрузку между управляемыми воркерами, поэтому количество виртуальных пользователей не ограничено одной машиной. Метрики, ошибки и результаты проверок поступают в режиме реального времени во время выполнения теста. Если в первую минуту что-то явно идет не так, остановите тест, чтобы не платить за часы виртуальных пользователей (VU), которые вам не нужны. Готовый отчет сохраняется в рабочем пространстве, поэтому любой участник команды сможет открыть его позже.

5. Сделайте это барьером релиза в CI/CD

Как только облачный запуск пройдет успешно, поместите тот же тест в свой конвейер. Опция --runner postman-cloud-static-ip отправляет нагрузку со статических IP-адресов, а --pass-if устанавливает код выхода:

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

Как понять, что это работает?

Четыре проверки показывают, выполняет ли настройка свою задачу:

• Отсутствие ошибок брандмауэра. В представлении ошибок запуска не должно быть ошибок 403 или сбросов соединений от WAF. Если они есть, какой-то адрес отсутствует в белом списке или белый список охватывает адреса не того региона.
• Локальное окружение и облако совпадают при низкой нагрузке. Запустите 20 виртуальных пользователей локально и в облаке. Если локальный показатель p90 намного выше, а ваш процессор был загружен на максимум, ваши предыдущие локальные показатели измеряли возможности самого компьютера.
• Известная точка отказа. Увеличивайте количество виртуальных пользователей в нескольких облачных запусках и отмечайте, при каком значении уровень ошибок превышает 1%. Это число является вашей текущей пропускной способностью, и его нужно отстаивать при проверке.
• Тенденция, а не снимок. Сравнивайте p90 для разных релизов в истории запусков рабочей области. Барьер, который никогда не давал сбоев, может быть настроен слишком мягко.

Когда статические IP-адреса не подходят?

• Только для приватных хостов. Если у API нет публичного адреса, добавление в белый список не поможет. Вместо этого запустите Postman CLI внутри сети с помощью стандартного локального раннера, ресурсы которого ограничены этой машиной.
• Белый список — это не аутентификация. Белый список IP-адресов сужает круг лиц, имеющих доступ к конечной точке. Сохраните собственную аутентификацию API и передавайте учетные данные через коллекцию, используя общие секреты хранилища для облачных запусков.
• Регион фиксируется вашим аккаунтом. Облачные запуски отправляют трафик из региона вашего аккаунта: US по умолчанию или EU для планов с размещением данных в ЕС.
• Очень маленькие тесты. Для облачных запусков требуется не менее 10 виртуальных пользователей. Ниже этого порога локальный запуск проще.

Часто задаваемые вопросы

Какие планы Postman включают статические IP-адреса для облачных тестов производительности?

Статические IP-адреса для облачных тестов производительности доступны в платных планах Postman. Раньше они были доступны только в тарифе Enterprise. Облачные тесты производительности расходуют часы VU независимо от того, используют ли они статические IP-адреса, а страница цен Postman содержит актуальные тарифы.

Как запустить облачный тест производительности Postman со статических IP-адресов в CI/CD?

Используйте Postman CLI со средством запуска со статическим IP-адресом: postman performance run <collection-id> --runner postman-cloud-static-ip. Добавьте --pass-if с пороговым значением, например less_than(p90, 500). Команда ожидает завершения облачного запуска и завершается с ненулевым кодом при недостижении порогового значения, что приводит к сбою задания CI/CD.

Работают ли статические IP-адреса для API без публичного адреса?

Нет. Статические IP-адреса для облачных тестов производительности Postman работают для общедоступных конечных точек, которые фильтруют трафик по исходному IP-адресу. Если API доступен только в частной сети, запустите Postman CLI внутри этой сети с помощью локального средства запуска по умолчанию. Такой запуск создает нагрузку с машины, на которой он выполняется, и ограничен ее ресурсами.

Стоит ли проводить нагрузочное тестирование локально или в Postman Cloud?

Используйте оба варианта. Локальный запуск теста производительности Postman в приложении или CLI — это быстрый дымовой тест, который выявляет поврежденные переменные и падающие утверждения при 10–20 виртуальных пользователях. Облачный запуск распределяет сотни виртуальных пользователей по управляемым воркерам Postman, поэтому результаты не ограничиваются ЦП или сетью одной машины.

Следующий шаг

Статические IP-адреса для облачных тестов производительности доступны на платных тарифах Postman. Настройте свой первый запуск с помощью руководства по запуск облачного теста производительности со статических IP-адресов.