Если вы когда-либо запускали легитимный автотест против формы входа и получали тихий отказ — форма просто не отправляется, а в логах пусто — вы столкнулись с reCAPTCHA v3. В отличие от v2 с его «выберите светофоры», v3 полностью невидим для пользователя и возвращает серверу числовой риск-скор. Понимание того, как работает reCAPTCHA v3, критично для QA-инженеров, исследователей антибот-систем и команд автоматизации, которые хотят, чтобы их легитимный трафик доходил до целевой страницы, а не отбрасывался на уровне серверной валидации.
Как работает reCAPTCHA v3: модель скоринга 0.0–1.0
reCAPTCHA v3 — это полностью невидимая система оценки рисков. Вместо визуальной задачи она возвращает непрерывную оценку от 0.0 до 1.0 для каждого действия пользователя, где 0.0 означает «явный бот», а 1.0 — «явный человек». Оценка возвращается клиенту через grecaptcha.execute(), а затем токен отправляется на ваш сервер и проверяется через Google siteverify API.
Каждый вызов grecaptcha.execute(siteKey, {action: 'login'}) привязан к конкретному действию — login, signup, checkout. Это действие становится частью токена и должно совпадать при серверной проверке. Без привязки к действию Google не сможет корректно калибровать скор.
На практике Google документирует одиннадцать бакетов скоринга, но реальные пороги определяет каждый сайт индивидуально. Типичная конфигурация выглядит так:
| Диапазон оценки | Действие сайта | Типичный сценарий |
|---|---|---|
| 0.0–0.3 | Блокировка | Подозрительный трафик, ботнет, datacenter IP |
| 0.3–0.6 | Вызов (challenge) | Вторичный фактор, email-верификация, v2-челлендж |
| 0.6–1.0 | Пропуск | Нормальный пользовательский трафик |
Порог оценки reCAPTCHA 0.3 — это наиболее часто встречающаяся граница между «заблокировать» и «попросить дополнительное подтверждение». Многие e-commerce и финансовые платформы ставят порог блокировки на 0.3, а порог вызова — на 0.5. Если ваш легитимный автотест получает оценку 0.2, вы не пройдёте, даже если поведение идеально имитирует человека.
Сигналы, которые Google объединяет в оценку
Google не раскрывает точную формулу, но из официальной документации reCAPTCHA v3 и исследований антибот-сообщества известно, что система объединяет десятки сигналов в единый скор. Вот основные категории:
1. Поведенческая телеметрия
reCAPTCHA v3 собирает данные о взаимодействии с страницей: тайминги движений мыши, паттерны скроллинга, интервалы между нажатиями клавиш, время наведения на элементы. Эти сигналы формируют «поведенческий отпечаток» — если движения слишком линейные или слишком быстрые, скор падает.
2. Граф Google-куки
Если пользователь ранее взаимодействовал с другими сайтами Google (поиск, YouTube, Gmail), у него есть ___gads и NID куки. Этот граф связывает браузер с историей доверенных сессий. Новая сессия без истории Google-взаимодействий получает более низкий стартовый скор.
3. Характеристики браузера
Система анализирует отпечаток браузера: TLS-фингерпринт (JA3/JA4), порядок шифров, User-Agent, navigator properties, canvas fingerprint, WebGL-рендеринг. Несоответствия между заявленным User-Agent и реальными характеристиками TLS или JS-окружения — сильный сигнал бота. Например, если User-Agent заявляет Chrome на Windows, но JA3-отпечаток соответствует стандартному Python-requests, Google это видит.
Конкретные TLS-сигналы, которые отслеживаются: порядок шифров в ClientHello, расширения TLS, ALPN-протоколы, формат GREASE. Библиотеки вроде requests или curl имеют характерные JA3-хэши, отличные от реальных браузеров. MDN документация по User-Agent описывает, как браузеры формируют эту строку, но антибот-системы смотрят глубже.
4. IP-репутация
Это критический компонент, который часто недооценивают. Google ведёт репутационную базу IP-адресов. Дата-центровые диапазоны (AWS, DigitalOcean, OVH, Hetzner) почти всегда получают низкий скор, независимо от поведения. Торговые сети, VPN-провайдеры и известные прокси-диапазоны также флагируются. Резидентные IP-адреса — реальные ISP-выделенные адреса домашних пользователей — получают наивысший базовый скор.
Почему datacenter IP обрушивают оценку независимо от поведения
Это ключевой инсайт для команд автоматизации: вы можете идеально сэмулировать движения мыши, использовать реальный Chrome с корректным JA3-отпечатком, иметь валидные Google-куки — и всё равно получить оценку 0.1, если ваш IP принадлежит диапазону AWS. Причина проста: Google классифицирует дата-центровые IP как «вероятно автоматизированные» по умолчанию.
В практических тестах автотесты, запущенные с datacenter-прокси, стабильно получают оценки в диапазоне 0.1–0.2, тогда как те же тесты с residential-прокри в той же стране получают 0.5–0.8. Разница в 0.3–0.6 баллов — это разница между блокировкой и пропуском.
Вот почему обход reCAPTCHA v3 в контексте легитимной автоматизации — это не про взлом системы, а про устранение ложноположительных сигналов. Если ваш трафик легитимен (авторизованное тестирование, QA-автоматизация, accessibility-проверки), вы заслуживаете корректного скора. Использование residential-прокри убирает один из самых весомых негативных сигналов.
Серверная проверка токена: siteverify и соответствие action/hostname
После того как клиент получает токен через grecaptcha.execute(), этот токен отправляется на ваш сервер. Сервер вызывает Google siteverify API:
POST https://www.google.com/recaptcha/api/siteverify
secret=YOUR_SECRET_KEY&token=TOKEN_FROM_CLIENTGoogle отвечает JSON с полями:
success— boolean, валиден ли токенscore— float от 0.0 до 1.0action— строка действия, указанная при execute()hostname— домен, с которого был сгенерирован токенerror-codes— массив кодов ошибок
Две критические проверки на стороне сервера:
- Соответствие action: значение
actionиз ответа должно точно совпадать с тем, что вы ожидаете. Если вы выполнялиexecuteс{action: 'login'}, а в ответеaction: 'signup', токен невалиден. - Соответствие hostname:
hostnameдолжен совпадать с вашим доменом (или быть из списка разрешённых). Это предотвращает повторное использование токенов с других сайтов.
Токены одноразовые и действительны примерно 2 минуты. Если ваш автотест задерживается между получением токена и отправкой формы, токен может истечь, и siteverify вернёт timeout-or-duplicate.
Легитимный подход с ProxyHat residential-прокри
Для авторизованного тестирования и QA-автоматизации нужен подход, который устраняет ложноположительные сигналы, не пытаясь «обмануть» систему. Вот практическая конфигурация:
Компоненты
- Браузер: реальный Chromium/Chrome через Playwright или Puppeteer (не headless-режим — headless детектируется)
- Прокси: ProxyHat residential с geo-таргетингом на страну целевого сайта
- Поведение: реалистичные задержки, движения мыши, скроллинг перед взаимодействием с формой
- Куки: предварительный прогон через Google-сервисы для создания доверительной истории (где этично и применимо)
Python-пример с Playwright и ProxyHat
from playwright.sync_api import sync_playwright
import time
import random
PROXY = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US",
"password": "YOUR_PASSWORD"
}
SITE_URL = "https://example.com/login"
RECAPTCHA_SITE_KEY = "your-site-key"
def human_delay(min_s=0.5, max_s=2.0):
time.sleep(random.uniform(min_s, max_s))
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False,
proxy=PROXY,
args=[
"--disable-blink-features=AutomationControlled",
"--no-sandbox"
]
)
context = browser.new_context(
viewport={"width": 1920, "height": 1080},
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/121.0.0.0 Safari/537.36",
locale="en-US"
)
page = context.new_page()
# Навигация с реалистичной задержкой
page.goto(SITE_URL)
human_delay(2, 4)
# Имитация человеческого взаимодействия
page.mouse.move(500, 300)
human_delay(0.5, 1.5)
page.mouse.move(700, 450)
human_delay(0.3, 0.8)
page.mouse.wheel(0, 200)
human_delay(1, 2)
# Заполнение формы
page.fill("input[name=email]", "test@example.com")
human_delay(0.5, 1.0)
page.fill("input[name=password]", "testpass123")
human_delay(0.8, 1.5)
# Выполнение reCAPTCHA v3
token = page.evaluate(f"""
async () => {{
await new Promise(r => grecaptcha.ready(r));
return await grecaptcha.execute(
'{RECAPTCHA_SITE_KEY}',
{{action: 'login'}}
);
}}
""")
print(f"Token received: {token[:20]}...")
# Отправка токена на сервер
# Сервер вызовет siteverify для проверки
page.click("button[type=submit]")
human_delay(2, 4)
browser.close()Конфигурация прокри ProxyHat
ProxyHat residential-прокри используют формат аутентификации с параметрами в username. Для geo-таргетинга на США:
# HTTP
http://user-country-US:pass@gate.proxyhat.com:8080
# SOCKS5
socks5://user-country-US:pass@gate.proxyhat.com:1080
# Sticky-сессия для сохранения IP между запросами
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080
# Городской таргетинг
http://user-country-US-city-newyork:pass@gate.proxyhat.com:8080Sticky-сессии важны для reCAPTCHA v3: если IP меняется между загрузкой страницы и выполнением grecaptcha.execute(), Google видит несоответствие и снижает скор. Используйте session-ID для сохранения одного IP на протяжении всей сессии теста.
Подробнее о доступных локациях и конфигурации — на странице локаций ProxyHat и в официальной документации.
Типичные ошибки и краевые случаи
1. Headless-браузер без стелс-настроек
Стандартный headless Chrome детектируется по множеству сигналов: navigator.webdriver === true, отсутствие WebGL-рендерера, характерные размеры окна. Решение: используйте headless=False или применяйте стелс-плагины вроде playwright-stealth.
2. Несоответствие JA3-отпечатка и User-Agent
Если вы используете Python requests с заголовком Chrome User-Agent, JA3-отпечаток всё равно выдаёт Python. reCAPTCHA v3 может не проверять JA3 напрямую, но Google использует комплексный отпечаток браузера, включающий TLS-характеристики. Решение: используйте реальный браузер через Playwright/Puppeteer.
3. Слишком быстрые взаимодействия
Заполнение формы за 50мс — явный сигнал бота. Добавляйте случайные задержки 200–800мс между полями, движения мыши между действиями.
4. Истёкшие токены
Токен действителен ~2 минуты. Если ваш автотест делает много шагов между execute() и отправкой, токен может истечь. Выполняйте grecaptcha.execute() как можно ближе к моменту отправки формы.
5. Несоответствие action
Если на сайте несколько форм с разными action, убедитесь, что вы используете правильный. Серверная проверка отклонит токен с неверным action.
Где это уместно — и где нет
Этот подход предназначен исключительно для легитимных сценариев:
- Авторизованное тестирование: QA-команды, тестирующие собственные формы с reCAPTCHA v3
- Accessibility-автоматизация: проверка доступности форм для assistive-технологий
- Исследования антибот-систем: академические и промышленные исследования в области безопасности
- Нагрузочное тестирование: валидация производительности форм под реалистичной нагрузкой
Недопустимые сценарии: массовая регистрация аккаунтов, credential stuffing, fraud-автоматизация, обход защиты на сайтах, где у вас нет явного разрешения. В США такие действия могут нарушать Computer Fraud and Abuse Act (CFAA), а в ЕС — GDPR, особенно при обработке персональных данных. reCAPTCHA v3 — это защитный механизм, и его обход без авторизации — это нарушение, а не «техническая задача».
Важно: Даже при легитимном тестировании согласовывайте с владельцем сайта. Тестирование на продакшн-формах без разрешения может нарушать ToS и создавать юридические риски.
Для сценариев веб-скрапинга, где reCAPTCHA v3 защищает целевые страницы, residential-прокри ProxyHat помогают поддерживать корректный скор. Подробнее — в материалах про веб-скрапинг и SERP-трекинг. Тарифы и доступные пакеты — на странице цен ProxyHat.
Ключевые выводы
- reCAPTCHA v3 возвращает скор 0.0–1.0 — типичные пороги: блокировка <0.3, вызов 0.3–0.6, пропуск >0.6. Порог 0.3 — наиболее частая граница блокировки.
- IP-репутация — критический сигнал: datacenter IP почти всегда обрушивают скор до 0.1–0.2, residential IP дают базовый скор 0.5–0.8.
- Серверная проверка требует соответствия action и hostname — несоответствие = невалидный токен.
- Токены одноразовые и действуют ~2 минуты — выполняйте
grecaptcha.execute()максимально близко к отправке формы. - Используйте real browser + residential proxy + human-like behavior — это три обязательных компонента для легитимного прохождения.
- Sticky-сессии обязательны — смена IP между загрузкой страницы и execute() снижает скор.
- Только авторизованное использование — CFAA и GDPR применяются к несанкционированному обходу.
FAQ
Что такое оценка reCAPTCHA v3 и как она работает?
Оценка reCAPTCHA v3 — это число от 0.0 до 1.0, возвращаемое Google для каждого действия пользователя через grecaptcha.execute(). Система анализирует поведенческую телеметрию, характеристики браузера, граф Google-куки и IP-репутацию, объединяя десятки сигналов в единый скор. Сайты используют этот скор для принятия решений: блокировка, вызов дополнительного подтверждения или пропуск. Оценка не видна пользователю — всё происходит в фоне.
Почему оценка reCAPTCHA v3 важна для пользователей прокси?
Потому что IP-репутация — один из самых весомых сигналов в скоринг-модели. Дата-центровые IP почти всегда получают низкий скор (0.1–0.2), что приводит к блокировке легитимного трафика. Residential-прокри с реальными ISP-адресами дают базовый скор 0.5–0.8, что позволяет легитимной автоматизации (QA, accessibility-тесты) проходить проверку. Без residential-прокри даже идеальное поведение браузера не компенсирует негативный IP-сигнал.
Какой тип прокси лучше всего подходит для reCAPTCHA v3?
Residential-прокри — безусловно лучший выбор. Они используют реальные IP-адреса ISP, которые Google классифицирует как пользовательские. Datacenter-прокри помечаются как автоматизированные и обрушивают скор. Mobile-прокри тоже работают хорошо, но residential обеспечивают оптимальный баланс стоимости и качества. Важно использовать sticky-сессии, чтобы IP не менялся между загрузкой страницы и выполнением grecaptcha.execute() — несоответствие IP снижает скор.
Как избежать блокировок при работе с reCAPTCHA v3?
Используйте комбинацию: реальный браузер (Playwright/Puppeteer в non-headless режиме), residential-прокри с geo-таргетингом, sticky-сессии для сохранения IP, реалистичные задержки и движения мыши. Выполняйте grecaptcha.execute() максимально близко к отправке формы, так как токен действует ~2 минуты. Убедитесь, что action и hostname совпадают при серверной проверке. И главное — используйте этот подход только для авторизованного тестирования, не для обхода защиты на чужих сайтах.
