Проверка качества прокси-IP: пять тестов и долгосрочное наблюдение

После настройки прокси сообщение о подключении на странице — лишь первый шаг. На практике пригодность среды определяют детали, которые легко не заметить: кому принадлежит выходной адрес, относится ли диапазон к residential или дата-центру, откуда отправляются DNS-запросы и не раскрывает ли WebRTC реальный адрес.

Пять следующих проверок с конкретными действиями можно пройти по очереди примерно за десять минут.

1. Правильные ли география и оператор?

Откройте любую страницу, показывающую текущий IP, и проверьте три вещи: совпадают ли страна и город с нужным регионом, соответствует ли название оператора купленному сервису и совпадает ли ASN с заявленным.

Так можно выявить распространённую проблему: провайдер заявляет узел в Германии, а фактический выход находится в США. Базы данных IP тоже могут расходиться, поэтому разные сервисы проверки иногда показывают разные результаты. Сверьте два-три источника и ориентируйтесь на зарегистрированную организацию в записи whois.

Заодно проверьте IPv6. В некоторых средах трафик браузера идёт через прокси, но IPv6 по-прежнему выходит локально. На странице проверки только IPv6 убедитесь, что результат тоже указывает на выход прокси. Если там всё ещё виден ваш реальный адрес, среда защищена лишь частично.

2. Residential-диапазон или дата-центр?

Тип IP часто упускают из виду даже чаще, чем географию, хотя его влияние может быть более прямым. Residential-IP регистрируются на операторов широкополосного доступа, а IP дата-центров принадлежат диапазонам облачных провайдеров или IDC. Это различие публично видно в базах типов IP.

Простейший способ — проверить организацию, зарегистрированную для ASN. Названия со словами Cloud, Hosting, Data Center или VPS обычно указывают на дата-центр; Telecom, Broadband, Cable или Communications чаще встречаются у residential- или ISP-диапазонов. Дополнительно проверьте reverse DNS: у residential-IP часто есть обратная запись, назначенная оператором, а PTR для дата-центра нередко следует шаблону домена облачного провайдера.

Если использовать собственный облачный сервер как прокси, выход неизбежно будет относиться к дата-центру. Это определяется инфраструктурой и не меняется настройками. Плюсы — стабильность, контроль и эксклюзивное использование IP; минус — сам тип адреса. Что важнее, зависит от строгости риск-контроля целевой платформы: при мягких правилах дата-центр может подойти, а при жёстких может потребоваться residential- или ISP-прокси.

3. Связность и потери пакетов

Наличие соединения не равно стабильности. Короткий ping может ничего не показать, поэтому нужно наблюдать соединение некоторое время подряд.

Выполните несколько сотен непрерывных ping или повторных запросов к одной цели и посмотрите на потери пакетов и колебания задержки. Хороший результат — нулевые потери и задержка в одном порядке величины. Периодические потери или резкие скачки задержки обычно указывают на перегрузку маршрута или нехватку пропускной способности. Чтобы определить проблемный участок, тестируйте по этапам: сначала задержку от локального устройства до прокси-сервера, затем от сервера до целевого сайта. Явно худший участок и будет узким местом.

Тип прокси тоже должен совпадать. SSH, SOCKS5 и HTTP нельзя произвольно смешивать: выбранный в клиенте протокол должен соответствовать тому, что реально открыт на сервере, иначе соединение может устанавливаться, но трафик проходить не будет. То же относится к портам. Если стандартный порт, например 22 для SSH, закрыт у провайдера, сначала исправьте правила firewall, а уже потом подозревайте пароль.

4. Есть ли утечки DNS или WebRTC?

Эти две проверки показывают, не раскрывается ли ваше реальное местоположение по другому каналу.

Для проверки утечки DNS откройте страницу с тестом DNS leak и посмотрите, с какого узла отправляются запросы на разрешение имён. Если конечный resolver остаётся локальным, проксирование трафика само по себе не помогает: платформа может определить реальный регион по месту DNS-разрешения и сравнить его с географией IP. Решение — включить удалённое DNS-разрешение в среде или выбрать тип прокси, который поддерживает DNS через прокси.

Утечки WebRTC менее заметны. Для peer-to-peer-связи браузер собирает сведения о локальных сетевых интерфейсах, и при некоторых настройках это может обходить прокси и раскрывать частный или даже публичный адрес. Откройте страницу проверки WebRTC и посмотрите, нет ли среди candidate-адресов вашего реального IP. Если есть, отключите WebRTC в браузере или настройках среды либо ограничьте его работой только через прокси.

5. Согласованы ли часовой пояс и язык?

Если выход определяется как США, а браузер использует пекинское время, китайский язык и китайский режим отрисовки шрифтов, возникает явное несоответствие. Установите часовой пояс, язык и регион интерфейса в соответствии с географией IP. Точно имитировать конкретный город не требуется.

Как со временем понять, что IP был помечен

Предыдущие проверки можно завершить за один день, но репутацию IP можно оценить только со временем. Следите за такими признаками, как учащение CAPTCHA на целевом сайте, более частые запросы дополнительной проверки при входе, ограничение функций, которые раньше работали нормально, или мгновенное восстановление работы того же сайта после смены сети.

Если проверка начинает часто срабатывать уже после нескольких действий, обычно есть две причины: неподходящий тип IP либо адресный диапазон раньше массово использовался и накопил историю. Базы anti-abuse могут показать, был ли диапазон ранее помечен. Здесь проявляется преимущество собственного сервера: с момента покупки IP используется только вами и начинает с чистой истории.

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

Порядок проверки в день настройки

1. На странице проверки IP сверить географию, оператора и ASN, затем проверить утечку IPv6
2. По зарегистрированной организации ASN и reverse DNS определить, относится ли диапазон к residential или дата-центру
3. Выполнить несколько сотен непрерывных запросов и оценить потери пакетов и колебания задержки; при необходимости тестировать по участкам
4. Использовать тест DNS leak и тест WebRTC, чтобы убедиться, что реальный выход не раскрывается
5. Согласовать часовой пояс, язык и регион интерфейса с географией IP

После этого раз в одну-две недели снова проверяйте частоту CAPTCHA и дополнительных проверок и фиксируйте результаты. Если команда ведёт несколько сред, постоянное соответствие между каждой средой, её выходом и параметрами заметно упрощает работу. На этом этапе можно использовать управление несколькими средами в инструментах вроде PurpleMark.

Прокси, который работает, и прокси, который подходит для задачи, — не одно и то же. Для первого достаточно правильной настройки; для второго нужно проверить каждый пункт. Именно непротестированные элементы — утечки DNS, WebRTC и тип IP — чаще всего незаметно снижают доверие ко всей среде.