Мы прогнали бенчмарк против собственного пула резидентских прокси. Вот цифры.

Когда покупатель выбирает residential-провайдера, проверить заявленные характеристики до подписки негде. После подписки тоже трудно — пул непрозрачный, метрики у каждого вендора свои, сравнить корректно почти невозможно.

Чтобы это починить хотя бы у себя, мы написали воспроизводимый бенчмарк и прогнали его против собственного пула Geekproxy.io. В этом посте шесть метрик, которые вместе описывают, как пул ведёт себя в продакшене:

• Покрытие 69 стран
• Таргетинг по 50 штатам США
• Таргетинг по городам и провайдерам (ISP)
• Разнообразие пула по странам (уникальные IP, /24, /16)
• Репутация IP в независимой базе fraud-score
• Browser-проба через настоящий Chrome против четырёх сайтов с агрессивным антиботом: Instagram, TikTok, LinkedIn, Steam

Скрипт бенчмарка открыт на GitHub. С аккаунтом Geekproxy любой результат из этого поста можно перепроверить за час одной командой.

Зачем вообще бенчмаркать прокси-пул

Откройте страницу с тарифами любого крупного residential-провайдера. Характеристики везде одни: 195+ стран, 100M+ IP, таргетинг до города, 99.9% uptime. Эти цифры покупатель проверить не может: пул закрытый, определения у всех свои.

Что хочется знать на самом деле:

1. Если я запрашиваю страну X, получу ли я IP, который геолоцируется в X, или мне дадут американский IP, в базе вендора помеченный как X?
2. Если я делаю 100 ротирующихся запросов, сколько уникальных IP я увижу? Сколько /24? Это настоящий пул или маленький bucket, который циклится?
3. Помечает ли публичный сервис fraud-detection эти IP как proxy-трафик? Если да, антибот тоже пометит.
4. Загрузит ли настоящий браузер Instagram, TikTok, LinkedIn через этот прокси без challenge?
5. Если я указываю штат, город или конкретную ASN, параметр реально работает?

На каждый из этих вопросов есть да/нет ответ в момент запуска эксперимента. Мы их запустили.

Методология

Тестировали через обычный тариф Geekproxy residential, тот же, что получает любой новый клиент. Никакого премиум-пула, никаких whitelist-IP, никаких внутренних эндпоинтов. Бенчмарк бьёт в продакшен.

Запросы идут через прокси и попадают в один из:

• api.ipify.org фиксируем исходящий IP
• ipinfo.io, ip-api.com, ipapi.co консенсус по геолокации
• proxycheck.io fraud-score и детекция proxy/VPN
• продовые HTML/JSON-эндпоинты Amazon, Walmart, Steam, Instagram, TikTok, LinkedIn в зависимости от метрики

Каждый параметр таргетинга описан в грамматике username Geekproxy. Мы использовали:

Browser-пробы используют nodriver, активный наследник undetected-chromedriver. Chrome не умеет принимать user:pass@host:port в аргументе --proxy-server напрямую, поэтому мы поднимаем маленький локальный HTTP CONNECT-релей, который добавляет заголовок Proxy-Authorization на исходящих запросах. 60 строк asyncio, и это самый чистый способ дотянуть настоящий Chrome до резидентского прокси с аутентификацией.

Полный скрипт бенчмарка открыт на GitHub. Ссылка в конце.

Покрытие стран: 69 из 69

Geekproxy покрывает существенно больше 69 стран, но 69 удобный размер выборки: помещается в один разумный график, при этом охватывает все населённые континенты и все крупные рынки, где residential-прокси нужны. Это та цифра, которую мы взяли как репрезентативную.

Прогнали по каждой стране 5 запросов через cr.XX (rotating, порт 823). Для каждого успешного ответа спросили три независимых геолокационных API (ipinfo.io, ip-api.com, ipapi.co), к какой стране относится IP, и взяли мажоритарный голос.

Результат: 69 из 69 стран вернули живой residential IP. Когда IP возвращался, геолокационный консенсус совпадал с запрошенной страной в 98.6% случаев.

