IPv4 или IPv6 proxy: адреса, стоимость и совместимость

В этом руководстве два протокола сравниваются по четырём осям: адресное пространство, то, как сайты считают rate limit, модель стоимости и совместимость. Показано, как проверить поддержку IPv6 у цели через dig, на что смотреть на стороне клиента и как измерить долю успешных запросов на небольшой выборке. В примерах используется шлюз WeProxy gw.weproxy.com.tr:8989, а USER и PASSWORD — заглушки для учётных данных.

Чем IPv4 proxy отличается от IPv6 proxy?

Proxy пересылает ваш запрос на цель со своего выходного адреса. Если этот адрес IPv4, целевой сервер видит адрес вида 203.0.113.10. Если IPv6 — что-то вроде 2001:db8:4a1f::25. Соединение между клиентом и proxy, а также протокол proxy (HTTP или SOCKS5) от этого выбора не зависят.

Разница проявляется на выходном участке. Proxy с IPv6-выходом обязан подключаться к цели по IPv6. Если у цели нет IPv6-адреса, подключаться некуда. IPv4-выход такого ограничения не имеет, потому что подавляющее большинство сайтов, публикующих IPv6, сохраняют и IPv4 (dual-stack).

Дефицит адресов против избытка адресов

Адресное пространство IPv4 — 32 бита, всего около 4,3 млрд адресов. Свободный пул IANA закончился в 2011 году, а региональные регистраторы в последующие годы перевели выдачу новых блоков на листы ожидания и рынок передачи адресов. Поэтому каждый IPv4-адрес — отдельная статья расходов, и провайдеры используют его снова и снова.

Адресное пространство IPv6 — 128 бит (RFC 8200). RFC 4291 отводит младшие 64 бита адреса под идентификатор интерфейса, поэтому стандартный блок для одной локальной сети — /64. В одном /64 содержится 2^64 адресов, примерно 18 квинтиллионов. Один /48 у провайдера включает 65 536 подсетей /64. В IPv6 проблема не в том, чтобы найти адреса, а в том, как цель их группирует.

Почему сайты ограничивают IPv6-трафик по /64 или /48?

В IPv4 rate limit обычно ведётся по отдельному адресу, потому что один адрес, как правило, означает одного абонента или одну группу за NAT. В IPv6 эта логика не работает. Одно устройство может создать сколько угодно адресов внутри своего /64; расширения приватности в операционных системах (RFC 8981) и так делают это регулярно. Сайт, считающий по адресам, принимал бы каждый новый адрес за нового посетителя.

Поэтому многие WAF и ограничители скорости агрегируют IPv6-адреса на уровне префикса /64. Некоторые идут дальше и считают на уровне /56 или /48, поскольку домашним и корпоративным сетям обычно выдают блоки такого размера. В итоге тысяча разных адресов из одного /64 может выглядеть для цели как один клиент.

Отсюда следует, что главный критерий при выборе IPv6 proxy — «сколько отдельных префиксов», а не «сколько адресов». Пул с огромным числом адресов, собранных в одном /64, на цели с подсчётом по префиксу получает 429, как один IP. Когда блоки распределены по разным /64 и /48, распределяется и счётчик. Уровень, на котором считает цель, снаружи не виден; его нужно измерить небольшим тестом.

Репутация переносится вместе с префиксом точно так же. Если один адрес в /64 использовали для злоупотреблений, блокировка часто применяется ко всему префиксу. Большинство IPv6-выходов идут из сетей дата-центров, и их ASN легко опознать. О разнице в детектировании между datacenter и residential IP читайте в сравнении residential и datacenter; те же сигналы действуют и для IPv6.

Чем отличается модель стоимости IPv4 и IPv6 proxy?

Поскольку IPv4 дефицитен, цена IPv4 proxy привязана к адресам или трафику. Rotating IPv4-продукты (datacenter, residential, мобильные) тарифицируются за GB: вы пользуетесь большим общим пулом и платите за переданный трафик. Статические IPv4-продукты оплачиваются за адрес на период, потому что этот адрес закреплён за вами на весь срок.

В IPv6 стоимость адреса падает почти до нуля. Это переносит расчёт с адресов на порты и время. Rotating IPv6 Proxy от WeProxy продаётся помесячными пакетами за порт, без квоты; у IPv6-пакетов с портами нет ограничения bandwidth. Пакеты Static Datacenter IPv6 оплачиваются за адрес помесячно и идут с безлимитным bandwidth.

