Cómo funcionan la reputación IP y la puntuación de fraude (IPQualityScore) en 2026

Cuando un sitio moderno decide si te deja iniciar sesión, registrarte o pagar, ya no mira solo tu contraseña: consulta tu reputación IP. Servicios como IPQualityScore (IPQS) devuelven en milisegundos un score de fraude IP de 0 a 100 que resume la probabilidad de que tu dirección sea un proxy, VPN, bot o fuente de abuso. Comprender cómo funcionan la reputación IP y la puntuación de fraude (IPQualityScore) es lo que separa a un scraper que pasa del que recibe 403 en cada petición. Esta guía desmonta el modelo de scoring, las señales concretas que IPQS evalúa y por qué un proxy residencial de ProxyHat con ASN de ISP real es la única categoría que pasa de forma fiable donde una IP de datacenter falla.

Cómo se construye un score de fraude 0-100: el interior de IPQualityScore

IPQualityScore no es una lista negra estática. Es un pipeline que combina datos históricos, señales de red en tiempo real y modelos de machine learning. El resultado es un único número entre 0 (limpio) y 100 (fraude casi seguro), acompañado de flags booleanos como proxy, vpn, tor, recent_abuse y bot_status. La documentación oficial de IPQS describe estos campos en su Proxy Detection API, y el comportamiento real coincide con lo que cualquier ingeniero anti-fraud ve en producción.

1. Honeypots y trampas de abuso

IPQS mantiene una red de honeypots: formularios, páginas de login y endpoints falsos que solo una herramienta automatizada o un atacante visitaría. Cuando una IP envía una petición a uno de esos cebos, queda marcada como recent_abuse. Esta señal es la más cara del modelo: una IP que tocó un honeypot en los últimos 30 días arrastrará un score alto incluso si el resto de señales son neutras. Para un operador de proxies esto significa que un nodo «quemado» no se recupera solo con rotar; hay que sacarlo del pool.

2. Clasificación de ASN y rango

El Autonomous System Number (ASN) es la señal más predictiva. IPQS clasifica cada ASN como ISP (banda ancha residencial), hosting (AWS, DigitalOcean, OVH, Hetzner), mobile (operador celular) o business. Un ASN de hosting eleva el score de base por defecto. Dentro del ASN, IPQS evalúa el rango /24: si el 60% de las IPs del rango aparecen en listas negras, el score base sube para todas las direcciones de ese bloque. Es por eso que dos IPs «nuevas» del mismo datacenter pueden llegar ya con score 80 sin haber hecho nada.

3. Listas negras y feeds de amenazas

IPQS agrega más de 400 listas negras públicas y privadas (spam, botnet, proxy abierto, escáner de puertos). La presencia en una lista de bajo nivel suma poco; la presencia en una lista de botnet activa suma mucho. La ausencia total tampoco garantiza score bajo: una IP nueva de datacenter sin historial puede recibir score 75 solo por su ASN.

4. Machine learning sobre patrones de abuso escalable

IPQS entrena modelos sobre volumen de peticiones por IP, cadencia, distribución geográfica de destino y similitud con clusters de IPs que ya fueron flaggadas. El modelo detecta lo que llaman scalable abuse: patrones donde muchas IPs del mismo proveedor hacen lo mismo a la vez, típico de un botnet de proxies residenciales mal gestionado o de un scraping de datacenter mal rotado. El modelo también consume señales de TLS fingerprinting como JA3/JA4 cuando el cliente expone handshake directo.

5. Comprobaciones forenses en vivo

Para IPs dudosas, IPQS ejecuta checks en tiempo real: escaneo de puertos abiertos (22, 80, 1080, 3128, 8080), resolución de rDNS, verificación de geolocalización contra el rango, y detección de cabeceras Via o X-Forwarded-For mal formadas. Estas señales alimentan los flags proxy y vpn directamente.

Las señales concretas de detección de proxy (IPQualityScore proxy detection)

El campo proxy de IPQS no se basa en una sola heurística. Se construye a partir de un vector de señales que conviene conocer en detalle, porque cada una es un punto de fallo potencial para tu automatización.

Dos señales merecen atención extra porque son las que más工程师 subestiman:

• rDNS: un proxy de datacenter suele tener un PTR como ec2-54-210-1-2.compute-1.amazonaws.com. IPQS lo compara contra una lista de proveedores de hosting y sube el score. Un proxy residencial bien gestionado tiene un PTR del tipo cpe-72-178-12-34.res.rr.com, coherente con un ISP residencial.
• Geolocalización: IPQS cruza la geolocalización declarada con el rango asignado al ASN. Si pides una IP «en Berlín» pero el rango está registrado en Frankfurt para un ISP concreto, el mismatch suma puntos. Por eso la geo-targeting por ciudad de ProxyHat importa: user-country-DE-city-berlin alinea la salida con un rango coherente.

Umbrales y cómo los sitios integran el score en login, checkout y signup

IPQS recomienda un umbral de bloqueo en score ≥ 75 para signup y score ≥ 90 para acciones de alto riesgo como pago o retiro de fondos. En la práctica, los equipos anti-fraud configuran tres umbrales:

1. 0-74: permitir — IP limpia, flujo normal.
2. 75-89: desafiar — forzar CAPTCHA, step-up auth, revisión manual del pago.
3. 90-100: bloquear — denegar registro, login o checkout directamente.

La integración típica es una llamada síncrona a https://www.ipqualityscore.com/api/json/ip/{key}/{ip} en el momento del login o checkout. El coste de latencia es de 50-200 ms, asumible para casi cualquier flujo de usuario. Algunos equipos cachean el resultado por IP durante 24 horas para reducir coste y latencia, pero esto es arriesgado: una IP residencial puede reasignarse en horas y una IP de datacenter rotada puede cambiar de score entre peticiones.

Clave: el umbral que elijas define tu equilibrio fricción-vs-seguridad. Subir el bloqueo a 85 reduce falsos positivos en usuarios corporativos que viajan, pero deja pasar más scraping. Bajarlo a 70 bloquea más bots pero también bloquea a usuarios legítimos detrás de VPNs corporativas. No existe un número universal; se ajusta por canal y por producto.

Por qué los proxies residenciales pasan y los de datacenter fallan

Todo el modelo de IPQS está diseñado para responder a una pregunta: ¿esta IP parece una casa o una granja de servidores? La respuesta determina el score base. Un proxy residencial de ProxyHat con ASN de ISP real cumple las tres condiciones que IPQS busca para asignar score bajo:

1. ASN de ISP: la salida está en un rango asignado a Comcast, Spectrum, Deutsche Telekom, Movistar u otro operador de banda ancha. IPQS clasifica el ASN como ISP, no hosting, lo que evita el salto base de 30-50 puntos.
2. Geolocalización residencial coherente: el rango está registrado en la ciudad correcta y el PTR pertenece al ISP, no a un proveedor cloud. No hay mismatch geográfico.
3. Historial de abuso bajo: una IP de hogar reutilizada no ha tocado honeypots masivamente. Su score base se mantiene en 0-30.

Un proxy de datacenter, por el contrario, falla en las tres: ASN de hosting, PTR de cloud, y un rango /24 donde muchas IPs ya están en listas negras. El resultado típico es score 75-95 sin necesidad de que la IP haya hecho nada malo. Esa es toda la detección de proxy residencial: distinguir un ISP real de un hosting provider. No hay truco que arregle un ASN de AWS.

Los proxies móviles también pasan bien, porque su ASN es de un operador celular (T-Mobile, Vodafone, Movistar) y la geolocalización es naturalmente móvil. Son la opción más robusta para targets con anti-bot agresivo, aunque suelen ser más caros.

Más allá del IP: TLS, canvas y comportamiento

El score de IPQS es solo la primera capa. Los sitios con anti-bot serio (Cloudflare Bot Management, Datadome, Kasada) añaden tres capas más que conviene conocer aunque uses IPs residenciales perfectas.

TLS fingerprinting (JA3/JA4)

Cuando el cliente hace el handshake TLS, el orden exacto de cipher suites, extensiones y curvas forma un hash JA3/JA4. Un requests de Python con headers de Chrome pero handshake de OpenSSL produce un JA3 que no coincide con ningún Chrome real. IPQS no lo evalúa directamente, pero Cloudflare sí, y un mismatch JA3 es bloqueo casi seguro. La solución es usar un cliente que reproduzca el handshake del navegador: cycletls en Node, curl-impersonate o un navegador headless bien configurado. curl-impersonate es la referencia de facto para reproducir JA3 de Chrome y Firefox.