Включая Китай. Запрос cr.cn через rotating-порт работает, мы получили валидные китайские IP в той же серии:

proxy: http://login__cr.cn:[email protected]:823
  status=200  ip=218.197.143.66
  status=200  ip=223.254.133.173
  status=200  ip=223.254.130.95

Это редкость для residential-пулов. Большинство провайдеров материковый Китай не покрывает структурно, у нас покрытие есть.

Распределение latency по странам ожидаемое для резидентского пула: низкие сотни миллисекунд в EU и US, многосекундные значения в странах далеко от нашей тестовой машины (Южная Азия, Африка). В этом прогоне latency не была фокусом, но скрипт записывает её для каждой пробы.

Таргетинг штатов США: 92% попаданий

Параметр state.X задокументирован, но обозревателями почти не тестируется. Мы прогнали все 50 штатов, по 5 попыток каждый, через rotating-порт 823.

Когда IP возвращался, он попадал в запрошенный штат в 91.7% случаев по консенсусу регионов от трёх геолокационных API.

Оставшиеся 8% несовпадений почти всегда приграничные кейсы или расхождения между geo-базами. Город под Нью-Йорком один API относит к «New York», другой к «Connecticut» (Stamford в 30 км от NYC). Иногда у конкретного IP-блока в одной базе ещё не обновился владелец после переразмещения. Сам прокси при этом выдал IP из правильного географического региона, различие на стороне публичных геолокационных баз.

Если перепроверить ту же выборку на коммерческой базе вроде MaxMind GeoIP2 Enterprise, попадание ожидаемо ближе к 100%: платные базы обновляются чаще и точнее режут штаты по фактическим административным границам. Публичные API мы используем как общедоступную, воспроизводимую базу сравнения. Для ad-verification или local-SEO задачи 92% точности по штату через state.X достаточно, чтобы делать реальную работу.

Покрытие городов: 83% попаданий по консенсусу

Взяли 18 пар страна|город по основным рынкам. Тот же протокол: пробуем через city.X 5 раз на город, смотрим IP, сравниваем города.

Страна (cr.XX внутри запроса) попала в 100% случаев. Город по консенсусу 3 геолокационных API: 83%.

Тут важный нюанс: публичные геолокационные базы плохо разрешают именно города. Один API говорит «Berlin», второй «Brandenburg», третий «Schoenefeld» для одного и того же IP в пригороде Берлина. По строгому правилу «нужно совпадение в большинстве» это считается промахом, хотя физически IP в правильной агломерации.

Лондон попал в категорию city=London в 100% случаев на каждой пробе. Берлин, Токио, Сан-Паулу: 90%+. По остальным городам цифра ниже из-за рассинхрона баз, не из-за прокси. Если перепроверить ту же выборку на платной базе вроде MaxMind GeoIP2 City, попадание ожидаемо выше 95%, потому что коммерческие базы заметно лучше разрешают пригороды и метро-зоны.

Таргетинг по ISP: 91% попаданий

asn.X нишевая фича, которую большинство резидентских провайдеров не выпячивает. Она реально нужна: многие системы fraud-detection классифицируют IP именно по ASN, поэтому возможность пройти через конкретный residential-ISP это реальный рычаг для ad-verification, скрейпинга соцсетей и мониторинга конкурентов.

Прогнали 11 крупных residential-ISP по пяти странам: Comcast, AT&T, Verizon, Charter / Spectrum, Cox, T-Mobile US, BT, Virgin Media, Deutsche Telekom, Orange France, Vodafone Spain.

90.9% попаданий при N=5 проб на ASN, по консенсусу 3 источников ASN-данных.

Оставшиеся 9% это, как и в случае с городами, рассинхрон публичных ASN-баз. ipinfo и ip-api берут данные из разных снимков WHOIS и обновляются с задержкой. IP-блок мог поменять владельца, а одна из баз ещё не подтянула. Сам прокси при этом возвращает IP из правильного routing-prefix. На авторитетной WHOIS-сверке (Team Cymru или коммерческая база IP2ASN) ожидаемое попадание заметно ближе к 100%.

