Cómo probar la velocidad, tasa de éxito, y precisión de ubicación de un proxy residencial

La velocidad sola es un mal benchmark. Cómo medir bien la tasa de éxito, los percentiles de latencia, y la precisión geo de un proxy residencial, con tests de Python listos para copiar.

“¿Qué tan rápido es?” es la primera pregunta equivocada que hacer sobre un proxy residencial. Un proxy que responde en 200ms pero se bloquea la mitad de las veces es inútil; uno un poco más lento que devuelve la página real cada vez es exactamente lo que quieres. Antes de confiar en un proveedor, o de depurar por qué tu scraper rinde por debajo, necesitas medir tres cosas objetivamente: tasa de éxito, distribución de latencia, y precisión de ubicación. Esta guía te da tests para copiar y pegar de cada una y, igual de importante, cómo leer los números sin engañarte.

Todo lo de abajo corre contra el gateway residencial de Shifter (un endpoint, p.shifter.io:443, targeting codificado en el nombre de usuario), pero los tests son agnósticos al proveedor, cambia el host y las credenciales y funcionan en cualquier lugar. Los ejemplos son Python; la configuración del cliente refleja proxies residenciales con Python.

Las tres métricas que de verdad importan

La velocidad cruda es la métrica en la que la gente se fija y la menos útil en aislamiento. Las IPs residenciales enrutan por dispositivos de consumidor reales, así que son inherentemente un poco más lentas que las de datacenter, eso es esperable, y no un defecto. Lo que de verdad determina si un proxy es bueno para tu trabajo:

Tasa de éxito — de las peticiones que envías, cuántas devuelven la página real (no un bloqueo, CAPTCHA, o error). Este es el número que decide si tu pipeline de datos está completo.
Distribución de latencia — no la media, la dispersión. El p95 y la cola te dicen cuán malas se ponen tus peticiones lentas, que es lo que duele a escala.
Precisión de ubicación — cuando apuntas a un país o ciudad, ¿la IP de salida de verdad resuelve ahí? Para cualquier caso de uso con geo-targeting, datos de ubicación equivocada son datos silenciosamente equivocados.

Mide las tres. Un único número, especialmente la velocidad media, esconde los problemas que importan.

Configuración

Guarda las credenciales en variables de entorno, y define un helper que construya una URL de proxy con targeting:

import os, time, statistics, requests

USER = os.environ["SHIFTER_USER"]
PASS = os.environ["SHIFTER_PASS"]
GATEWAY = "p.shifter.io:443"

def proxy(country="us", city=None, sid=None, ttl=600):
    parts = [USER, "country", country]
    if city: parts += ["city", city]
    if sid:  parts += ["sid", sid, "ttl", str(ttl)]
    url = f"http://{'-'.join(parts)}:{PASS}@{GATEWAY}"
    return {"http": url, "https": url}

Primero, verifica que de verdad estás pasando por el proxy, un número sorprendente de reportes de “el proxy es lento” son tráfico que nunca salió de la máquina local:

r = requests.get("https://api.ipify.org?format=json", proxies=proxy("us"), timeout=30)
print(r.json())   # debería ser una IP residencial, no la tuya

Test 1: Precisión de ubicación

Apunta a un país (y opcionalmente una ciudad), pregunta a un endpoint de geo-IP dónde está la IP de salida, y mide la tasa de coincidencia sobre muchas muestras. Rota cada petición (sin sid) para muestrear el pool, no una IP:

def test_geo(country="us", n=50):
    hits = 0
    for _ in range(n):
        try:
            r = requests.get("http://ip-api.com/json", proxies=proxy(country), timeout=30)
            data = r.json()
            if data.get("countryCode", "").lower() == country.lower():
                hits += 1
        except requests.RequestException:
            pass
    print(f"{country}: {hits}/{n} = {hits/n:.0%} country-accurate")

test_geo("us")
test_geo("de")

