Cómo funciona la puntuación de reCAPTCHA v3: guía técnica para automatización legítima

Si alguna vez has enviado una solicitud legítima a una API protegida por reCAPTCHA v3 y has recibido un token que el servidor rechaza con un score de 0.1, ya conoces el problema central: cómo funciona la puntuación de reCAPTCHA v3 no es obvio, y el motor de Google no publica su modelo exacto. Este artículo desglosa el scoring continuo de 0.0 a 1.0, las señales que Google fusiona, por qué la reputación del IP puede colapsar tu puntuación por sí sola, y cómo la automatización legítima —pruebas QA, investigación de seguridad autorizada, accesibilidad— puede obtener puntuaciones que superan los umbrales del sitio.

Cómo funciona la puntuación de reCAPTCHA v3: el modelo de scoring continuo

A diferencia de reCAPTCHA v2, que presenta un desafío visual explícito (selección de imágenes, casilla "No soy un robot"), reCAPTCHA v3 es invisible: no muestra ningún widget al usuario. En su lugar, el sitio web invoca grecaptcha.execute(siteKey, {action: 'login'}) en JavaScript, y la API devuelve un token opaco que el servidor backend envía a https://www.google.com/recaptcha/api/siteverify para su verificación. La respuesta incluye un campo score entre 0.0 y 1.0, donde valores más altos indican mayor confianza en que el tráfico es humano.

Google agrupa internamente las puntuaciones en aproximadamente once buckets discretos (0.1, 0.2, 0.3, …, 0.9, 1.0), aunque la API devuelve el valor continuo. Los umbrales de decisión los define cada sitio, pero los patrones comunes son:

Rango de score	Decisión típica	Ejemplo de acción del sitio
< 0.3	Bloquear	Rechazar la solicitud, devolver 403
0.3 – 0.6	Desafiar	Mostrar reCAPTCHA v2 o verificación por email
> 0.6	Permitir	Procesar la acción normalmente

El campo action es crítico: Google espera que el action declarado en grecaptcha.execute() coincida con el action devuelto en la respuesta de siteverify. Si no coinciden, el token debe rechazarse. Esto evita que un token obtenido para la acción login se reutilice en una acción register.

La documentación oficial de Google reCAPTCHA v3 confirma que el score se basa en interacciones del usuario y datos del entorno, pero no publica los pesos exactos de cada señal. La comunidad de investigación ha invertido años en ingeniería inversa del modelo, y los hallazgos convergen en varias categorías de señales.

Las señales que Google fusiona para calcular el score

El motor de puntuación de reCAPTCHA v3 fusiona múltiples categorías de señales. No se trata de una regla simple —es un modelo de machine learning que pondera decenas de features. Las categorías principales son:

1. Telemetría de interacción con la página

reCAPTCHA v3 inyecta un script que registra eventos de mouse, scroll y teclado: velocidad del cursor, trayectorias, intervalos entre pulsaciones de teclas, tiempo entre mousedown y mouseup, distancia de scroll por evento, y tiempo total en la página antes de invocar execute(). Un humano típico mueve el ratón con micro-correcciones y pausas irregulares; un bot que no simula estos eventos genera un patrón nulo o perfectamente uniforme que el modelo detecta fácilmente.

2. Grafo de cookies de Google

Si el navegador tiene cookies de Google activas (SID, HSID, NID de google.com, youtube.com, etc.), reCAPTCHA puede correlacionar la sesión con el historial de actividad de Google del usuario. Una cuenta de Google con años de actividad legítima contribuye positivamente al score. Un navegador limpio sin cookies de Google recibe un score base más bajo, porque el modelo no tiene historial de confianza al que aferrarse.

3. Características del navegador y fingerprints TLS

reCAPTCHA examina el User-Agent, el conjunto de headers HTTP, las APIs de JavaScript disponibles (navigator.webdriver, navigator.plugins, navigator.languages), y características del canvas/WebGL. A nivel de red, Google también puede inspeccionar el handshake TLS del navegador. El fingerprint JA3/JA4 —que codifica el orden de cipher suites y extensiones TLS— distingue entre navegadores reales (Chrome, Firefox, Safari) y bibliotecas HTTP como Python requests o Go's net/http, cuyos handshakes TLS no coinciden con ningún navegador conocido.

