Какой прокси лучше, IPv4 или IPv6: разбор по совместимости площадок

IPv4 и IPv6 это две версии сетевой адресации. Первая записывается четырьмя числами через точку, вида 203.0.113.17. Вторая записывается восемью группами шестнадцатеричных символов, вида 2a03:1b4c:8f::7, и запас адресов там несопоставимо больше. Прокси-сервер подставляет вашему трафику адрес одной из этих версий, и выбор между ними упирается в единственный вопрос: примет ли целевая площадка соединение с такого адреса.

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

Что площадка видит на входе соединения

Соединение до сайта начинается с DNS. Клиент спрашивает у резолвера адрес домена и получает запись A для четвёртой версии, запись AAAA для шестой. Записи AAAA у домена нет, значит с адреса шестой версии идти некуда: маршрута до цели не существует, запрос падает на этапе установки TCP-сессии. Это происходит до всякой антибот-логики, до заголовков, до отпечатка браузера.

Дальше площадка смотрит на источник запроса. Адрес четвёртой версии считается одной единицей: один хост, один счётчик запросов, одна строка в списке доступа. Шестую версию крупные сервисы почти всегда учитывают блоками /64, потому что провайдер выдаёт абоненту сразу подсеть, и внутри неё может быть хоть миллиард адресов. Различие в единице учёта тянет за собой весь остальной расчёт.

Полезно понимать, как система выбирает версию, когда у домена есть обе записи. Функция getaddrinfo возвращает приложению весь набор адресов сразу, а порядок в этом наборе задаёт таблица политик из RFC 6724. По умолчанию шестая версия стоит выше, поэтому клиент с двумя живыми стеками пойдёт к цели именно ей. Приложение об этом не сообщает: в логе парсера остаётся домен и код ответа, версия там не видна. Отсюда и берутся истории, когда прогон настроен на четвёртую версию, а площадка считает запросы с адреса шестой.

У меня есть рабочий список из 40 доменов: поисковая выдача, соцсети, рекламные кабинеты, маркетплейсы, доски объявлений, платёжные шлюзы и почтовые сервисы. Я прогнал по нему проверку записей AAAA и живые запросы с тестового адреса шестой версии. Соединение приняли 18 доменов. Оставшиеся 22 закрыты для шестой версии на входе, и настройками прокси-клиента это не меняется.

Где шестую версию не принимают на входе

Начну с самой глухой категории. Платёжные шлюзы, эквайринг, сервисы рассылок и всё, что стоит рядом с деньгами: 0 из 7 доменов моего списка отдали запись AAAA. Ни один. Логика там простая: подсеть шестой версии выдаётся абоненту почти без ограничений, поэтому антифрод считает такие источники слабо прослеживаемыми и режет их целыми диапазонами.

Доски объявлений: 1 из 6. Единственный домен, который отдал AAAA, при первом же входе показал проверку и держал её до конца сессии. Маркетплейсы: 2 из 9, причём у обоих поддержка есть у витрины и отсутствует у внутреннего API кабинета продавца. Забавная картина: главная открывается по шестой версии, а вызов к /api/v2/offers уходит в таймаут, потому что у поддомена api записи AAAA нет.

Отдельно стоят панели и партнёрские кабинеты с полем «разрешённый IP». Поле часто размечено под 15 символов и валидируется маской четвёртой версии. Адрес шестой версии туда физически не помещается, форма отдаёт «неверный формат» и сохранять отказывается. Я встречал такое у трёх партнёрских программ и у одной панели хостинга. Обойти нельзя никак: белый список принимает только четвёртую версию, и работать через эту панель можно с адреса четвёртой версии.

Почтовые сервисы стоят особняком, у них своя причина отказа. Крупные приёмники требуют от источника обратную запись PTR, и для шестой версии требование жёстче: без корректной обратной зоны письмо уходит в отказ прямо на этапе приветствия SMTP, с текстом про отсутствие rDNS. Обратная зона для блока шестой версии настраивается редко, поэтому доставка с таких адресов держится хуже. Проверка занимает секунды: запрос PTR по адресу выхода показывает, есть ли там имя вообще.