Cómo leerlo. La precisión de país debería ser muy alta (piensa en el rango alto de los 90%). La precisión de ciudad es inherentemente más difusa, las bases de datos de geo-IP discrepan sobre a qué ciudad pertenece una IP, así que un “fallo” puede ser un desacuerdo de base de datos, no un proxy enviándote al lugar equivocado. Dos advertencias que te salvan de conclusiones falsas: prueba la precisión de ciudad contra la misma fuente de geo-IP que usa tu sitio objetivo si puedes, y nunca confíes en un único proveedor de lookup como verdad absoluta.

Test 2: Latencia, medida como una distribución

Mide el tiempo total de petición sobre muchas muestras y reporta percentiles, no la media. Una media suaviza justo la cola lenta que te duele a escala:

def test_latency(country="us", n=50, url="https://api.ipify.org"):
    times = []
    for _ in range(n):
        start = time.perf_counter()
        try:
            requests.get(url, proxies=proxy(country), timeout=30).raise_for_status()
            times.append((time.perf_counter() - start) * 1000)  # ms
        except requests.RequestException:
            pass
    times.sort()
    p = lambda q: times[min(len(times)-1, int(q*len(times)))]
    print(f"n={len(times)}  p50={p(0.5):.0f}ms  p95={p(0.95):.0f}ms  max={times[-1]:.0f}ms")

test_latency("us")

Cómo leerlo. Mira el p50 frente al p95: una dispersión ajustada (p95 cerca del p50) significa rendimiento predecible; un p95 muchas veces el p50 significa una cola pesada que estancará a los workers concurrentes. Para separar el overhead del proxy de la lentitud del objetivo, corre el mismo test contra un endpoint rápido y neutral (como un echo de IP) y contra tu objetivo real, la diferencia es aproximadamente la latencia propia del objetivo. Y no compares el p50 residencial con el p50 de datacenter como si fueran el mismo producto; el residencial añade un salto de dispositivo real por diseño (ve proxies residenciales vs datacenter).

Test 3: Tasa de éxito, la que más importa

Corre las peticiones contra tu objetivo real (el éxito es específico del objetivo) y clasifica cada resultado. La trampa aquí es confiar en el estado HTTP: un 200 OK aún puede ser un bloqueo blando, una página de CAPTCHA o “por favor verifica” servida con un 200. Así que valida el contenido, no solo el código:

def looks_like_real_page(html):
    # Ajusta esto a tu objetivo: presencia del markup esperado, ausencia de marcadores de bloqueo.
    block_markers = ("captcha", "are you a robot", "access denied", "unusual traffic")
    low = html.lower()
    return len(html) > 1000 and not any(m in low for m in block_markers)

def test_success(url, country="us", n=100):
    ok, soft_block, errors = 0, 0, 0
    for _ in range(n):
        try:
            r = requests.get(url, proxies=proxy(country), timeout=30)
            if r.status_code == 200 and looks_like_real_page(r.text):
                ok += 1
            else:
                soft_block += 1        # 200-pero-bloqueo, 403/429/503, etc.
        except requests.RequestException:
            errors += 1                # timeouts, fallos de conexión
    print(f"success={ok/n:.0%}  blocked={soft_block/n:.0%}  errors={errors/n:.0%}")

test_success("https://your-target.example/page", country="us")

Cómo leerlo. La tasa de éxito es la métrica principal para el scraping, es la fracción de peticiones que devolvieron datos usables. Divide los fallos en bloqueados (el objetivo te rechazó) frente a errores (red/timeout), porque tienen arreglos distintos: los bloqueos consistentes apuntan a la calidad de IP o al comportamiento de las peticiones (por qué se bloquean los scrapers), mientras que los errores apuntan a timeouts o filtros geo demasiado ajustados. Nota que la rotación por petición y un bucle de reintentos suben tu tasa de éxito efectiva, así que mide tanto la cruda (de un solo disparo) como la de con-reintentos si así es como correrás en producción.

Juntándolo todo

Un harness mínimo corre las tres y imprime un informe:

if __name__ == "__main__":
    for cc in ("us", "de", "gb"):
        print(f"\n== {cc.upper()} ==")
        test_geo(cc, n=50)
        test_latency(cc, n=50)
        test_success("https://your-target.example/page", country=cc, n=100)

