Скорость прокси — это не одно число: это задержка (время до первого байта), пропускная способность (скорость передачи байтов) и процент успешных запросов (как часто вы получаете работоспособный ответ вообще) — и каждый из этих показателей меняется в зависимости от часа, цели и исходящего IP. Одиночный тест в один момент времени почти ничего не говорит, поэтому маркетинговые цифры провайдеров и разовые обзоры так легко создавать и так сложно использовать. Это метод, который мы используем для наших собственных рейтингов: что измерять, как, как часто и как обобщать результаты, чтобы они имели смысл.

Четыре числа

МетрикаНа какой вопрос отвечаетКак получитьТипичное хорошее значение
Задержка (TTFB)Сколько ждет каждый запрос до начала передачи данныхcurl -w %{time_starttransfer} на небольшом ресурсеДатацентровые: +10–50 мс к прямому подключению; резидентные/мобильные: +80–300 мс
Пропускная способностьКак быстро передаются большие объемы данныхЗамерить время загрузки файла фиксированного размера (1–10 МБ)Датацентровые: почти линейная скорость; резидентные: 5–50 Мбит/с; мобильные: 5–30 Мбит/с
Процент успешных запросовКак часто запрос завершается реальным ответом 2xxПодсчет результатов множества запросов>98% на нейтральных целях; ниже на защищенных — это заслуга цели
АптаймКак часто прокси вообще доступенПериодическая проверка связи в течение нескольких дней>99.5% для датацентровых/ISP; ротируемые пулы маскируют отдельные сбои

Отчеты, в которых приводится одна цифра «скорости», обычно сообщают пропускную способность при большой загрузке с датацентрового прокси в тихий час — самая лестная комбинация из возможных.

Принципы перед командами

  1. Измеряйте разницу, а не абсолютное значение. Всегда выполняйте один и тот же запрос напрямую и через прокси друг за другом и сообщайте дельту. Иначе изменчивость вашего собственного соединения смешивается с прокси.
  2. Всегда одна и та же цель. Используйте небольшой, быстрый, стабильный endpoint без ограничения скорости — статический файл на крупном CDN или ваш собственный сервер. Никогда не тестируйте на сайте, который собираетесь парсить; его анти-бот ответ — это другое измерение.
  3. Много выборок, распределенных во времени. Минимум 20 запросов за прогон; прогоны в разное время суток и в течение недели. Прокси — это общая инфраструктура, и нагрузка следует за рабочими часами в регионе провайдера и исходящих IP.
  4. Сообщайте процентили, а не средние. Один 30-секундный таймаут уничтожает среднее. Медиана (p50) говорит о типичном опыте; p95 — об опыте в плохой день; оба важнее среднего.
  5. Прогревайтесь. Отбрасывайте первый запрос каждого прогона — установка DNS и TLS-сессии делает его медленнее остальных.
  6. Меняйте по одной переменной за раз. Сравнение датацентрового прокси провайдера A с резидентным провайдера B сравнивает типы, а не провайдеров.

Задержка с помощью curl

# напрямую
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# через прокси
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

Через прокси time_connect — это время до прокси; connect и TLS до цели происходят внутри туннеля и попадают в time_appconnect/time_starttransfer. Число для сравнения — ttfb: разница между прокси и прямым подключением — это добавленная прокси задержка. Зациклите:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

Пропускная способность

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

Используйте файл достаточно большого размера, чтобы установка соединения составляла малую долю (5–10 МБ), но достаточно малый, чтобы не сжигать посекундный трафик резидентных прокси при множестве прогонов. На ротируемых пулах пропускная способность зависит от соединения исходящего хоста; запустите достаточно выборок, чтобы увидеть распределение, и помните, что на тарифах с оплатой за гигабайт пропускная способность также определяет, как быстро вы тратите деньги.

Процент успешных запросов

Каждый запрос заканчивается одним из: 2xx с телом ожидаемого размера; 4xx/5xx от цели; ошибка прокси (407, отказ в соединении, таймаут); или страница вызова (CAPTCHA/промежуточная) со статусом 200 — последнее пропускают наивные счетчики, поэтому проверяйте тело, а не только код. В Python:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

Отделяйте ошибки прокси (407, ошибки соединения, таймауты до прокси) от ошибок цели (403, 429, вызовы). Первые — проблема провайдера; вторые — о репутации IP на этой цели и относятся к другому тесту — см. как анти-бот системы оценивают запросы.

Аптайм