Похожая история со старыми CMS и корпоративными API. Там встречаются самописные фильтры, которые парсят строку адреса регулярным выражением под четыре числа с точками. Приходит адрес шестой версии, регулярное выражение не совпадает, запрос уходит в ветку «неизвестный источник» и получает 403.

Как выглядит отказ со стороны площадки

Разберу отказы по внешнему виду, потому что новичок обычно видит одну строку в логе и делает из неё неверный вывод. Я сам первое время винил прокси-сервер, хотя причина сидела в отсутствии записи AAAA у цели.

Первые три строки говорят о маршрутизации, последние три о политике площадки. Различать их важно, потому что лечатся они по-разному. Таймаут и 0x03 снимаются переключением на четвёртую версию, а 403 по диапазону снимается только сменой адреса на такой, которого нет в списке блокировок.

Отдельно про 0x03. Это стандартный код протокола SOCKS5, означающий недоступность сети. Многие клиенты показывают его как «general failure», поэтому проверять стоит на curl с подробным выводом: там код виден в явном виде. Если вы работаете через приватные адреса четвёртой версии, этот код в логах не появится вовсе, потому что маршрут до цели есть всегда.

Пятая строка самая коварная. Страница открывается, контент приходит, но каждый второй запрос упирается в проверку. Причина в том, что счётчик у площадки ведётся на подсеть /64, а внутри этой подсети сидите не только вы. Восемь адресов из одного блока для площадки складываются в один быстрый источник, который выбирает часовой лимит за несколько минут.

Какие сервисы держат оба протокола

Теперь про хорошее. Поисковая выдача приняла шестую версию по всем 6 доменам из списка, включая региональные зеркала. Крупные соцсети: 5 из 5, поддержка полная, запись AAAA отдаётся и у веб-версии, и у мобильного API. Рекламные кабинеты: 4 из 7, тут разброс по конкретным сервисам большой.

Из таблицы видно распределение. Всё, что связано с публичным контентом и поиском, держит обе версии спокойно. Всё, что связано с аккаунтами, оплатой и модерацией объявлений, живёт на четвёртой версии и другую видеть не хочет.

Я держу это распределение перед глазами, когда планирую прогон. Сбор выдачи по 3000 ключей можно вести любой версией. Работа с кабинетом продавца ведётся только с адреса четвёртой версии, и запасного варианта здесь нет.

Как версия адреса влияет на определение региона

Совместимость упирается ещё и в геобазы. Каталоги адресов четвёртой версии наполнялись десятилетиями, там расписан почти каждый мелкий диапазон вплоть до города и названия провайдера. Блоки шестой версии попадают в те же каталоги крупными кусками: владелец регистрирует сразу /32 или /29 на всю свою сеть, а разметка внутри блока остаётся приблизительной.

Вывод для работы простой. Площадка, которая подбирает контент по региону, с адреса шестой версии обычно определяет страну верно и город мимо. Я проверил это на 18 доменах своего списка, где поддержка AAAA есть. Нужный город угадали 11 целей, ещё 4 показали столицу страны, 3 отдали интерфейс на языке по умолчанию, будто источник им незнаком.

Для сбора обезличенной выдачи такая погрешность терпима. Для замера по конкретному городу она ломает весь прогон: страницы приходят из чужого региона, сравнивать их не с чем. Под такие задачи я беру адрес четвёртой версии с известной привязкой и подтверждаю привязку до старта одним запросом к цели с региональным параметром в адресной строке.

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

Как проверить поддержку до закупки адресов

Проверка занимает у меня минут 20 на цель и снимает вопрос до оплаты. Порядок такой.

Сначала смотрю записи DNS. Одна команда, ответ мгновенный:

dig +short A   target.example
dig +short AAAA target.example
dig +short AAAA api.target.example

Третья строка тут важнее первых двух. Поддомены проверяю отдельно: у витрины запись AAAA бывает, а у API нет, и прогон валится уже на боевых запросах.

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

curl -6 -sS -o /dev/null -w '%{http_code} %{remote_ip} %{time_total}\n' https://target.example/
curl -4 -sS -o /dev/null -w '%{http_code} %{remote_ip} %{time_total}\n' https://target.example/

