Una prueba gratuita es una cantidad pequeña y fija de ancho de banda, y la forma en que la utilices determina si aprendes algo útil. El enfoque habitual es apuntarla a un endpoint de prueba que devuelve una dirección IP, confirmar que la dirección cambia y concluir que los proxies funcionan. Eso no te dice casi nada de lo que necesitabas saber, y es la razón por la que la gente acaba comprando un plan que le decepciona en los sitios que realmente le importan.
Una prueba existe para responder a una única pregunta: ¿funcionará esto en mis objetivos, a mi volumen, en mis mercados? Todo lo que sigue está ordenado para que las respuestas de mayor valor aparezcan primero, por si se te acaba el ancho de banda antes que la curiosidad.
Antes de empezar: prepárate para no desperdiciarla
Dos minutos de preparación cambian lo que vale una prueba.
Anota tus objetivos reales, los sitios o endpoints concretos de los que depende tu proyecto, e incluye el más difícil en lugar de solo los fáciles. Anota tus mercados reales, los países concretos y, si es relevante, las ciudades que necesitas. Y decide de antemano qué aspecto tiene un resultado aprobado, por ejemplo un noventa por ciento de respuestas válidas en tu objetivo principal desde dos países, porque un umbral fijado de antemano evita que racionalices un resultado mediocre después.
Luego configura la validación de respuestas antes de tu primera solicitud. Este es el paso de preparación más importante, porque una página de desafío, un resultado vacío, un listado truncado o una redirección a una página genérica a menudo llegarán con un estado 200, y una prueba que cuenta códigos de estado informará de éxito sin haber recopilado nada. Comprueba que exista un marcador que solo aparezca en una página realmente buena: un elemento esperado, una longitud de contenido plausible, un campo conocido en el JSON. Los modos de fallo están catalogados en detecting blocked or fake content.
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}
def is_valid(html):
return "product-price" in html and len(html) > 20_000 # your own marker
ok = 0
for i in range(100): # a small, honest sample
r = requests.get("https://your-real-target.example/item/123",
proxies=PROXIES, timeout=20)
if r.status_code == 200 and is_valid(r.text):
ok += 1
print(f"validated success rate: {ok}%") # not "did it return 200"Prueba uno: tasa de éxito en tus propios objetivos
Esta es la prueba que importa más que todas las demás juntas, y debería consumir la mayor parte de tu prueba.
Ejecuta una muestra significativa, un centenar de solicitudes aproximadamente, contra cada objetivo real y mide la tasa de éxito validada en lugar de la HTTP. Incluye tu objetivo más defendido, porque un pool que gestiona bien los sitios fáciles y se derrumba en el difícil no es un pool que resuelva tu problema. Si tienes una configuración actual, ejecuta la misma muestra a través de ella como control para poder comparar en lugar de suponer.
Fíjate en el patrón donde el éxito empieza alto y se degrada a lo largo de la ejecución, ya que eso suele significar que tu ritmo es demasiado agresivo para el objetivo, más que que el pool sea malo, y es una lección de ritmo que vale la pena aprender durante una prueba en lugar de en producción.
Prueba dos: precisión geográfica
Si tu proyecto depende de la ubicación, y la mayoría lo hace, verifica que el país que solicitas es el país que obtienes, y comprueba todos los mercados que realmente necesitas en lugar de un único ejemplo cómodo. Un pool puede ser excelente en una región y escaso en otra, y la cifra global de una página de marketing no te dice nada sobre el lugar concreto desde el que recopilas.
Vale la pena comprobar dos niveles. Primero, si la dirección de salida geolocaliza en el país solicitado, muestreando a través de suficientes solicitudes para detectar inconsistencias. Segundo, y más significativo, si el sitio objetivo se comporta como si estuvieras allí: moneda correcta, precios locales, catálogo regional, resultados de búsqueda locales. El segundo es la prueba real, porque las bases de datos de geolocalización de IP y la opinión del propio objetivo no siempre coinciden, y es la opinión del objetivo la que estás pagando. Si necesitas city-level targeting, verifícalo a nivel de ciudad en lugar de asumir que la precisión a nivel de país lo implica.
Prueba tres: si el pool es lo que dice ser
Gasta algo de ancho de banda muestreando direcciones de salida y agrupándolas por la organización a la que pertenecen. Los proveedores de internet de consumo son lo que quieres ver; una proporción significativa de organizaciones de hosting o cloud indica que el pool está diluido con espacio de datacenter, lo cual importa porque esas direcciones son las que tus objetivos tratarán como tráfico de máquina. El método completo está en spotting datacenter IPs sold as residential, y la distinción subyacente está en the anatomy of a residential IP.
Ya que estás en ello, ten en cuenta que la calidad de la dirección es un eje separado del tipo de dirección: un pool genuinamente residencial que haya sido abusado hasta tener mala reputation seguirá atrayendo desafíos, que es exactamente lo que mide la prueba uno desde fuera.
Prueba cuatro: comportamiento de sesión
Si alguna parte de tu proyecto implica un flujo de varios pasos, una búsqueda que pagina, un inicio de sesión, un contexto de ubicación que estableces y luego lees, confirma dos cosas durante la prueba.
Confirma que la rotación realmente rota cuando no especificas una sesión, y confirma que una sticky session realmente mantiene una dirección durante el tiempo que necesitas. Luego ejecuta una de tus secuencias reales de varios pasos de principio a fin en una sesión mantenida, porque un pool puede parecer correcto en solicitudes individuales y aun así romper un flujo si la dirección cambia por debajo de él. Si tu trabajo necesita muchas identidades mantenidas a la vez, comprueba que las sesiones concurrentes se comportan de forma independiente.
Prueba cinco: rendimiento y consumo
Dos cifras a registrar, ambas afectan al plan que acabarás comprando.
La latencia y el rendimiento importan si tu trabajo es sensible al tiempo, así que mide los tiempos de respuesta a través del proxy en tus objetivos reales en lugar de en un endpoint de prueba de velocidad, y espera que lo residencial sea más lento que una conexión directa ya que el tráfico recorre un camino más largo. Lo que importa es si es lo bastante rápido para tu tarea, no si iguala una referencia de datacenter. El enfoque de medición está en testing speed, success rate, and location accuracy.
Luego mide los bytes por solicitud, que es la cifra que convierte una estimación de plan en una decisión de plan. Multiplica tu promedio medido por tu volumen mensual de solicitudes esperado y tendrás una cifra de ancho de banda real en lugar de una suposición, que es el dato de entrada para estimating monthly bandwidth. Si el resultado resulta incómodo, este es también el momento de descubrir que obtener un endpoint de datos en lugar de renderizar páginas completas te hace bajar de nivel, como se explica en cutting proxy bandwidth costs.
En qué no gastar una prueba
Hay algunas cosas que consumen ancho de banda sin enseñarte nada.
Probar contra un endpoint de eco de IP demuestra que el proxy está conectado, lo cual es una comprobación de sanidad de treinta segundos más que una evaluación. Probar solo objetivos fáciles favorece al pool y oculta la respuesta que necesitabas. Ejecutar un volumen enorme contra un único objetivo no mide la calidad y puede hacer que esa dirección quede bloqueada, lo que a su vez hace que el pool parezca peor de lo que es. Y juzgar a partir de un puñado de solicitudes te da ruido, ya que una muestra de cinco solicitudes no puede distinguir un pool del noventa y cinco por ciento de uno del setenta.
Una más: no evalúes a un proveedor por las afirmaciones sobre el tamaño del pool. Una cifra destacada no es algo que una prueba pueda verificar y no es lo que determina tus resultados. La densidad en tus países y el éxito en tus objetivos sí lo son.
Una lista de comprobación para la prueba
- Prepárate: objetivos reales incluyendo el más difícil, mercados reales, un umbral de aprobación y validación de respuestas escrita antes de la primera solicitud.
- Mide la tasa de éxito validada, aproximadamente un centenar de solicitudes por objetivo, con un control si lo tienes.
- Verifica la geografía para cada mercado que necesites, tanto la ubicación de salida como el comportamiento del objetivo.
- Muestrea las organizaciones de salida para confirmar que el pool es genuinamente residencial.
- Ejecuta un flujo real de varios pasos en una sesión mantenida, y confirma la rotación sin ella.
- Registra la latencia y los bytes por solicitud, y dimensiona tu plan a partir de cifras medidas.
Si una prueba supera los seis puntos en tus propios objetivos, la decisión del plan se convierte en aritmética en lugar de un salto de fe. El conjunto completo de decisiones a nivel de plan está en choosing the right residential proxy plan.
La conclusión
Una prueba es ancho de banda, y el ancho de banda gastado en un endpoint de eco de IP responde a una pregunta que no tenías. Gástalo en tus objetivos reales con validación de respuestas real, verifica los mercados que realmente necesitas, comprueba que el pool es genuinamente residencial, ejercita un flujo de sesión si tu trabajo tiene uno, y registra los bytes por solicitud para que tu plan se dimensione a partir de mediciones. Fija el umbral de aprobación antes de empezar. Haz eso y terminarás la prueba sabiendo si el producto resuelve tu problema, que es lo único para lo que sirve una prueba.
Si quieres ejecutar esa lista de comprobación, puedes hacerlo con una prueba gratuita de proxies residenciales de Shifter, con segmentación por país y ciudad, rotación por defecto y sticky sessions para los flujos que las necesitan. Cuando lleguen los números, el precio por GB significa que el plan que elijas seguirá al ancho de banda que has medido en lugar de a una suposición.