Прокси для парсинга Яндекса: IPv6 пулы, ротация и обход капчи

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

Почему IPv4-прокси проигрывают

Стоимость IPv4-адреса на рынке — от 2 до 5 долларов за штуку. Для парсинга нужны сотни, а лучше тысячи адресов. Умножьте — получите бюджет, который не окупится никаким парсером. IPv6-адрес стоит копейки, а точнее — он практически бесплатный. Провайдеры выдают подсети /64, где 18 квинтиллионов адресов. Вам столько не надо, но сам масштаб открывает возможности.

Второй момент — скорость блокировки. Яндексу достаточно 10-15 запросов с одного IPv4, чтобы включить защиту. С IPv6 вы можете сменить адрес на каждый запрос. Технически это выглядит как разные пользователи с разных устройств.

Как устроен IPv6-пул

Представьте подсеть 2a00:1838:1234::/48. Внутри — 65 тысяч подсетей /64. Каждая /64 — это ваша "квартира" с неограниченным числом адресов. Прокси-сервисы выдают вам доступ к такой подсети, а вы уже сами формируете адреса для каждого запроса.

```bash

Пример генерации адресов из подсети /64

prefix="2a00:1838:1234:5678"

for i in \$(seq 1 100); do

suffix=\$(printf '%x' \$i)

echo "\${prefix}::\${suffix}"

done

```

Адреса генерируются на лету. Никакого предварительного списка. Хотите 10 тысяч уникальных адресов — пожалуйста.

Настройка ротации

Ротация бывает двух типов: по времени и по запросам. Для Яндекса критичен второй вариант. Один адрес — один запрос. Иначе капча.

```python

import requests

import random

def get_proxy():

Генерация случайного IPv6 из подсети

prefix = "2a00:1838:1234:5678"

suffix = format(random.randint(1, 65535), 'x')

return f"http://user:password@[{prefix}::{suffix}]:8000"

session = requests.Session()

for query in ["купить iphone", "доставка цветов", "ремонт квартир"]:

proxy = get_proxy()

session.proxies = {"http": proxy, "https": proxy}

response = session.get(f"https://yandex.ru/search/?text={query}")

Обработка ответа

```

Обратите внимание на формат — IPv6 в URL обязательно оборачивается в квадратные скобки. Это частая ошибка новичков.

Капча: как с ней жить

Капча от Яндекса — это SmartCaptcha. Она анализирует поведение, заголовки, TLS-отпечаток. Чистый IP без истории — сразу подозрение. Поэтому просто менять адреса недостаточно.

Рабочая схема: перед основным запросом сделайте 2-3 "прогревочных" запроса к главной странице Яндекса. Создайте историю. Затем переходите к поиску. Прогрев занимает 3-5 секунд на адрес, но снижает вероятность капчи в разы.

```bash

Прогрев адреса перед парсингом

curl -x "http://user:password@[2a00:1838:1234:5678::1]:8000" \

-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \

https://yandex.ru/ -o /dev/null -s -w "%{http_code}\n"

```

Второй уровень защиты — заголовки. Без User-Agent, Accept-Language и прочего Яндексу сразу ясно, что это бот. Используйте свежие реальные заголовки из браузера.

Сервис lexic.ml

Когда я начинал работать с IPv6-прокси для Яндекса, перепробовал десятки сервисов. Большинство давали либо грязные подсети, либо урезанный функционал. lexic.ml работает с 2015 года и специализируется именно на IPv6. У них можно взять чистую подсеть /64 под парсинг Яндекса, с нормальной скоростью и без дурацких ограничений по трафику.

Технически это выглядит как SOCKS5-прокси с авторизацией по логину и паролю. Вы получаете доступ к подсети, а адреса генерируете сами. Никаких лишних прослоек — чистый канал до Яндекса.

Определение блокировки

Яндекс не всегда показывает капчу. Иногда он просто отдаёт пустую выдачу или редиректит на проверку браузера. Отслеживайте коды ответов и содержимое страницы:

- HTTP 200 с капчей — страница содержит `captcha` в URL или HTML

- HTTP 302 — редирект на `yandex.ru/showcaptcha`

- HTTP 403 — полная блокировка адреса

```python

def check_block(response):

if response.status_code == 403:

return "blocked"

if "captcha" in response.url:

return "captcha"

if len(response.text) < 1000:

return "empty"

return "ok"

```

Если видите пустую выдачу — адрес уже скомпрометирован. Меняйте без сожаления.

Скорость и лимиты

Яндекс выдерживает примерно 15-20 запросов в секунду с одного IP-диапазона. Если подсеть /64 — то ограничение не по адресам, а по нагрузке на сервис. Практический потолок — 100-150 запросов в секунду с одной подсети. Дальше начинаются таймауты и троттлинг.

Реальные цифры с lexic.ml: 50 запросов в секунду, 200 тысяч запросов в сутки — без единой капчи. При условии грамотной ротации и прогрева.

Обработка ошибок

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

```python

import time

from requests.exceptions import ProxyError, ConnectionError

def fetch_with_retry(url, max_retries=3):

for attempt in range(max_retries):

try:

proxy = get_proxy()

response = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)

if response.status_code == 200:

return response

except (ProxyError, ConnectionError):

time.sleep(2 ** attempt)

return None

```

Таймаут в 10 секунд — оптимален. Меньше — ловите ложные ошибки. Больше — теряете время на зависшие соединения.

Распределённый парсинг

Одна машина — узкое место. Если нужно больше 200 тысяч запросов в сутки, подключайте несколько серверов. Каждый получает свою подсеть /64. Координация через Redis или простое распределение списка запросов по файлам.

```bash

Раздача запросов по воркерам

split -l 1000 queries.txt worker_

for f in worker_*; do

python3 parser.py \$f &

done

wait

```

Такой подход масштабируется горизонтально. Добавили сервер — добавили подсеть. Всё остальное работает без изменений.

Итоги

Парсинг Яндекса через IPv6 — реальность. Ключевые моменты: чистые подсети, ротация на каждый запрос, прогрев адресов, правильные заголовки. Соблюдаете эти правила — капча остаётся в теории. Нарушаете — получаете блокировку подсети и теряете время.

Начните с малого: возьмите тестовую подсеть, настройте ротацию, проверьте на 1000 запросов. Если всё чисто — масштабируйтесь. Если капча появляется — смотрите в сторону прогрева и заголовков. Опыт приходит с практикой, а не с чтения статей.