Две строки вывода рядом дают полную картину. Код 200 в обеих строках означает поддержку обеих версий. Пустой remote_ip и время около 30 секунд в первой строке означают отсутствие маршрута.

Третий шаг: тот же запрос через прокси, потому что поведение цели меняется в зависимости от того, откуда пришло соединение. Здесь я всегда беру схему socks5h, чтобы имя домена резолвил выходной узел:

curl -x socks5h://user:pass@proxy.host:1080 -sS \
     -o /dev/null -w '%{http_code} %{remote_ip}\n' https://target.example/

Схема socks5h отличается от socks5 тем, кто разбирает домен в адрес. С буквой h это делает прокси-сервер, и версия протокола выбирается на его стороне. Это же снимает часть утечек DNS, поэтому работу по протоколу SOCKS5 я ставлю по умолчанию во всех прогонах.

Четвёртый шаг: серия запросов, чтобы нащупать границу лимита. Гоняю 60 запросов с интервалом в секунду и записываю, на каком номере появится 429 либо проверка:

for i in $(seq 1 60); do
  curl -s -o /dev/null -w "%{http_code} " \
       -x socks5h://user:pass@proxy.host:1080 \
       "https://target.example/search?q=test$i"
  sleep 1
done
echo

Строка кодов на выходе читается за секунду. Двадцать значений 200 подряд, потом 429 означают лимит около 20 запросов в минуту с адреса. Дальше это число идёт прямо в расчёт пула.

Результаты четырёх шагов я свожу в одну строку таблицы на каждую цель: домен, наличие AAAA у корня и у поддоменов, код по четвёртой версии, код по шестой, найденный лимит, дата замера. Таблица живёт рядом с конфигом прогона. Когда через месяц цель начинает вести себя иначе, я сравниваю свежий замер со старой строкой и вижу, поменялась политика площадки или сломался мой выходной узел. Без такой записи каждый разбор начинается заново, и на него уходит день.

Ещё одна проверка на входе касается самого пула. Прежде чем ставить адреса в работу, я прогоняю по ним запрос к цели, которую собираюсь трогать чаще всего, и записываю код ответа по каждому адресу. Пять адресов, пять кодов 200, задержка в пределах трёхсот миллисекунд: пул готов. Один адрес отвечает 403 при живых остальных, значит его диапазон уже знаком площадке, и он уходит на другие задачи.

Что делать с двойным стеком

Двойной стек это состояние, когда у машины живы обе версии сразу. Операционная система в таком случае работает по алгоритму Happy Eyeballs из RFC 8305: клиент открывает соединения по обеим версиям почти одновременно и продолжает работать с той, что ответила первой. Для домашнего сёрфинга удобно. Для прогонов вредно.

Вред такой. Часть запросов уходит шестой версией, часть четвёртой, и в логе площадки одна сессия выглядит как два разных источника. Cookie выданы одному адресу, следующий запрос приходит с другого, площадка видит рассинхрон и отправляет сессию на проверку. Я потерял на этом пару дней, пока не догадался открыть tcpdump и посмотреть, какая версия реально уходит в сеть.

Лечится это принудительным выбором семейства адресов. В curl хватает ключа -4. В Python при работе через requests я подменяю выбор семейства в urllib3:

import socket
import urllib3.util.connection as urllib3_cn

urllib3_cn.allowed_gai_family = lambda: socket.AF_INET

import requests
r = requests.get("https://target.example/",
                 proxies={"https": "socks5h://user:pass@proxy.host:1080"},
                 timeout=20)
print(r.status_code)

В Firefox за это отвечает параметр network.dns.disableIPv6 в about:config. В браузерах на движке Chromium отдельного переключателя нет, поэтому версию я отключаю на уровне сетевого адаптера или на уровне профиля антидетект-браузера. В Windows шестую версию можно снять галочкой в свойствах адаптера, и после перезапуска браузера двойного стека уже не будет.

Ещё один момент про двойной стек на стороне выхода. Сам прокси-сервер тоже может иметь обе версии. Тогда даже при форсировании -4 на клиенте выходной узел способен пойти к цели шестой версией, и цель увидит адрес шестой версии. Проверяется это тем же curl через прокси с выводом remote_ip: там видно, какой адрес реально участвовал в соединении. У меня в схеме стоят серверные адреса в дата-центре с фиксированной версией на выходе, поэтому вопрос снят на уровне закупки.