Аптайм — это процент успешных запросов за календарное время. Запланируйте легкий пробник — команду задержки выше или просто CONNECT — каждые 5–15 минут в течение как минимум недели, записывайте результат с меткой времени и вычисляйте долю успешных проб. Две тонкости:

  • Ротируемые пулы скрывают сбои. Если один выход умирает, вы получаете другой; аптайм есть у самого шлюза. Проверяйте шлюз и отдельно отслеживайте, как часто назначенный IP меняется, когда вы запрашивали sticky-сессию — неожиданное изменение — это мягкий сбой.
  • Статические IP (датацентровые, ISP) — это то, для чего обычно заявляют «99.9%». 99.9% — это 43 минуты простоя в месяц; 99.5% — 3.6 часа. Оба легко отличить от недели 15-минутных проб.

Планирование прогонов

Минимальный, но значимый график: задержка + успешность (20–50 запросов) в 03:00, 09:00, 14:00 и 20:00 по местному времени исходящих IP, каждый день в течение семи дней; пропускная способность один раз за прогон; проверка связи каждые 15 минут в течение всего периода. Это несколько сотен килобайт в день на прокси для задержки и несколько десятков мегабайт для пропускной способности — доступно даже на тарифах с оплатой за гигабайт, если использовать небольшой файл. Запускайте с машины, которая всегда включена (идеально — небольшой VPS), через cron и пишите одну CSV-строку на запрос. Наши опубликованные рейтинги — например, рейтинг скорости и рейтинг надежности — построены именно на таких недельных сериях, а не на одном дне.

Чтение результатов

  • p50 задержки близко к норме для типа и p95 в пределах ~3× p50: здорово. p95 во много раз больше p50 означает периодические перегрузки — провайдер oversubscribed в пиковые часы.
  • Процент успешных запросов ниже ~97% на нейтральной цели из-за ошибок на стороне прокси: проблема инфраструктуры, а не ваша.
  • Днем значительно хуже, чем ночью: общая емкость; спросите о выделенных опциях или примите это в планировании.
  • Отличные показатели на датацентровых, плохие на резидентных у того же провайдера: нормально — разные продукты; сравнивайте резидентные с резидентными.
  • Аптайм ниже заявленного: теперь у вас есть лог для поддержки, что ценнее жалобы.

Наконец, помните о типе. Резидентные и мобильные прокси медленнее по конструкции — трафик действительно проходит через домашнюю линию или сотовую вышку — и покупать их ради скорости — это ошибка категории; см. сравнение типов прокси. Измеряйте их относительно их собственного класса и относительно того, что действительно нужно вашей задаче. Также учтите, что проксированное соединение работает по HTTP/2, а не HTTP/3, поэтому сравнивайте сопоставимое, когда прямой базовый уровень находится на сайте с поддержкой QUIC (подробности).

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

Как проверить скорость прокси?

Запросите один и тот же небольшой ресурс напрямую и через прокси, много раз, в разное время суток; сравните время до первого байта (задержку) и отдельно замерьте время загрузки файла фиксированного размера (пропускную способность). Сообщайте медианы и 95-е процентили, а не средние.

Какая задержка прокси считается хорошей?

Относительно прямого подключения: датацентровые прокси добавляют десятки миллисекунд; резидентные и мобильные — примерно 80–300 мс, потому что трафик проходит через потребительское соединение. Оценивайте каждый тип по своей норме.

Как проверить аптайм прокси?

Проверяйте его по расписанию (каждые 5–15 минут) в течение как минимум недели, записывайте каждый результат и вычисляйте долю успешных проверок. Для ротируемых пулов проверяйте шлюз; для статических IP — сам IP.

Почему мои результаты отличаются от заявлений провайдера?

Заявления обычно лучший случай: датацентровый продукт, тихий час, большая загрузка, одна выборка. Ваше измерение включает пиковые часы, конкретные исходящие IP, которые вы получаете, и процентили. Ваше число — то, которое предсказывает ваш опыт.

Стоит ли тестировать на сайте, который я собираюсь парсить?

Не для скорости. Его анти-бот слой добавит вызовы и блокировки, которые измеряют репутацию IP, а не производительность прокси. Используйте нейтральный статический ресурс для скорости и проводите тесты репутации отдельно.

Сколько выборок мне нужно?

Минимум 20 за прогон для стабильной медианы, несколько прогонов в день в течение недели, чтобы увидеть эффекты времени суток и дня недели. Для аптайма неделя нужна в любом случае.