Por ejemplo, Chrome 120 en Windows presenta un JA3 que comienza con 771,4865-4866-4867-49195-49199-..., mientras que requests con urllib3 produce un handshake completamente diferente. Cualquier discrepancia entre el User-Agent declarado y el JA3 observado es una señal de automatización.

4. Reputación del IP

Aquí está el factor que más afecta a los usuarios de proxies. Google mantiene una base de reputación de IPs que clasifica direcciones por tipo (residencial, datacenter, móvil) y por historial de actividad maliciosa. Los IPs de datacenters —rangos ASN de AWS, Google Cloud, Azure, DigitalOcean, OVH— reciben sistemáticamente puntuaciones más bajas, independientemente del comportamiento del navegador. Un navegador real con cookies de Google y telemetría humana perfecta puede recibir un score de 0.3 o menor si la solicitud proviene de un IP de datacenter.

Esto se debe a que el modelo aprendió que el tráfico automatizado malicioso proviene predominantemente de datacenters. La señal del IP actúa como un multiplicador negativo: si el IP es sospechoso, el score base se reduce drásticamente, y las señales positivas del navegador solo pueden compensar parcialmente.

Por qué los proxies datacenter colapsan el score y los residenciales son necesarios

La conclusión práctica es directa: para obtener una puntuación reCAPTCHA v3 que supere el umbral de aprobación de un sitio (típicamente > 0.6), necesitas que el componente de reputación del IP sea positivo. Los IPs residenciales —asignados por ISPs a hogares reales— tienen la mejor reputación porque el modelo los asocia con tráfico humano legítimo. Los IPs móviles (operadores celulares) también funcionan bien. Los IPs datacenter, por el contrario, arrastran el score hacia abajo de forma casi automática.

En pruebas empíricas de la comunidad, la diferencia es dramática: la misma sesión de navegador con las mismas cookies puede pasar de un score de 0.1 sobre un IP de AWS a un score de 0.7 o 0.8 sobre un IP residencial limpio. Este delta de 0.6 puntos es la diferencia entre ser bloqueado y ser permitido.

Es importante destacar que un proxy residencial no es un bypass mágico. Si el navegador no simula interacción humana, si el JA3 no coincide con un navegador real, o si las cookies de Google están ausentes, incluso un IP residencial puede devolver un score bajo. El proxy residencial es una condición necesaria pero no suficiente para obtener un score aprobatorio.

Verificación del token en el servidor: siteverify, action y hostname

Cuando el frontend invoca grecaptcha.execute(), obtiene un token que debe enviarse al backend. El backend entonces realiza una petición POST a https://www.google.com/recaptcha/api/siteverify con tres parámetros:

• secret: la clave secreta del sitio (no la pública).
• response: el token devuelto por execute().
• remoteip (opcional): la IP del cliente.

La respuesta JSON incluye:

{
  "success": true,
  "score": 0.7,
  "action": "login",
  "challenge_ts": "2026-01-15T12:00:00Z",
  "hostname": "example.com",
  "error-codes": []
}

El backend debe validar tres cosas más allá del score:

1. El score supera el umbral definido para esa acción (p. ej., > 0.6 para login, > 0.8 para transferencias bancarias).
2. El action coincide con el esperado. Si el frontend solicitó execute con {action: 'login'}, la respuesta debe tener action: "login". Si no coincide, rechazar.
3. El hostname coincide con el dominio esperado. Si el token se generó en evil.com pero el backend espera example.com, rechazar.

Los tokens tienen una validez limitada —típicamente 2 minutos— y son de un solo uso. Un segundo envío del mismo token a siteverify devuelve success: false con el error timeout-or-duplicate.

Enfoque legítimo con ProxyHat: navegador real + IP residencial + interacción humana

Para automatización legítima —QA de flujos de registro, pruebas de accesibilidad, investigación de seguridad autorizada— el enfoque que produce puntuaciones aprobatorias combina cuatro elementos:

