Задержка прокси: как выбрать быстрый канал
Latency прокси — сумма задержек на пути «ваш сервер → gateway NEONPROXY → целевой сайт → обратно». Лишние 200 ms на запрос при миллионе URL добавляют 55 часов wall time. Для SMM и браузинга высокая задержка ощущается как «тормозной интернет». Разберём, как измерить, сравнить и выбрать быстрый канал без смены провайдера.
Из чего складывается latency
Физика. Сигнал не быстрее скорости света в кабеле: Москва — Франкфурт ~30–40 ms RTT в идеале, Москва — США ~120–150 ms. Маршрут BGP. Плохой peering добавляет hops и jitter. Нагрузка gateway. Перегруженный узел прокси увеличивает queueing delay. TLS. Полный handshake +1 RTT; session resumption экономит время. DNS. Резолв через медленный resolver перед каждым запросом — скрытый налог.
Как измерять правильно
Ping до IP прокси показывает только до gateway, не до целевого сайта через tunnel. Корректный benchmark — HTTP request через прокси к реальному endpoint:
curl -o /dev/null -s -w '%{time_total}\n' -x http://user:pass@host:port https://целевой-домен.com/
Замеряйте p50, p95, p99 на 20–50 запросах, не один lucky shot. Прокси-чекер NEONPROXY даёт базовый ping и время отклика — стартовая точка перед боевым тестом.
Выбор геолокации
Правило: прокси ближе к целевому серверу или к вашему воркеру — что длиннее плечо в вашей схеме. Crawler на VPS во Frankfurt + сайт в EU → DE/NL прокси. Crawler в Moscow + US-only API → US прокси, даже если ваш сервер в RU.
NEONPROXY предлагает 24 гео-зоны — не берите US proxy для задачи «немецкий маркетплейс» только потому что US дешевле: latency и антифрод пострадают. Гайд по выбору — как выбрать прокси.
Приемлемые цифры по задачам
Массовый парсинг HTML: p95 < 2 s на страницу (с учётом TTFB цели). Real-time API polling: p95 < 500 ms. Браузер SMM: subjective «как домашний LTE» — RTT < 100 ms до CDN соцсети желателен. Sticky session login: важна стабильность jitter, не только среднее — скачки 50→800 ms ломают UX.
Фильтрация медленных адресов в пуле
При покупке пула IPv6 часть адресов может быть на разных uplink. Health check при старте: blacklist proxy с p95 > threshold. Weighted routing — больше запросов на быстрые IP. Периодический re-check раз в сутки — маршруты меняются.
Не выбрасывайте прокси из-за одного timeout — transient glitch. Три timeout подряд — cooldown 15 min.
Оптимизация на клиенте
HTTP keep-alive и connection pooling — один TCP к прокси на десятки запросов. DNS cache (ttl respect) на воркере. Близкий resolver (1.1.1.1 vs локальный ISP). Параллелизм без overshoot — см. parallel requests.
SOCKS5 vs HTTPS: разница latency обычно < 5 ms на datacenter proxy — выбирайте по совместимости, не по ping. SOCKS5 vs HTTPS.
Latency vs bandwidth
Высокий bandwidth не спасает высокий latency для small requests — TCP slow start на каждом новом connection. Keep-alive критичен. Для large downloads bandwidth важнее RTT.
Трафик и переплаты — отдельная тема: bandwidth и тарифы.
Когда latency некритична
Offline batch ETL ночью. Queue-based crawl с SLA «готово к утру». Задачи с dominant processing time (heavy parsing CPU) — proxy RTT < 5% total.
Диагностика проблем
Вдруг вырос latency на всех прокси — проблема у вас (DNS, ISP) или у цели (CDN incident). Только на одном IP — bad route, замена через API. Только HTTPS, SOCKS ok — bug в HTTP CONNECT client.
Traceroute через прокси сложен; сравните direct vs proxy time_total к одному URL — delta = proxy tax.
Чеклист выбора быстрого канала
1) Определите geo цели и воркера. 2) Закажите 2–3 geo из 24 зон NEONPROXY. 3) Benchmark p95 к реальному URL. 4) Выберите победителя. 5) Keep-alive + DNS cache. 6) Health check в пуле. 7) Мониторинг p95 daily.
Быстрый прокси — это правильное geo и здоровый маршрут, а не магический «turbo» тариф.