Cuando tu scraper o flujo de automatización recibe un 403 en el primer request, casi nunca la causa es tu header ni tu handshake TLS — es la reputación de IP. Servicios como IPQualityScore (IPQS) asignan una puntuación de fraude de 0 a 100 a cada dirección IP, y los sitios la consultan en tiempo real para decidir si te dejan pasar, te desafían con un CAPTCHA o te bloquean sin más. Entender cómo funciona la reputación de IP y la puntuación de fraude (IPQualityScore) es la diferencia entre una pipeline que escala limpiamente y otra que muere el segundo día.
Este artículo está pensado para ingenieros anti-fraude y de scraping que necesitan evaluar la calidad de un pool de proxies antes de comprometer tráfico real. Usaremos IPQS como caso práctico porque su API de proxy detection expone de forma transparente las mismas señales que consumen los bancos, las pasarelas de pago y los sitios de e-commerce. La conclusión práctica —spoiler— es que un proxy residencial genuino con ASN de ISP pasa con puntuaciones bajas, mientras que un datacenter IP queda marcado casi siempre. Vamos a desarmar por qué.
Qué es la reputación de IP y cómo se construye la puntuación de fraude
La reputación de IP es un perfil histórico y en tiempo real asociado a una dirección: qué ha hecho, desde qué red sale, si aparece en listas negras y si su comportamiento coincide con patrones de abuso conocido. IPQualityScore condensa todo eso en un único número entre 0 y 100, donde 0 es tráfico completamente limpio y 100 es abuso casi cierto. El número no es mágico: es la salida de un pipeline de varias capas que conviene conocer si vas a interpretar resultados.
Honeypots, trampas y telemetría de abuso
IPQS y servicios similares operan honeypots: formularios falsos, cuentas de prueba y endpoints instrumentados que solo un bot o un atacante tocaría. Cuando una IP envía spam a un honeypot, intenta credenciales robadas o rellena un formulario de registro con datos sintéticos, esa IP queda marcada con un sello de recent abuse que pesa mucho en la puntuación final. La telemetría se acumula durante meses, por lo que una IP puede tener un historial sucio aunque hoy se comporte bien.
Clasificación de ASN y rangos
Cada IP pertenece a un bloque asignado a un Autonomous System (ASN). IPQS clasifica los ASN en categorías: ISP residencial, hosting/datacenter, móvil y corporativo. Un rango completo propiedad de DigitalOcean, AWS, Hetzner o OVH recibe un peso negativo de partida, porque históricamente el 99% del tráfico automatizado malicioso sale de ahí. Un rango de Comcast o AT&T no recibe ese peso, porque el tráfico residencial legítimo lo domina.
Listas negras compartidas
IPQS agrega feeds de blacklists públicas (Spamhaus, SORBS históricamente, Project Honey Pot) y privadas. Aparecer en una lista negra activa suma puntos; aparecer en varias multiplica el impacto. Las listas negras tienen una vida útil: una IP puede deslistarse tras 7-30 días sin incidentes, pero la marca de recent abuse en IPQS puede persistir más tiempo.
Machine learning y señales de comportamiento
La puntuación final no es solo suma de pesos: un modelo de ML combina decenas de features —velocidad de requests, diversidad de user-agents desde la misma IP, coincidencia geográfica, hora del día, patrón de rotación— para detectar lo que IPQS llama scalable abuse: tráfico que se ve legítimo por request individual pero que, en agregado, revela automatización. Un solo request desde un datacenter IP con un header perfecto puede puntuar 35; mil requests en una hora desde el mismo bloque suben la puntuación de todo el rango.
Comprobaciones forenses en vivo
Finalmente, IPQS ejecuta live forensic checks en el momento de la consulta: escanea puertos abiertos (22, 80, 1080, 3128, 8080 son clásicos de proxies), comprueba el rDNS (reverse DNS), valida la geolocalización contra la base de MaxMind y detecta si la IP aparece en la red Tor o en listas de proxies públicos. Estas señales se combinan con las históricas para producir el número de 0 a 100. Puedes revisar el detalle de cada campo en la documentación oficial de la Proxy Detection API de IPQS.
Las señales concretas que IPQS usa para detectar proxies
Si miras la respuesta JSON de la API de IPQS, verás campos booleanos y numéricos. Estos son los que de verdad mueven la aguja:
- Tipo de ASN (hosting vs ISP): el campo
connection_typedevuelveresidential,corporate,education,mobileodatacenter. Cualquier cosa que no searesidentialomobilesuma puntos por defecto. - Puertos abiertos:
active_proxyse activa si IPQS detecta un servidor proxy escuchando en puertos típicos. Un datacenter IP con el puerto 8080 abierto grita "soy un proxy". - rDNS (reverse DNS): si el PTR de la IP resuelve a algo como
host.digitalocean.comoec2-xx.compute.amazonaws.com, el patrón del hostname delata el proveedor cloud. Un residencial real resuelve acpe-72-178-xx-xx.texas.res.rr.com. - Geolocalización y mismatch: IPQS compara la geolocalización declarada por MaxMind con la zona horaria del navegador y con el idioma del Accept-Language. Un IP en Frankfurt con un navegador en
en-USy zona horariaAsia/Kolkataes una bandera roja gigante. - Historial de abuso reciente:
recent_abuseyabuse_velocityindican si la IP ha sido reportada en los últimos días y con qué frecuencia. Una IP datacenter reciclada que antes perteneció a un botnet puede tenerrecent_abuse: trueaunque ahora la uses tú limpiamente. - Señales de Tor y VPN:
toryvpnson booleanos. Tor casi siempre dispara la puntuación al máximo; las VPN comerciales (NordVPN, ExpressVPN) también, porque sus rangos están catalogados.
Hay además una capa que IPQS no expone directamente pero que los sitios avanzados aplican encima: el fingerprinting TLS. Un cliente HTTP de Python con requests produce un JA3/JA4 distinto al de un Chrome real, y servicios como Cloudflare usan ese hash para separar bots de humanos antes incluso de mirar la IP. Puedes leer cómo funciona el hashing JA3 en la documentación de Cloudflare Radar sobre JA3. La reputación de IP y el fingerprint TLS son filtros en serie: pasar uno no sirve de nada si fallas el otro.
Umbrales que importan: por qué >=90 bloquea y cómo se cablea
IPQS publica una recomendación de uso que conviene memorizar: bloquear tráfico con fraud_score >= 90, desafiar (CAPTCHA, 2FA, step-up) entre 75 y 89, y dejar pasar por debajo de 75. Estos números no son arbitrarios — corresponden a los percentiles donde la precisión del modelo se mantiene alta sin sacrificar demasiados falsos positivos. Un umbral demasiado bajo (por ejemplo, bloquear desde 50) mata tráfico residencial legítimo; uno demasiado alto deja pasar bots sofisticados.
En la práctica, los sitios cablean esta lógica en tres puntos críticos:
- Signup / registro: si la IP del visitante tiene
fraud_score >= 90orecent_abuse == true, se bloquea el alta o se exige verificación por email/SMS. Es el punto más barato para frenar abuso — antes de que la cuenta exista. - Login: puntuaciones entre 75 y 89 disparan step-up authentication (2FA por app, push notification). Por encima de 90, se bloquea o se requiere reseteo de credenciales. Esto frena credential stuffing sin penalizar a usuarios legítimos en redes nuevas.
- Checkout / pago: aquí el umbral suele ser más conservador. Muchos comercios bloquean cualquier IP con
fraud_score >= 85oproxy == true, porque el coste de un chargeback (típicamente 15-25 USD más comisión) justifica la prevención agresiva.
Para tu pipeline de scraping, la implicación es directa: si tu IP de salida puntúa por encima del umbral del sitio objetivo, no importa lo bien que imites headers o resuelvas CAPTCHAs — la decisión se tomó antes de que tu request llegara al código de la aplicación. Por eso conviene medir tu propia puntuación antes de enviar tráfico de valor.
Por qué los proxies residenciales pasan donde los datacenter fallan
Aquí está el núcleo del asunto. Un proxy residencial genuino sale desde una IP asignada por un ISP a un hogar real: Comcast, Spectrum, Deutsche Telekom, Movistar. Esa IP tiene:
- ASN de ISP residencial, no de hosting. IPQS la clasifica como
residentialy no aplica el peso negativo de partida. - Geolocalización residencial coherente: el rDNS apunta a
cpe-…, la ciudad de MaxMind coincide con la zona horaria del navegador y con el idioma esperado. - Historial limpio: si el hogar no ha sido parte de un botnet,
recent_abuseesfalsey la puntuación base se mantiene baja (típicamente 0-30). - Sin puertos de proxy abiertos: el router doméstico no escucha en 8080 ni en 1080 hacia Internet.
Un datacenter IP, por contraste, falla en casi todas las señales a la vez: ASN de hosting, rDNS que delata el proveedor cloud, historial de abuso compartido con el rango, y a menudo puertos abiertos. No es que IPQS tenga una lista negra específica de tu proveedor — es que las señales se acumulan y el modelo las pesa. Por eso un datacenter IP puntúa típicamente entre 60 y 90 incluso sin historial de abuso personal, mientras que un residencial limpio puntúa 0-25.
La siguiente tabla resume el contraste:
| Señal | Residencial (ISP) | Datacenter (hosting) | Móvil (carrier) |
|---|---|---|---|
| Tipo de ASN | ISP residencial | Hosting / cloud | Móvil (4G/5G) |
| Fraud score típico (sin abuso) | 0-25 | 60-90 | 0-35 |
| Precisión de geolocalización | Ciudad / barrio | País, a veces errónea | Ciudad (cambiante) |
| rDNS característico | cpe-…res.rr.com | ec2-…amazonaws.com | mobile-…telekom.de |
| Detección de proxy/VPN | false | true casi siempre | false |
| Coste por GB (aprox.) | 3-8 USD | 0.5-2 USD | 8-15 USD |
| Caso de uso ideal | Scraping serio, SERP, cuentas | Pruebas internas, fetch masivo | Apps móviles, 2FA bypass |
Los proxies móviles también pasan limpios —su ASN es de un operador celular— pero son más caros y su IP rota con cada conexión de radio, lo que los hace ideales para flujos que simulan apps móviles pero menos eficientes para scraping masivo de escritorio.
Caso práctico: consultando la API de IPQS para un exit residencial de ProxyHat
Vamos a medirlo. El objetivo es legítimo: auditar la calidad de tu propia salida de proxy antes de enviar tráfico de producción. Consultaremos la API de IPQS para la IP que nos asigna ProxyHat con un exit residencial en EE.UU., y la compararemos con una IP datacenter típica. Necesitas una API key de IPQS (tienen tier gratuito con 5,000 consultas/mes).
Paso 1: descubrir tu IP de salida
import requests
IPQS_KEY = "TU_API_KEY_IPQS"
# Salida residencial vía ProxyHat, geolocalizada en EE.UU.
proxies = {
"http": "http://user-country-US:TU_PASSWORD@gate.proxyhat.com:8080",
"https": "http://user-country-US:TU_PASSWORD@gate.proxyhat.com:8080",
}
# Descubrir la IP de salida real
exit_ip = requests.get(
"https://api.ipify.org?format=json",
proxies=proxies,
timeout=15,
).json()["ip"]
print("IP residencial de salida:", exit_ip)
Si exit_ip pertenece a un rango de Comcast, Spectrum o AT&T, vas por buen camino. Si pertenece a AWS u OVH, algo está mal en tu configuración.
Paso 2: consultar IPQS para esa IP
def ipqs_lookup(ip: str, key: str = IPQS_KEY) -> dict:
url = f"https://www.ipqualityscore.com/api/json/ip/{key}/{ip}"
r = requests.get(url, timeout=10)
r.raise_for_status()
return r.json()
residential = ipqs_lookup(exit_ip)
print("--- Salida residencial ProxyHat ---")
print("fraud_score:", residential["fraud_score"])
print("connection_type:", residential["connection_type"])
print("proxy:", residential["proxy"], "vpn:", residential["vpn"], "tor:", residential["tor"])
print("recent_abuse:", residential["recent_abuse"])
print("ISP:", residential["ISP"], "ASN:", residential["ASN"])
En una salida residencial limpia esperas ver algo como fraud_score: 0-20, connection_type: residential, proxy: false, recent_abuse: false. Esa es la firma que pasa los umbrales de la mayoría de sitios.
Paso 3: comparar con una IP datacenter
# Una IP datacenter típica (rango de hosting conocido)
datacenter_ip = "104.131.0.1"
dc = ipqs_lookup(datacenter_ip)
print("--- IP datacenter de comparación ---")
print("fraud_score:", dc["fraud_score"])
print("connection_type:", dc["connection_type"])
print("proxy:", dc["proxy"], "vpn:", dc["vpn"])
print("recent_abuse:", dc["recent_abuse"])
print("ISP:", dc["ISP"], "ASN:", dc["ASN"])
Aquí lo normal es fraud_score: 70-95, connection_type: datacenter, proxy: true. La diferencia no es marginal — es estructural. Por más que optimices tu scraper, esa IP datacenter va a quedar marcada en cuanto toque un endpoint que consulte IPQS.
Paso 4: comparativa en curl
Si prefieres una verificación rápida desde terminal:
# Descubrir la IP de salida residencial
curl -x http://user-country-US:TU_PASSWORD@gate.proxyhat.com:8080 \
https://api.ipify.org
# Consultar IPQS para esa IP
curl "https://www.ipqualityscore.com/api/json/ip/TU_API_KEY_IPQS/<IP>"
Sustituye <IP> por la que devolvió el primer comando. El JSON de respuesta incluye todos los campos que vimos en Python.
Configuración de ProxyHat para mantener tu puntuación de fraude baja
La estrategia no es solo "usar residenciales" — es usarlos bien. Algunas reglas prácticas:
- Geo-targeting coherente: si tu objetivo es un sitio en Alemania, sal con
user-country-DE. Un IP de EE.UU. accediendo a una tienda alemana conAccept-Language: de-DEes un mismatch que algunos sitios detectan. Consulta las ubicaciones disponibles de ProxyHat para alinear la geografía. - Sesiones pegajosas cuando tenga sentido: para flujos de login o checkout, usa
user-session-abc123para mantener la misma IP durante toda la sesión. Rotar IP entre el GET del formulario y el POST puede disparar señales anti-fraude legítimas. - Rotación por request para scraping masivo: si solo recolectas datos públicos (SERP, precios), rota en cada request sin sesión fija. Así distribuyes el riesgo entre muchas IPs y ninguna acumula historial de abuso.
- Mide antes de enviar tráfico de valor: ejecuta el script de IPQS anterior contra una muestra de tu pool antes de un lanzamiento. Si más del 5% de tus IPs puntúan por encima de 75, cambia de proveedor o de subred.
Para casos de uso concretos, revisa nuestras guías de web scraping y SERP tracking, y compara planes en la página de precios de ProxyHat. La documentación técnica completa, incluyendo parámetros avanzados de sesión y geolocalización, está en docs.proxyhat.com.
Errores comunes y casos límite
Algunos patrones que vemos repetidamente:
- Usar datacenter para todo y sorprenderse por los 403: si tu IP puntúa 85 en IPQS, ningún header va a salvarte. Cambia a residencial antes de tocar nada más.
- Ignorar el fingerprint del navegador: incluso con un residencial limpio, un
requestsde Python con un JA3 de OpenSSL puro queda marcado por Cloudflare. Para objetivos serios, usa Playwright constealtho un navegador real headless, y deja que el proxy residencial solo cubra la capa de IP. - Rotar demasiado en flujos con estado: cambiar de IP entre el login y la primera acción autenticada es exactamente el patrón que los sistemas anti-fraude buscan. Usa sesiones pegajosas para flujos con estado.
- No auditar el pool: los rangos residenciales pueden ensuciarse si un hogar se infecta con malware. Consulta IPQS periódicamente sobre una muestra aleatoria de tu pool y retira IPs con
recent_abuse: true. - Asumir que "residencial" siempre es limpio: algunos proveedores mezclan IPs de IoT comprometidos con residenciales genuinos. Si tu fraud score medio sube sin explicación, investiga el origen del pool.
Marco ético: testing legítimo, no fraude de pagos
Antes de cerrar, lo obligatorio. Auditar tu propia IP con IPQS es perfectamente legítimo — estás comprobando la calidad de un servicio que pagas. La automatización autorizada sobre sitios con los que tienes relación comercial o cuyos robots.txt y términos de servicio lo permiten, también. Lo que no es aceptable es usar proxies para evadir controles anti-fraude en flujos de pago, crear cuentas falsas a escala, o acceder a sistemas sin autorización.
En EE.UU., el Computer Fraud and Abuse Act (CFAA) tipifica el acceso no autorizado a sistemas protegidos, y los tribunales han interpretado que saltarse restricciones técnicas puede constituir delito aunque no haya daño económico. En la UE, el GDPR impone obligaciones sobre el tratamiento de datos personales — y una IP lo es. Si tu scraping recoge datos personales de usuarios europeos, necesitas base legal y, en muchos casos, consentimiento. La regla práctica: si tu caso de uso te da dudas sobre su legalidad, consulta a un abogado antes, no después.
Para equipos de seguridad, el pentesting autorizado sobre infraestructura propia o con contrato firmado es el escenario natural para este tipo de auditoría de IP. Para equipos de scraping, cíñete a datos públicos, respetar robots.txt, y mantener tasas de request razonables (típicamente 1-5 req/s por IP residencial, no 50).
Puntos clave
La reputación de IP es un filtro en serie: si tu IP puntúa alto en IPQS, ningún truco de header o TLS te salva. La defensa correcta es salir desde una red que el modelo clasifica como residencial limpia.
- IPQS construye su puntuación de 0 a 100 combinando clasificación de ASN, honeypots, listas negras, ML de comportamiento y comprobaciones forenses en vivo (puertos, rDNS, geo, Tor).
- El umbral recomendado es bloquear a
>= 90, desafiar entre 75 y 89, y dejar pasar por debajo de 75. Checkout suele ser más conservador. - Un proxy residencial genuino pasa porque su ASN es de ISP, su geolocalización es coherente y su historial está limpio — exactamente lo que el modelo busca para no marcar.
- Un datacenter IP falla estructuralmente: ASN de hosting, rDNS delator y historial de abuso compartido en el rango.
- Audita tu pool con la API de IPQS antes de enviar tráfico de valor. Si más del 5% de tus IPs puntúan >75, cambia de proveedor o subred.
- La IP es necesaria pero no suficiente: combina residenciales con un fingerprint de navegador real para pasar filtros avanzados como Cloudflare.
Si quieres probarlo tú mismo, crea una cuenta en ProxyHat, ejecuta el script de arriba contra tu salida residencial, y compara el fraud_score con cualquier IP datacenter que tengas a mano. La diferencia es la mejor demostración de por qué el tipo de proxy importa más que cualquier otra optimización.