Маленькое практическое примечание: asn.X нужно использовать вместе с cr.XX той же страны, к которой принадлежит ASN. Это в одну строчку:

login__cr.us;asn.7922   # Comcast US

И есть зеркальная фича, про которую тоже полезно знать: noasn.X позволяет исключить конкретный ASN из пула. Полезно, когда нужно гарантированно не получать IP из определённого датацентрового или mobile-провайдера в выборке. Например:

login__cr.us;noasn.AS21928   # US, но без T-Mobile

В коде бенчмарка обе фичи обёрнуты в ProxyParams.

Разнообразие пула: 100% уникальных в Бразилии

Заявление «у нас 100 миллионов IP» снаружи проверить невозможно. Поэтому мы задаём другой вопрос: на последовательности N ротирующихся запросов как часто пул выдаёт повтор IP, и насколько новая IP-адресация отличается от предыдущей?

По каждой из семи стран (US, GB, DE, FR, JP, BR, AU) мы выпустили 40 ротирующихся запросов через порт 823 и посчитали три вещи: уникальные IP, уникальные /24, уникальные /16.

Главный результат: в Бразилии все 34 успешных пробы вернули IP в 34 разных /16-подсетях. Ни одного повтора ни на одном уровне. GB и Франция дали 100% уникальности на 33 и 25 успешных пробах. US, Япония и Австралия 93–97%. Германия 91%.

Для антибота, работающего на уровне /24 (а большинство так и делает), это значит, что последовательные ротирующиеся запросы выглядят как из независимых сетей. Для клиента, который делает высокочастотный скрейпинг или ad-verification, эта метрика важнее заявленного размера пула.

Репутация IP: 99.4% чистых

Размер пула и уникальность не важны, если каждый IP в пуле лежит на публичном блок-листе. Поэтому мы взяли 500 уникальных US IP из ротирующегося пула и пропустили каждый через proxycheck.io, один из самых цитируемых публичных сервисов по репутации IP.

Результат: 497 из 500 IP получили risk 0 и не были помечены как proxy, VPN или Tor. 3 из 500 получили moderate risk. Ноль high-risk.

То есть 99.4% наших residential-IP проходят независимую proxy-detection как обычный домашний трафик.

В любом резидентском пуле, независимо от вендора, всегда будет небольшой процент IP, которые в данный момент сидят на чьём-то блок-листе. Устройства в пуле тоже занимаются обычным потребительским сёрфингом, иногда из сетей, которые автору блок-листа не нравятся. 0.6% в нашем прогоне лежат в moderate-диапазоне и прошли бы большинство антибот-фильтров, кроме самых жёстких.

Browser-layer: настоящий Chrome на агрессивных сайтах

HTTP-пробы выше полезные, но тест, который важнее всего большинству клиентов: может ли настоящий браузер через прокси пройти реальную антибот-стену. Поэтому мы написали browser-layer пробу.

Работает так: nodriver запускает Chrome с --proxy-server=127.0.0.1:<port>. Локальный порт это маленький TCP-релей, который принимает неаутентифицированный CONNECT от Chrome, добавляет Proxy-Authorization: Basic ... из username/password Geekproxy и форвардит в rs.geekproxy.io:823. С точки зрения Chrome аутентификации в цепочке нет.

Этот стек направили на четыре сайта, которые регулярно цитируют как сложные для резидентских прокси:

Все четыре загрузились. Никаких challenge-страниц, никаких 999 от LinkedIn, никаких Press & Hold от вариантов с PerimeterX. HTML отрендерился, title был ожидаемым, скриншоты показывают реальный контент.

Скриншот Instagram показывает публичный preview профиля с модалкой «See photos, videos and more from instagram», которую Meta выдаёт незалогиненным посетителям. Это тот же контент, который видит обычный посетитель с обычного домашнего соединения. Никакого bot-challenge.

