Google Search через IPv6 прокси: парсинг выдачи и обход капчи

Почему Google упирается рогом именно на IPv6

Google — это, пожалуй, самый сложный目标 для любого прокси-пула. И дело не только в капче. Основная беда в том, что Google видит IPv6-подсети целиком. Если у вас /64, а тем более /48, Google прекрасно понимает, что все адреса из этого блока принадлежат одному провайдеру. И начинает резать.

На IPv4 ситуация иная. Там адреса давно дефицит, провайдеры выдают их поштучно, и Google не может так нагло банить целые /24. А вот IPv6 — это бесконечный океан адресов, и Google об этом знает. Поэтому для IPv6-прокси порог входа в бан ниже в разы.

Практика показывает: чистый /64 от какого-нибудь хостинга выдерживает 200-400 запросов до первого 429. Если использовать /48 с равномерным распределением по /64, лимит растёт до 2000-3000. Дальше — только ротация подсетей.

Как Google детектит IPv6-прокси

Тут работает несколько механизмов одновременно. Первый — ASN. Google смотрит на номер автономной системы. Если это Hetzner, OVH, DigitalOcean — флаг сразу. Жилые IPv6 от Comcast или Deutsche Telekom проходят куда легче.

Второй — rDNS. Если PTR-запись выглядит как `host-123-45.isp.net`, это одно. Если `vps-12345.cloudprovider.com` — совсем другое. Google читает PTR и делает выводы.

Третий — поведенческий анализ. С одного /64 адреса приходит 500 запросов в минуту с одинаковыми User-Agent и без cookies. Это палево. Настоящий пользователь так не делает.

Четвёртый — TLS fingerprint. JA3/JA4 хеш от Python requests отличается от Chrome. Google это видит на уровне ClientHello. Даже если IP чистый, а fingerprint палевный — получите капчу.

Настройка прокси-пула на IPv6

Правильная схема — это не один прокси, а пул с ротацией. Минимум 50-100 подсетей /64. Каждая подсеть даёт 2^64 адресов, но использовать все не нужно — Google запомнит паттерн.

Вот пример на Python с ротацией через SOCKS5:

```python

import requests

import random

from itertools import cycle

PROXIES = [

"socks5://user:pass@[2a01:4f8:1c1c:1234::1]:1080",

"socks5://user:pass@[2a01:4f8:1c1c:5678::1]:1080",

"socks5://user:pass@[2a01:4f8:1c1c:9abc::1]:1080",

]

proxy_pool = cycle(PROXIES)

def google_search(query):

proxy = next(proxy_pool)

headers = {

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

"AppleWebKit/537.36 (KHTML, like Gecko) "

"Chrome/120.0.0.0 Safari/537.36",

"Accept-Language": "en-US,en;q=0.9",

}

try:

r = requests.get(

"https://www.google.com/search",

params={"q": query, "num": 20},

proxies={"https": proxy},

headers=headers,

timeout=15,

)

return r.status_code, len(r.text)

except requests.RequestException as e:

return None, str(e)

```

Ключевой момент — таймауты. IPv6 через SOCKS5 иногда даёт задержки 300-800 мс против 80-150 мс на IPv4. Это нормально, но нужно учитывать в rate limit.

Ротация: подсети, адреса, сессии

Ротация бывает трёх уровней. Первый — по адресам внутри одной /64. Это почти бесполезно против Google, потому что он видит /64 как единицу. Второй — по /64 внутри /48. Вот это работает. Третий — по ASN, самый надёжный, но требует пула от разных провайдеров.

Схема ротации зависит от задачи. Если парсите 10 000 запросов в сутки — хватит 20-30 /64. Если 500 000 — нужно 200+ /64 и минимум 5 разных ASN.

Сессии тоже важны. Google ставит cookies (NID, CONSENT, 1P_JAR). Если вы каждый запрос идёте с нового IP и без cookies — выглядите как бот. Если сохраняете cookies на 5-10 запросов с одного IP — выглядите как человек.

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

Разбор капчи: что реально работает

Капча от Google бывает трёх видов. Первый — простой чекбокс «I'm not a robot». Второй — выбор картинок. Третий — полностью заблокированная страница с `sorry/index`.

Первый вид обходится относительно легко. Достаточно правильного fingerprint браузера и чистого IP. Второй — сложнее, нужен либо сервис решения капчи (2captcha, Anti-Captcha), либо эмуляция реального браузера через Playwright.

Третий вид — это уже бан. Тут ничего не поможет, кроме смены IP и паузы на 24-48 часов.

Вот пример с Playwright и stealth-плагином:

```python

from playwright.sync_api import sync_playwright

def search_with_browser(query, proxy):

with sync_playwright() as p:

browser = p.chromium.launch(

headless=True,

proxy={"server": proxy},

args=[

"--disable-blink-features=AutomationControlled",

"--disable-features=IsolateOrigins,site-per-process",

],

)

context = browser.new_context(

user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "

"AppleWebKit/537.36 (KHTML, like Gecko) "

"Chrome/120.0.0.0 Safari/537.36",

viewport={"width": 1440, "height": 900},

locale="en-US",

)

page = context.new_page()

page.goto(f"https://www.google.com/search?q={query}")

page.wait_for_timeout(2000)

results = page.query_selector_all("div.g")

data = [r.inner_text() for r in results]

browser.close()

return data

```

Playwright решает проблему TLS fingerprint, но жрёт в 10-20 раз больше ресурсов. На одном ядре — 3-5 параллельных сессий, не больше.