Léelo en este orden: tasa de éxito primero (¿siquiera vuelven los datos?), luego la cola de latencia (¿aguantará bajo concurrencia?), luego la precisión geo (¿son los datos correctos?). Un proveedor que gana en p50 pero pierde en tasa de éxito es la elección equivocada para el scraping.

Errores comunes que producen números engañosos

Reportar la latencia media. Usa percentiles, la cola es lo que rompe los trabajos concurrentes.
Confiar en el estado 200. Los bloqueos blandos devuelven 200 con una página de CAPTCHA. Valida el contenido.
Muestras demasiado pequeñas. 5 peticiones no te dicen nada; usa suficientes (50 a 100+) para ver la distribución y la cola.
Verdad absoluta de geo equivocada. Distintas bases de datos de geo-IP discrepan, especialmente a nivel de ciudad. Prueba contra la fuente que usa tu objetivo, y trata la precisión de ciudad como inherentemente más difusa que la de país.
Comparar residencial con datacenter en velocidad cruda. Productos distintos; el residencial cambia algo de latencia por confianza de usuario real y una tasa de éxito más alta en objetivos defendidos (qué proxies son mejores para scrapear).
No confirmar que estás en el proxy. Verifica que la IP de salida cambió antes de hacer benchmark de nada.

Una nota sobre hacerlo de forma responsable

Haz benchmark contra endpoints a los que se te permite acceder, servicios públicos de echo de IP para velocidad y geo, y tus propios objetivos autorizados para la tasa de éxito. Mantén los tamaños de muestra razonables, no martilles un sitio para medirlo, y honra los rate limits. Nuestra política de uso aceptable es la fuente de la verdad para lo que está permitido en Shifter.

Preguntas frecuentes

¿Qué es una buena tasa de éxito para proxies residenciales? Depende por completo del objetivo, un sitio bien defendido bloqueará más que uno abierto. Lo que importa es medirla contra tu objetivo y comparar proveedores en el mismo objetivo. Divide los fallos en bloqueos frente a errores para saber qué arreglar.

¿Por qué mi proxy residencial es más lento que uno de datacenter? Porque enruta por un dispositivo de consumidor real, ese salto añade latencia por diseño. Ese es el tradeoff por la confianza de usuario real y tasas de éxito más altas en sitios que bloquean las IPs de datacenter. Juzga el residencial por la tasa de éxito y la distribución de latencia, no por el p50 crudo frente a datacenter.

¿Cómo pruebo la precisión de ubicación a nivel de ciudad? Apunta a la ciudad y comprueba la IP de salida contra una fuente de geo-IP, idealmente la misma que usa tu objetivo. Espera que la precisión de país sea muy alta y la de ciudad más difusa, ya que las bases de datos de geo-IP discrepan sobre los límites de ciudad. Ve cuándo importa el targeting a nivel de ciudad.

¿Por qué una respuesta 200 aún cuenta como un fallo? Porque los sitios sirven bloqueos blandos, páginas de CAPTCHA o “verifica que eres humano”, con un estado 200. Si solo compruebas el código de estado, registrarás los bloqueos como éxitos. Valida que el contenido coincide con cómo se ve una página real.

¿Debería probar con sesiones rotativas o sticky? Ambas, según tu carga de trabajo. La rotativa (sin sid) muestrea el pool y sirve para el scraping amplio; la sticky (sticky vs rotativa) prueba flujos de varios pasos. Mide el modo en el que de verdad correrás en producción.

En resumen

Probar bien un proxy residencial significa negarse a reducirlo a un único número de velocidad. Mide la tasa de éxito contra tu objetivo real con validación de contenido, la latencia como una distribución con una mirada a la cola p95, y la precisión de ubicación con una verdad absoluta de geo-IP sensata, y sabrás si un proveedor de verdad encaja con tu trabajo en lugar de adivinar por una cifra de marketing. La calidad del pool es lo que mueve las tres, así que entender la reputación de IP te ayuda a interpretar los resultados.

Si estás haciendo benchmark de proveedores o depurando tu propia tasa de éxito, corre estos tests contra el gateway residencial y tu objetivo de elección. La página de precios tiene planes por GB para probarla contra los mercados y sitios que te importan.