Практический вывод такой. Для задач большого объёма с небольшими ответами на страницу модель за GB быстро растёт; модель за порт без квоты делает стоимость предсказуемой. Для задач малого объёма, где нужно высокое доверие, residential IPv4 с оплатой за GB даёт результат при меньшем общем трафике. Актуальные пакеты и стартовые варианты указаны на страницах продуктов.

С какими сайтами работает IPv6 proxy?

IPv6 proxy работает, только если у того самого имени хоста, к которому вы обращаетесь, есть запись AAAA. Запись A связывает имя хоста с IPv4-адресом, запись AAAA — с IPv6-адресом. Если при разрешении цели proxy не находит AAAA, ему не к чему подключаться с IPv6-выхода. Результат — ошибка соединения на стороне клиента: с HTTP proxy обычно 502, с SOCKS5 — ответ «host unreachable» или «address type not supported».

Часть крупных платформ, например Google, публикует записи AAAA для основных доменов. Многие небольшие сайты, e-commerce-платформы и старые хостинги работают только по IPv4. Поддержка различается и по именам хостов: у основного домена AAAA есть, а у API-поддомена нет, или наоборот, — обычная ситуация. Поэтому проверяйте не название сайта, а каждое имя хоста, которое реально вызывает ваш код.

Проверка записи AAAA у цели через dig

Самая быстрая проверка — команда dig. Запросите записи A и AAAA для одного и того же имени хоста по отдельности:

# Есть ли IPv6-адрес?
dig AAAA google.com +short

# IPv4-адрес для сравнения
dig A google.com +short

# Отдельно проверьте поддомен, который вызывает ваш код
dig AAAA api.example.com +short

Если в выводе есть адрес с двоеточиями, например 2a00: или 2001:, запись AAAA существует. Если вывод пустой — её нет. Если в выводе только имя с точкой на конце (CNAME) и под ним нет строки с адресом, то и в конце цепочки AAAA нет. В Windows тот же запрос выполняется командой nslookup -type=AAAA google.com.

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

Сторона клиента: передайте имя хоста proxy

Вашему клиенту не нужна IPv6-связность. Участок между клиентом и шлюзом может идти по IPv4; IPv6 используется только между proxy и целью. Условие одно: клиент должен передать цель proxy в таком виде, чтобы proxy мог дойти до неё по IPv6.

Для этого нужно передать proxy имя хоста. В HTTP proxy CONNECT example.com:443 передаёт имя хоста, и proxy сам разрешает запись AAAA. В SOCKS5 схема socks5h:// передаёт имя хоста как доменное имя (RFC 1928 ATYP 0x03). Если клиент с socks5:// разрешает имя локально и получает только IPv4-адрес, он отправит этот адрес на IPv6-выход, и соединение не установится. Локальное разрешение к тому же является DNS-утечкой; подробности — в руководстве по DNS leak, разница протоколов — в статье HTTP vs SOCKS5.

Если вы используете IP whitelist, есть ещё одна деталь. Если ваш сервер подключается к шлюзу по IPv6, в панели должен быть зарегистрирован именно этот IPv6-адрес. Если в whitelist только ваш IPv4-адрес, вы получите 407. Другие причины этой ошибки и порядок проверки описаны в руководстве по кодам ошибок прокси. В WeProxy авторизацию по логину/паролю и IP whitelist можно использовать одновременно по HTTP и SOCKS5.

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

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

# Echo-эндпоинт, который отвечает и по IPv4, и по IPv6
curl -sS -x "http://USER:[email protected]:8989" https://api64.ipify.org
echo

Если в ответе адрес с двоеточиями, выход IPv6. Если возвращаются четыре числа через точку, выход IPv4; проверьте тип пакета и данные подключения. Ту же проверку можно сделать в браузере с помощью инструмента IPv6 checker, а общую работоспособность proxy подтвердить через proxy checker.

Затем небольшая выборка запросов к цели:

import socket
import requests

PROXY = "http://USER:[email protected]:8989"
proxies = {"http": PROXY, "https": PROXY}

def has_aaaa(host):
    try:
        return bool(socket.getaddrinfo(host, 443, socket.AF_INET6, socket.SOCK_STREAM))
    except socket.gaierror:
        return False

def success_rate(url, attempts=20):
    ok = 0
    for _ in range(attempts):
        try:
            r = requests.get(url, proxies=proxies, timeout=(10, 30))
            if r.status_code == 200:
                ok += 1
        except requests.exceptions.RequestException:
            pass
    return ok / attempts

host = "example.com"
print("Запись AAAA:", has_aaaa(host))
exit_ip = requests.get("https://api64.ipify.org", proxies=proxies, timeout=(10, 30)).text
print("Выходной IP:", exit_ip)
print("Доля успешных:", success_rate(f"https://{host}/"))