Как считать пул под каждый вариант

Расчёт начинается с лимита цели, который я измерил на четвёртом шаге проверки. Дальше арифметика простая.

Пример со своего прогона. Собираю 3000 страниц выдачи, цель держит 20 запросов в минуту с одного источника, окно на работу два часа. Один источник за два часа отдаёт 2400 запросов, при этом реально я закладываю запас на повторы и беру 60 процентов от максимума. Получается около 1440 полезных запросов с адреса, значит на 3000 страниц нужно 3 адреса при спокойном темпе и 5 адресов с запасом на отвалы.

Теперь то же самое для шестой версии. Счётчик у площадки ведётся на подсеть /64, поэтому тысяча адресов внутри одного блока даёт ровно один источник в глазах цели. Пул считается по числу разных /64. Количество адресов в панели на эту арифметику влияния почти не оказывает.

Проверить принадлежность адресов к разным блокам можно за минуту. Берётся первая половина адреса, 64 бита, то есть четыре группы до двойного двоеточия: у 2a03:1b4c:8f:12::7 и 2a03:1b4c:8f:12::40 эта часть совпадает, значит для цели они один источник. Разными их делает отличие в четвёртой группе и выше. Я гоняю список выданных адресов через короткий скрипт, который обрезает каждый до /64 и считает уникальные значения. Двести адресов в панели нередко складываются в две или три подсети, и расчёт потоков надо вести именно по ним.

Есть и обратная сторона учёта по блокам, приятная. Когда цель считает мягко, одна подсеть /64 позволяет менять адрес на каждый запрос без смены источника в глазах площадки. Для сбора статичного публичного контента это удобно: отпечаток сессии остаётся тем же, а конкретный адрес выхода перебирается свободно.

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

Под сбор данных я держу пул с запасом в полтора раза от расчёта. Для регулярных прогонов удобны адреса с автоматической сменой выхода при месячном доступе к пулу: точка выхода подбирается внутри пула сама, счётчики целей размазываются по разным адресам, каждую неделю пересобирать схему не нужно.

Куда каждая версия ложится в рабочей схеме

Расставлю по задачам, коротко и по существу.

Сбор поисковой выдачи. Обе версии проходят, я смотрю на размер пула и на количество нужных источников. Если цель считает по /64, то экономия на количестве адресов внутри блока превращается в ноль, потому что источник для площадки всё равно один.

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

Рекламные кабинеты. Четвёртая версия проходит везде, шестая на четырёх сервисах из семи. Под кабинеты я беру только четвёртую версию, потому что смена адреса при активной сессии тянет за собой запрос подтверждения по почте.

Аккаунты, доски объявлений, платёжные формы. Только четвёртая версия. Никаких вариантов, шестая версия там либо отсутствует в DNS, либо отбивается антифродом на первом же шаге. Именно под такие задачи я держу пул IPv4 под рабочие задачи, и он закрывает весь мой список целей полностью.

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

Что я держу в схеме сейчас

Основа пула у меня на четвёртой версии, потому что она открывает все 40 целей из списка без исключений. Шестую версию я подключаю точечно, на объёмном сборе публичного контента, где цель отдаёт AAAA и считает лимиты мягко. Такая пара закрывает и совместимость, и объём.

Перед любой новой целью я прохожу те же четыре шага: DNS, прямой запрос, запрос через прокси, серия на поиск лимита. Двадцать минут работы экономят неделю разбирательств с плавающими таймаутами. И привычка смотреть remote_ip в выводе curl окупилась уже несколько раз: пару раз она показала, что выход шёл версией, которую я в настройках отключил.

Рядом в разделе основ лежат смежные материалы: белый или серый адрес с разбором репутации диапазонов, какой порт указывать в клиенте с расшифровкой типовых номеров, доступ к пулу на месяц про то, как считается срок пакета. Из раздела о сборе данных пригодится страница про прокси в коде на Python, там разобрана подмена семейства адресов и работа через requests.