Кейс: парсинг выдачи для SEO-агентства

Задача — собирать топ-100 по 5000 запросов ежедневно. Клиент — SEO-агентство, нужно мониторить позиции своего сайта и конкурентов.

Первый запуск на одном /64 от Hetzner: 247 запросов, потом 429. Пауза 60 секунд — снова 429. Через час — бан на сутки.

Причина — Google увидел один /64 с 247 запросами за 12 минут без cookies и с одинаковым User-Agent. Плюс JA3 от Python requests.

Решение: пул из 40 /64 от трёх разных ASN (Hetzner, OVH, мелкий региональный провайдер). Ротация по /64 каждые 30 запросов. Cookies сохраняются на 10 запросов в рамках одного IP. User-Agent меняется из пула в 50 штук. Задержка между запросами — 3-7 секунд рандомно.

Результат: 5000 запросов за 6 часов, 0 капч, 12 временных 429 (все прошли после паузы 30 сек). Стоимость — 40 IPv6-адресов от хостера, около \$2 в месяц.

Кейс: обход sorry/index при интенсивном парсинге

Другой клиент — сервис мониторинга цен. Нужно 200 000 запросов в сутки к Google Shopping.

Начали с 100 /64, ротация каждые 10 запросов. Через 3 часа — массовые sorry/index. Google забанил 60% подсетей.

Причина — интенсивность. 200 000 / 24 = 8333 запросов в час. Даже с 100 подсетями это 83 запроса в час на подсеть. Для Google это подозрительно много с одного /64.

Решение — увеличили пул до 400 /64, снизили интенсивность до 5000 запросов в час, добавили Playwright для 10% запросов (когда Google показывает капчу). Плюс проксирование через residential IPv6 от мобильных операторов для самых сложных запросов.

Результат: 200 000 запросов за 40 часов, sorry/index на 3% запросов, из них 90% решены через Playwright + 2captcha. Стоимость выросла до \$80 в месяц.

Кейс: когда IPv6 хуже IPv4

Бывает и наоборот. Один клиент парсил Google для узкого региона — Германия, баварский диалект запросов. Использовал IPv6 от немецкого хостера.

Google отдавал выдачу на английском, хотя `hl=de&gl=de` в параметрах. Причина — GeoIP для IPv6 часто менее точен, чем для IPv4. Хостер зарегистрирован в Берлине, но блок /64 мог числиться за Франкфуртом или даже Амстердамом.

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

Сравнение подходов

| Подход | Скорость | Стоимость/мес | Капча, % | Когда использовать |

|--------|----------|---------------|----------|-------------------|

| Один IPv6 /64 | 500 req/h | \$1 | 80+ | Тесты, малые объёмы |

| Пул 40 /64 | 3000 req/h | \$2-5 | 5-10 | SEO, средние объёмы |

| Пул 400 /64 | 5000 req/h | \$20-40 | 3-5 | Мониторинг цен |

| Residential IPv4 | 2000 req/h | \$100+ | 1-2 | Геозависимые задачи |

| Мобильные IPv6 | 1000 req/h | \$150+ | <1 | Сложные случаи |

Цифры приблизительные, зависят от ASN, гео и поведения клиента.

Rate limiting: сколько не жалко

Универсального числа нет. Но есть эмпирические границы. С одного /64 — не больше 10-15 запросов в минуту. С одного /48 — 50-80 в минуту. С одного ASN — 200-300 в минуту.

Задержки между запросами: минимум 2 секунды, оптимально 4-8. Рандомизация обязательна, иначе паттерн виден. Google анализирует интервалы и легко ловит равномерные 5.000 секунд.

Cookies — обязательно. Хотя бы CONSENT и NID. Без них Google считает каждый запрос первым визитом, что подозрительно.

Заголовки, которые нельзя забыть

Accept-Language должен совпадать с GeoIP. Если IP немецкий, а Accept-Language `en-US` — палево. Accept-Encoding — обязательно gzip, br. Без этого Google отдаёт обрезанную выдачу.

Sec-Fetch-* заголовки — Chrome их отправляет с версии 76. Если их нет, fingerprint палевный. Referer — для поиска обычно пустой или `https://www.google.com/`.

Connection: keep-alive — да, но с ротацией IP это работает только внутри одной сессии.

Мониторинг и что смотреть

Смотреть нужно на три метрики. Первая — доля 429 в общем потоке. Больше 5% — проблема с rate limit. Вторая — доля капч. Больше 10% — проблема с fingerprint или IP. Третья — доля sorry/index. Больше 1% — пора менять пул.

Логировать нужно IP, ASN, время, статус, наличие капчи. Без этого невозможно понять, какие подсети работают, а какие сожжены.

Пауза после бана — минимум 24 часа для /64, 6-12 часов для /48. Меньше — Google запомнит и продлит бан.

Итог

IPv6 для Google — палка о двух концах. С одной стороны, адресов много и они дешёвые. С другой — Google режет подсети целиком, и один /64 выгорает за пару часов.

Рабочая схема — пул из 40+ /64 от разных ASN, ротация по подсетям, cookies на сессию, реалистичные заголовки, задержки 4-8 секунд. С этим можно парсить 3000-5000 запросов в час без серьёзных проблем.

Если объёмы больше — либо расширять пул, либо добавлять residential IPv4, либо использовать Playwright для сложных случаев. Универсального рецепта нет, каждый случай требует подстройки под конкретный ASN, гео и паттерн запросов.