Прокси в Postman для тестирования API

Postman — стандарт для ручного и автоматизированного тестирования REST и GraphQL API. Прокси нужен, когда backend ограничивает доступ по IP, когда тестируете гео-зависимые эндпоинты или когда запросы должны идти через тот же канал, что и продакшен-парсер. NEONPROXY выдаёт строку host:port:login:password — покажем, куда её вставить в Postman Desktop и CLI Newman.

Глобальный прокси в Postman

Settings (шестерёнка) → Proxy → включите «Use custom proxy configuration». Для HTTPS-прокси NEONPROXY:

Отключите «System proxy», если Postman подхватывает корпоративный прокси Windows и мешает тестам. Отправьте GET на https://api.ipify.org?format=json — в ответе должен быть IP NEONPROXY.

Канал SVYAZVPN Открыть бота

SOCKS5 в Postman

Postman поддерживает SOCKS5 с версии 8+. Выберите тип SOCKS5, укажите host:1080 и те же credentials. Удобно, когда целевой SDK в продакшене использует SOCKS — поведение ближе к бою. Сравнение протоколов — SOCKS5 vs HTTPS.

Переменные окружения

Храните прокси-параметры в Environment, чтобы не светить их в коллекции:

Для CI экспортируйте коллекцию и запускайте Newman с флагами прокси — пароли передавайте через секреты пайплайна, не коммитьте в Git.

Newman в CI/CD

Перед nightly-прогоном проверьте пул в прокси-чекере: мёртвый IP даст ложные падения тестов.

Отладка типичных проблем

Error: connect ECONNREFUSED — неверный port или прокси offline. 407 — ошибка auth, сверьте login/password с кабинетом. SSL errors — целевой API за MITM; для dev можно временно отключить проверку сертификата в Postman Settings → SSL.

Postman Console (View → Show Postman Console) показывает реальный URL и заголовки — убедитесь, что X-Forwarded-For не подставляет домашний IP. Для скриптов на Python/Node см. requests и Axios.

Мониторы и scheduled runs

Postman Monitors выполняются с облачных IP Postman, а не с вашего NEONPROXY — для проверки whitelist API используйте Newman на своём CI-агенте с флагами прокси. Расписание cron + GitHub Actions + secrets PROXY_URL — типичный паттерн для geo-dependent health checks.

Коллекции с разным гео

Создайте отдельные Environment «DE», «US», «NL» с разными host из пула NEONPROXY. Переключайте окружение перед прогоном — так QA воспроизводит поведение пользователей в разных регионах без смены кода. Документируйте соответствие «окружение → страна» в README коллекции.

GraphQL и WebSocket

HTTP-прокси Postman поддерживает для обычных REST и GraphQL over HTTP. WebSocket через прокси в Postman ограничен — для WS-тестов используйте wscat или клиент на Go/Python с явным Transport. Подробнее про протоколы — SOCKS5 vs HTTPS.

Перед нагрузочным тестом API не гоните тысячи запросов через один IP — см. concurrent запросы и ротацию в отдельной статье.

Pre-request Scripts и динамические заголовки

В Pre-request Script можно подставлять timestamp и подписи API, но не менять глобальный прокси — Postman не поддерживает per-request proxy override в UI. Обход: несколько Workspace с разными глобальными прокси или Newman с разными env-файлами в параллельных job'ах CI.

Для OAuth2 flow сохраняйте токены в Environment, а прокси держите постоянным на всём цикле authorization code → token → API calls — смена IP между шагами часто ломает session binding у провайдеров.

Экспортируйте коллекции без hardcoded secrets: proxy user/pass только в Environment и CI secrets. Для нагрузочного QA смотрите load testing через прокси — Postman alone не заменит k6/JMeter, но отлично подходит для контрактных smoke-тестов через NEONPROXY.

Итог: глобальный прокси в Postman Settings + Environment с host:port:login:password покрывает 90% QA-сценариев. Newman доводит то же до CI с теми же credentials из secrets.

После настройки отправьте тестовый запрос к /tools/myip/ через Postman — убедитесь, что egress совпадает с ожидаемым гео тарифа.