has_aaaa использует локальный резолвер; это предварительная проверка, а не часть рабочего потока. Сам запрос идёт через HTTP proxy, и имя хоста разрешается на стороне proxy. Запустите тот же скрипт и с IPv4-пакетом. Разница между двумя долями в цифрах покажет, как цель обращается с IPv6-трафиком. Подробности настройки — на странице интеграции proxy с Python.

Таблица сравнения IPv4 и IPv6 proxy

Строка «единица подсчёта rate limit» зависит от цели. Читайте её как допущение, которое нужно проверить, а не как правило.

Для каких задач подходит IPv6 proxy, а для каких нет?

Сценарий, где IPv6 proxy силён, понятен: цель поддерживает IPv6, задаче нужно много запросов, и каждый запрос короткоживущий. Примеры:

• Сбор поисковой выдачи и SEO-данных на крупных платформах, публикующих IPv6 (сценарий SEO proxy).
• Запросы с высокой параллельностью к API-эндпоинтам с записью AAAA.
• Проверка IPv6-доступности собственной инфраструктуры или инфраструктуры клиента из разных стран.
• В web scraping — вынос имён хостов с поддержкой IPv6 в отдельную очередь и масштабирование объёма там.

Слабые сценарии так же понятны. Если цель работает только по IPv4, IPv6 proxy для неё не подходит. Если страница подгружает ресурсы с нескольких доменов (CDN, API, платёжный провайдер) и один из них только IPv4, браузерная автоматизация обрывается на полпути. Если цель строга к IPv6-префиксам дата-центров или ждёт residential-сигнала доверия, IPv4 residential даёт более высокую долю успешных запросов.

Для большинства команд самый надёжный путь — смешанный подход. Разделите имена хостов на две группы по записи AAAA. Те, что поддерживают IPv6 и показывают высокую долю успеха, направляйте в IPv6-пул, остальные и критичные потоки — в IPv4. Такое разделение даёт меньше ошибок, чем перевод всех целей scraping на IPv6 вслепую.

Как выбрать IPv6 proxy в WeProxy?

Выбор зависит от того, сколько должна длиться сессия:

Rotating IPv6 предназначен для задач большого объёма без сессий; по данным страницы продукта, в Datacenter-пакетах IP меняется на каждый запрос, а в Residential-пакетах — с интервалом не менее 120 секунд. Sticky IPv6 удерживает один выход от 1 до 120 минут в сценариях с логином или несколькими шагами. Static Datacenter IPv6 — для интеграций, где нужна постоянная идентичность или whitelist на другой стороне. Все три поддерживают HTTP и SOCKS5. Общую разницу между sticky и rotating см. в руководстве sticky vs rotating.

Если цель оказалась только IPv4, переключите этот поток на IPv4-продукты: Rotating Datacenter IPv4 для большого объёма, Rotating Residential IPv4 для высокого доверия.

Какие правила действуют при использовании IPv6 proxy?

Больше адресов не меняет правил цели. Расширять пул, чтобы обойти rate limit по префиксу, — не решение, если это нарушает условия использования цели. Учитывайте ответы 429 и Retry-After и держите параллельность на уровне, который цель выдерживает.

Если в собираемых данных есть персональные данные, обязательства по KVKK и GDPR нужно рассматривать отдельно; эта статья не является юридической консультацией. Автоматизация должна ограничиваться общедоступными разделами, которые разрешены правилами, и выполняться в рамках правил допустимого использования WeProxy.

IPv4 или IPv6: чек-лист для решения

1. Составьте список всех имён хостов, которые вызывает ваш код, а не только основного домена.
2. Для каждого выполните dig AAAA <host> +short. Имена с пустым результатом перенесите в список IPv4.
3. Для имён с записью AAAA подтвердите IPv6-выход через api64.ipify.org или инструмент IPv6 checker.
4. Используйте HTTP proxy или socks5h://; передайте имя хоста proxy.
5. Запустите одну и ту же выборку из 20 запросов на IPv4- и IPv6-пакетах и сравните доли успеха.
6. Если доли близки и объём большой, переходите на IPv6. Если доля низкая или поток критичный, оставайтесь на IPv4.
7. Если видите 429, исходите из того, что цель считает по /64 или /48; снижайте параллельность, а не наращивайте пул вслепую.

IPv4 — инструмент совместимости, IPv6 — инструмент масштаба. Решение определяется не самим протоколом, а записью AAAA у цели и измеренной вами долей успешных запросов.