LinkedIn-скриншот показывает страницу Microsoft с About us, аффилированными страницами (GitHub, Microsoft Learn, Microsoft Azure), Similar pages. Реальный контент, без challenge.

Это единственная метрика в этом посте, которая требует browser-layer. Остальные пять чистый HTTP. Мы разделяем их в коде: metrics/http_probe.py для сырого HTTP, metrics/browser_probe.py для nodriver-стека.

Воспроизводимость

Всё в этом посте можно перепроверить меньше чем за час. Клонируйте репозиторий, скопируйте .env.example в .env, вставьте свои Geekproxy-кредиты, запустите:

.venv/bin/python -m benchmark.runner coverage --kind country --probes 5
.venv/bin/python -m benchmark.runner coverage --kind state   --probes 5
.venv/bin/python -m benchmark.runner coverage --kind city    --probes 5
.venv/bin/python -m benchmark.runner coverage --kind asn     --probes 5
.venv/bin/python -m benchmark.runner pool-diversity --requests 40 --country br
.venv/bin/python -m benchmark.runner fraud-score    --ips 500 --country us
.venv/bin/python -m benchmark.runner browser        --target instagram_profile --country us
.venv/bin/python scripts/make_charts.py

Скрипт графиков читает результаты последнего прогона по каждой метрике и пишет PNG в data/charts/. Если ваши цифры существенно расходятся с нашими, заведите GitHub issue с описанием расхождения. Разберёмся и обновим пост.

Заметки по методологии

Несколько вещей, чтобы внимательный читатель мог решить, насколько доверять цифрам:

Геолокационный консенсус. Когда мы пишем «IP был в Калифорнии», это значит, что два из трёх публичных API (ipinfo.io, ip-api.com, ipapi.co) согласны, что он был в Калифорнии. Эти базы расходятся примерно на 5–10% IP, особенно в плотных городах и на границах стран и штатов. На коммерческой базе вроде MaxMind GeoIP2 Enterprise попадание ожидаемо выше: она обновляется чаще и точнее режет административные границы. Публичные API мы используем как общедоступную, воспроизводимую базу сравнения. Цифры по штатам, городам и ASN это нижние границы реальной точности.

Размеры выборок. Покрытие стран 5 проб на страну, штатов 5 на штат, городов и ASN по 5. Pool diversity 40 запросов на страну. Fraud score 500 уникальных IP. Достаточно, чтобы рассказать чёткую направленную историю.

Сервисы fraud-score. proxycheck.io один из трёх источников репутации, которые поддерживает runner. Два других (IPQualityScore и IPHub) требуют API-ключей, с которыми мы здесь не запускались. Если ключи есть, runner их использует и отчёт по каждому IP станет богаче.

Ожидания в browser-layer. Современные соцсети лениво подгружают контент. Мы ждём 25 секунд после загрузки страницы, скроллим несколько раз и ждём ещё немного перед скриншотом, чтобы дать JS отрисоваться. Без этого скриншот часто пустой кадр, хотя title и body-текст правильные. Дефолты в репо именно такие.

Что с этим делать

Если вы выбираете residential-провайдера, не верьте этому посту на слово. Возьмите бенчмарк, наведите на наш пул, наведите на чей-то ещё пул и сравните по одним и тем же метрикам. Мы открыли методологию для того, чтобы сравнение было возможным.

Если вы уже клиент Geekproxy и одна из этих метрик важна вашему use-case, у вас теперь есть точка отсчёта. ISP-таргетинг с 91% попаданий это число, под которое можно планировать. Покрытие стран 69 из 69 это число, которое можно сказать стейкхолдеру. 99.4% чистых IP по proxycheck это число, на которое опирается ваша scraping-операция.

Если хотите обсудить use-case, который мы здесь не покрыли (sticky-сессии в продакшене, concurrency-стресс при 1000+ параллельных, источник IP из мобильных сетей), напишите нам, и мы публично прогоним этот эксперимент тоже.

---

Скрипт бенчмарка и графики: github.com/geekproxy/residential-proxy-benchmark

Попробовать прокси, против которых гонялся бенчмарк: geekproxy.io