Нагрузочное тестирование через прокси
Load test с одного IP показывает, как CDN и WAF ведут себя для одного «суперпользователя», а не для реальной аудитории. Маркетинг запускает кампанию в пяти странах — пик приходит с разных ASN и rate-limit buckets. Прокси в нагрузочном тестировании распределяют запросы по множеству egress-адресов и позволяют моделировать региональный трафик без флота VM в каждом датацентре.
Задачи, где прокси уместны
Обход per-IP rate limit на staging — API gateway режет 100 RPS с одного адреса; сто прокси дают иллюзию ста клиентов. Geo-distributed load — проверка, что Tokyo POP выдерживает локальный flash sale. CDN cache warming — параллельные GET с разных IP прогревают edge nodes. Anti-DDoS tuning — security team валидирует пороги challenge, не атакуя production с одного botnet-like IP.
Тестируйте только системы, на которые у вас есть письменное разрешение. NEONPROXY не поощряет нагрузку на чужие production без consent.
Инструменты: k6, Locust, JMeter
k6 — HTTP_PROXY env или custom http batch with proxy URL per VU iteration. Для rotation используйте shared array proxy list из API NEONPROXY. Locust — HttpUser с proxies dict на клиенте; каждый greenlet может брать следующий IP из queue. JMeter — HTTP Request Defaults + CSV Data Set Config с host:port:user:pass.
SOCKS5 поддерживается через plugin или wrapper; для pure HTTP load HTTPS-прокси проще. Сравнение протоколов — SOCKS5 vs HTTPS.
Архитектура теста
Controller (k6 cloud или self-hosted) → N workers → each worker cycles M proxies → target staging URL. Metrics: p95 latency, error rate by status code, saturation proxy pool (timeouts). Separate metric «blocked by WAF» — 403 spike при одном ASN сигналит, что все IP из одной подсети NEONPROXY попали в rule; разнесите по разным заказам или снизьте RPS.
Warm-up phase без proxy помогает baseline; ramp with proxy на 20% traffic, затем 100%. Cool-down обязателен — не обрывайте резко, чтобы не оставить half-open connections.
Лимиты датацентровых прокси
DC IP не бесконечны по bandwidth: 100 Mbps на канал типично. Тысяча VU через один proxy — bottleneck на прокси, не на target. Rule of thumb: не более 50–100 concurrent connections на приватный IPv4. IPv6 pool масштабируется дешевле для high connection count — см. IPv6 vs IPv4.
Latency добавляется: +20–80 ms hop. Для latency-sensitive SLA тестируйте subset без proxy и full scale with proxy отдельными сценариями.
Geo и User-Agent
Load test «из Бразилии» — BR proxy + pt-BR Accept-Language. Иначе CDN отдаст другой shard. Комбинируйте с ротацией UA — отдельный материал. Не используйте один desktop Chrome UA на 10 000 VU — WAF детектит bot pattern.
Мониторинг во время теста
Target side: CPU, DB connections, queue depth. Proxy side: error rate connect timeout. Client side: k6 checks. Preflight каждого IP в чекере — dead proxy skew results.
Alert если success rate < 99% sustained 2 min — abort test, не «дожимайте» production staging.
Типичные ошибки
Load test production без окна maintenance. Все VU через один shared proxy — invalid results. Игнор TLS handshake cost при short requests. No coordination with CDN vendor — they may blackhole ASN. Confusing load test with scraper — different ethics and limits.
Забытый DNS leak на worker — часть трафика мимо прокси, geo test invalid.
Чеклист перед запуском
Written approval от owner системы. Staging или isolated prod slice. Proxy pool sized to target RPS. Realistic think time in script. Geo matrix documented. Rollback plan. Post-test report with p95/p99 and error breakdown.
NEONPROXY API выдаёт список endpoints для автоматического наполнения pool — см. документацию. Начните с малого пула на pilot 500 RPS, масштабируйте после стабильных метрик.
После теста сохраните Grafana dashboard snapshot и список заблокированных IP — это входные данные для следующей итерации: возможно, WAF rule слишком агрессивен к одному ASN, и security team скорректирует whitelist для вашего load-gen контура.