Canvas y WebGL fingerprinting

El navegador dibuja una escena WebGL y un canvas 2D con texto y geometría; el resultado pixel-a-pixel depende de GPU, driver y sistema operativo. Un headless sin GPU produce un hash que no existe en ningún perfil real. IPQS no lo mide, pero los SDKs de anti-bot sí. Para automatización seria conviene usar un navegador con GPU real o un fingerprint coherente y estable entre peticiones del mismo perfil.

Señales de comportamiento

Cadencia de peticiones, distancia entre clicks, tiempo de dwell, orden de eventos. Un script que carga la página y hace checkout en 800 ms con un solo evento de mouse es trivial de detectar. Las IPs residenciales no te salvan aquí; necesitas ritmos humanos o un buen generador de señales de input. Un buen benchmark: mantener al menos 2-4 segundos entre acciones críticas y variar los tiempos con jitter gaussiano.

Worked example: consultando IPQS para una salida residencial de ProxyHat vs datacenter

Vamos a medirlo. El siguiente script consulta la API de detección de proxy de IPQS para dos IPs: una salida residencial de ProxyHat geolocalizada en EE. UU. y una IP de datacenter de referencia. Necesitas una API key de IPQS (cuenta gratuita disponible) y credenciales de ProxyHat.

Primero, obtenemos la IP de salida de ProxyHat consultando un servicio de IP echo a través del proxy:

import requests
import os

IPQS_KEY = os.environ["IPQS_KEY"]
PROXYHAT_USER = os.environ["PROXYHAT_USER"]
PROXYHAT_PASS = os.environ["PROXYHAT_PASS"]

# Salida residencial en EE.UU.
proxy_url = "http://user-country-US:{}@gate.proxyhat.com:8080".format(PROXYHAT_PASS)
proxies = {"http": proxy_url, "https": proxy_url}

# 1. Descubrir la IP de salida residencial
resp = requests.get("https://api.ipify.org?format=json", proxies=proxies, timeout=20)
residential_ip = resp.json()["ip"]
print("IP residencial ProxyHat:", residential_ip)

# 2. IP de datacenter de referencia (sin proxy)
resp2 = requests.get("https://api.ipify.org?format=json", timeout=10)
datacenter_ip = resp2.json()["ip"]
print("IP datacenter local:", datacenter_ip)

def ipqs_lookup(ip):
    url = "https://www.ipqualityscore.com/api/json/ip/{}/{}".format(IPQS_KEY, ip)
    r = requests.get(url, params={"strictness": 1, "allow_public_access_points": "true"}, timeout=15)
    return r.json()

print("\n--- IP residencial ProxyHat ---")
print(ipqs_lookup(residential_ip))

print("\n--- IP datacenter ---")
print(ipqs_lookup(datacenter_ip))

Lo que verás típicamente: la IP residencial devuelve fraud_score entre 0 y 30, proxy: false, vpn: false, connection_type: "Residential" y un ASN clasificado como ISP. La IP de datacenter devuelve fraud_score entre 75 y 95, proxy: true o vpn: true, connection_type: "Corporate" o "Hosting" y un ASN de cloud. Esa diferencia de 60-90 puntos es exactamente lo que decide si tu scraper pasa el login o recibe un 403.

Para una sesión sticky (misma IP durante N minutos), añade el flag de sesión al usuario:

# Sesión sticky de 30 min en Berlín
proxy_url = "http://user-session-task42-country-DE-city-berlin:{}@gate.proxyhat.com:8080".format(PROXYHAT_PASS)

Para SOCKS5, cambia el puerto y el esquema:

socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080

Consulta la documentación de ProxyHat para el catálogo completo de flags de geo y sesión.

Errores comunes y casos límite