1. Navegador real o instrumentado con stealth: Playwright o Puppeteer con un plugin que oculte navigator.webdriver, simule plugins y mantenga un JA3 coherente con el User-Agent declarado.
2. IP residencial: un proxy residencial limpio que no esté en listas negras.
3. Interacción humana simulada: movimientos de ratón con curvas de Bézier, pausas aleatorias, scroll gradual y tiempo de permanencia en la página antes de ejecutar execute().
4. Sesión de navegador persistente: mantener cookies entre sesiones para que el grafo de cookies de Google pueda construirse con el tiempo.

Aquí hay un ejemplo en Python usando Playwright a través de un proxy residencial de ProxyHat:

from playwright.sync_api import sync_playwright
import time, random

PROXY = "http://user-country-US:PASSWORD@gate.proxyhat.com:8080"

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,
        proxy={"server": PROXY}
    )
    context = browser.new_context(
        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",
        viewport={"width": 1920, "height": 1080},
        locale="en-US"
    )
    page = context.new_page()
    page.goto("https://example.com/login")

    # Simular interacción humana: mover ratón, hacer scroll, esperar
    page.mouse.move(500, 300, steps=20)
    time.sleep(random.uniform(1.5, 3.0))
    page.mouse.move(800, 500, steps=15)
    page.evaluate("window.scrollBy(0, 200)")
    time.sleep(random.uniform(0.8, 1.5))

    # Ejecutar reCAPTCHA v3 para la acción 'login'
    token = page.evaluate("""
        async () => {
            await new Promise(r => grecaptcha.ready(r));
            const token = await grecaptcha.execute(
                'SITE_KEY', {action: 'login'}
            );
            return token;
        }
    """)

    print(f"Token obtenido: {token[:40]}...")
    # Enviar token al backend para siteverify
    browser.close()

En este ejemplo, el proxy se configura con user-country-US en el nombre de usuario, lo que hace que ProxyHat asigne un IP residencial en Estados Unidos. El puerto 8080 es el gateway HTTP estándar de ProxyHat. Para SOCKS5, usarías socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080.

Para mantener la misma IP entre peticiones (sesión sticky), añade un identificador de sesión:

PROXY = "http://user-country-US-session-myqa01:PASSWORD@gate.proxyhat.com:8080"

Esto asegura que todas las peticiones de una sesión provengan del mismo IP residencial, permitiendo que las cookies de Google se acumulen de forma coherente.

Comparación: datacenter vs residencial vs móvil

Tipo de IP	Score reCAPTCHA v3 típico	Coste relativo	Casos de uso
Datacenter	0.1 – 0.3	Bajo	Scraping sin reCAPTCHA, APIs sin anti-bot
Residencial	0.6 – 0.9	Medio-alto	QA con reCAPTCHA, SERP tracking, e-commerce
Móvil	0.7 – 0.9	Alto	Apps móviles, social media automation

Errores comunes y casos límite

Usar headless puro sin stealth

Chromium en modo headless=True expone navigator.webdriver = true y tiene diferencias en el fingerprint del canvas respecto al modo headed. reCAPTCHA v3 detecta esto y reduce el score. Solución: usar headless=False en entornos con display (o Xvfb en servidores Linux) o aplicar un plugin de stealth que parchee las señales más obvias.

No respetar el campo action

Si el frontend usa action: 'submit' pero el backend valida esperando action: 'login', el token se rechaza. Este error es común al copiar código entre páginas sin actualizar el action esperado en el backend.

Reutilizar tokens

Los tokens son de un solo uso y expiran en ~2 minutos. Si tu automatización obtiene un token y lo reenvía en una segunda petición, siteverify devuelve timeout-or-duplicate. Cada acción requiere un execute() nuevo.

Score 0.3 persistente pese a IP residencial

Si obtienes un recaptcha score 0.3 incluso con IP residencial, las causas más probables son: (1) el navegador no tiene cookies de Google y el grafo de confianza está vacío, (2) el JA3 no coincide con el User-Agent, (3) no hay telemetría de interacción antes de execute(), o (4) el IP residencial específico está temporalmente flaggeado. La solución es rotar a otro IP residencial y construir la sesión gradualmente.

Configuración específica con ProxyHat

Para integrar ProxyHat en tu pipeline de automatización legítima, la configuración es directa. El gateway HTTP está en gate.proxyhat.com:8080 y el SOCKS5 en gate.proxyhat.com:1080. Las flags de geo-targeting y sesión van en el nombre de usuario:

• Geo-targeting por país: user-country-US:pass@gate.proxyhat.com:8080
• Geo-targeting por ciudad: user-country-DE-city-berlin:pass@gate.proxyhat.com:8080
• Sesión sticky: user-session-abc123:pass@gate.proxyhat.com:8080

Para casos de uso de web scraping y SERP tracking donde reCAPTCHA v3 puede aparecer, consulta nuestra guía de web scraping y la página de SERP tracking. Los detalles de precios y planes están en /pricing, y la lista de ubicaciones disponibles en /locations. Para la documentación técnica completa, visita docs.proxyhat.com.

Cuándo es apropiado este enfoque — y cuándo no

Este enfoque es legítimo en estos contextos:

• QA automatizado: probar que tu propio flujo de registro/login funciona correctamente con reCAPTCHA v3 habilitado.
• Pruebas de accesibilidad: verificar que usuarios con tecnologías de asistencia pueden completar flujos protegidos por reCAPTCHA.
• Investigación de seguridad autorizada: pentesting con autorización explícita del propietario del sistema.
• Monitoreo de SERP y precios: recopilar datos públicos de motores de búsqueda y e-commerce de forma respetuosa.

No es apropiado para: crear cuentas masivas, evadir bloqueos de fraude, spam, credential stuffing, o cualquier actividad que viole los términos de servicio del sitio objetivo.

Aviso legal: En EE.UU., el Computer Fraud and Abuse Act (CFAA) penaliza el acceso no autorizado a sistemas protegidos. En la UE, el GDPR regula el tratamiento de datos personales. Automatizar el acceso a un sitio sin autorización, o de forma que viole sus términos de servicio, puede constituir una violación legal. Usa estas técnicas únicamente en sistemas que posees o donde tienes autorización explícita por escrito.

Conclusiones clave

Preguntas frecuentes

¿Qué es la puntuación de reCAPTCHA v3 y cómo funciona?

reCAPTCHA v3 devuelve un score continuo entre 0.0 y 1.0 por cada acción (login, register, etc.) invocada vía grecaptcha.execute(). El score refleja la probabilidad de que el tráfico sea humano, basándose en telemetría de interacción, cookies de Google, fingerprint del navegador y reputación del IP. Los sitios definen umbrales: típicamente bloquean scores < 0.3, desafían entre 0.3 y 0.6, y permiten > 0.6.

¿Por qué la puntuación de reCAPTCHA v3 importa para usuarios de proxies?

Porque la reputación del IP es una señal de peso en el modelo. Los IPs de datacenter (AWS, Azure, OVH) reciben sistemáticamente scores bajos (0.1–0.3) sin importar el comportamiento del navegador. Los proxies residenciales asignan IPs de ISPs reales con buena reputación, lo que permite que las señales positivas del navegador eleven el score por encima del umbral de aprobación.

¿Qué tipo de proxy funciona mejor para reCAPTCHA v3?

Los proxies residenciales ofrecen los mejores resultados porque asignan IPs de hogares reales con historial de tráfico legítimo. Los proxies móviles también funcionan bien. Los proxies datacenter, en cambio, colapsan el score por la mala reputación asociada a sus rangos ASN. Para sesiones que necesitan cookies persistentes, usa sesiones sticky en ProxyHat con user-session-ID en el nombre de usuario.

¿Cómo evitas bloqueos al implementar automatización con reCAPTCHA v3?

Combina cuatro elementos: (1) navegador real o con stealth que oculte navigator.webdriver y mantenga un JA3 coherente, (2) IP residencial limpia vía ProxyHat con geo-targeting, (3) interacción humana simulada con movimientos de ratón y scroll antes de execute(), y (4) sesión persistente con cookies de Google acumuladas. Evita headless puro, no reutilices tokens y respeta el campo action en el backend.

¿Es legal usar proxies para superar reCAPTCHA v3?

Depende del contexto. Es legal cuando automatizas acceso a sistemas que posees o donde tienes autorización explícita (QA, pruebas de accesibilidad, pentesting autorizado). Usar proxies para evadir reCAPTCHA en sitios de terceros sin autorización puede violar el CFAA en EE.UU. y el GDPR en la UE si se procesan datos personales. Consulta siempre los términos de servicio del sitio objetivo y obtén autorización por escrito.