• Usar la misma IP de datacenter para todo: el score sube con cada petición sospechosa. Una IP que empieza en 75 puede terminar en 95 en una hora de scraping intenso.
• Rotar IPs de datacenter muy rápido: IPQS detecta el patrón de «muchas IPs nuevas del mismo ASN haciendo lo mismo» como scalable abuse. Rotar no te salva si todas las IPs son del mismo proveedor cloud.
• Ignorar el rDNS: aunque uses IP residencial, si el PTR está mal configurado o apunta a un hostname de hosting, el score sube. ProxyHat gestiona el rDNS, pero vale la pena verificarlo con dig -x IP.
• Cachear el score IPQS demasiado: 24 h es razonable; 7 días no lo es. Las IPs residenciales se reasignan y las de datacenter se queman.
• No medir el score de tu propio pool: si no auditas tus salidas, no sabes qué nodos están quemados. Ejecuta el script anterior en bucle sobre tu pool y descarta cualquier IP con score > 75.

Configuración específica en ProxyHat

Para maximizar la tasa de paso frente a IPQS y sistemas similares, la configuración recomendada en ProxyHat es:

1. Tipo de proxy: residencial para targets con anti-bot, móvil para los más agresivos, datacenter solo para targets sin protección.
2. Geo-targeting por país y ciudad: usa user-country-US o user-country-DE-city-berlin para alinear geolocalización con el rango del ISP. Revisa las ubicaciones disponibles.
3. Sesiones: rotación por petición para scraping masivo, sticky sessions de 10-30 min para flujos multi-paso (login + checkout).
4. Auditoría continua: consulta IPQS para cada nueva IP del pool antes de enviarla a producción.
5. Rate limit realista: 1-3 peticiones por segundo por IP para targets sensibles. Más rápido dispara behavioural analytics.

Si tu caso de uso es web scraping o SERP tracking, revisa las guías de web scraping y SERP tracking para patrones de rotación recomendados. Para comparar planes y tipos de IP, consulta la página de precios.

Marco ético y legal: auditar, no defraudar

Consultar la reputación IP de tus propias salidas y de tu pool de proxies es legítimo: es control de calidad. Usar proxies residenciales para automatización autorizada, investigación de seguridad con autorización por escrito, pentesting dentro del scope acordado y QA de tus propios flujos de signup es legítimo. Usarlos para fraude de pagos, evasión de bans justos, creación masiva de cuentas falsas o elusión de medidas de seguridad de un tercero sin autorización no lo es.

Dos marcos legales aplican directamente:

• CFAA (EE. UU.): acceder a un sistema «sin autorización» o «excediendo la autorización» puede ser delito federal. La línea entre scraping público y acceso no autorizado es gris; consulta el caso hiQ v. LinkedIn y obtén asesoría si operas a escala.
• GDPR (UE): una IP es dato personal. Procesar scores IPQS sobre IPs de usuarios europeos requiere base legal y, según el caso, consentimiento. Auditar tu propio pool no procesa datos de terceros, pero consultar IPs de visitantes sí.

La regla práctica: si tu caso de uso no sobreviviría a una revisión por escrito por el equipo legal del target, no lo hagas. La infraestructura de proxies es una herramienta; la responsabilidad del uso es tuya.

Conclusiones clave

Key takeaways

• IPQS produce un score 0-100 combinando honeypots, ASN, listas negras, ML y checks forenses en vivo. El ASN es la señal más predictiva.
• El umbral recomendado es bloquear a ≥75 para signup y ≥90 para checkout. Muchos sitios usan tres umbrales: permitir, desafiar, bloquear.
• Los proxies residenciales pasan porque su ASN es de ISP real, su geolocalización es coherente y su historial de abuso es bajo. Los de datacenter fallan en las tres.
• El score de IP es solo la primera capa. JA3/JA4, canvas fingerprinting y análisis de comportamiento añaden capas que ni siquiera una IP perfecta resuelve sola.
• Auditar tu propio pool con la API de IPQS es la forma más barata de saber qué nodos están quemados antes de mandarlos a producción.

La reputación IP y la puntuación de fraude no son magia negra: son un vector de señales que cualquier ingeniero puede medir y optimizar. La diferencia entre pasar y no pasar se reduce, en la mayoría de casos, a usar IPs que un anti-fraud clasificaría como casas reales. Eso es exactamente lo que proporciona un pool residencial bien gestionado. Mide tu pool, elige el tipo de proxy correcto para cada target y mantén tu automatización dentro de los límites éticos y legales. El resto es ingeniería.