Ir al contenido
Iniciar sesión Registrarse

Buenas prácticas

La forma más rápida de saber si Shifter se adapta a tu proyecto es ejecutar tu carga de trabajo real, las mismas peticiones que ejecutarás en producción, y leer los resultados con honestidad. Estas prácticas te ayudan a conseguir una prueba limpia y representativa en lugar de una engañosa.

La forma en que rotas las IPs debe seguir lo que necesita tu tarea.

  • Rotación por petición (predeterminada): una IP residencial nueva en cada petición a través de la puerta de enlace p.shifter.io:443. Ideal para scraping, rastreo, recopilación de precios, trabajo de SERP y cualquier caso en el que cada petición sea independiente.
  • Sesiones persistentes: mantiene la misma IP durante una ventana determinada usando un id de sesión (sid) y un tiempo de vida (ttl). Ideal para inicios de sesión, carritos, procesos de pago y cualquier flujo de varios pasos que deba permanecer en una IP. Por ejemplo, customer-USERNAME-sid-9f3a2b7c-ttl-600 mantiene una IP durante unos 600 segundos.

Regla general: si los pasos dependen unos de otros, usa una sesión. Si no, rota. Los detalles completos están en Sesiones.

Muchos sitios cambian el contenido, los precios o la disponibilidad según la ubicación.

  • Si tu objetivo es sensible a la geolocalización, orienta por país, región, ciudad o ASN para que tu prueba refleje lo que ven los usuarios reales en ese mercado. Por ejemplo, customer-USERNAME-country-us-state-newyork-city-newyork.
  • Si la ubicación no importa para tu caso de uso, mantén la orientación amplia. Restringir demasiado reduce el conjunto de IPs disponibles y puede bajar las tasas de éxito sin ningún beneficio.

Consulta Geo-targeting para ver todos los parámetros.

Distribuir la carga suele marcar la diferencia entre una prueba sólida y una débil.

  • Distribuye las peticiones en el tiempo y entre IPs en lugar de saturar un solo objetivo. Con la rotación por petición, la IP ya varía, así que tus principales palancas son la concurrencia y el ritmo temporal.
  • Empieza con una concurrencia moderada, observa tu tasa de éxito y luego escala. Si el éxito baja al forzar más, es que vas demasiado rápido para ese objetivo, no que estés topando con un límite del proxy.
  • Añade retrasos pequeños y variados, y reintenta los fallos con una IP nueva. Con la rotación, el reintento cae de forma natural en una salida distinta, así que trata un bloqueo como una señal leve: reduce el ritmo, reintenta y continúa.

Elige el producto que encaja con la carga de trabajo

Sección titulada «Elige el producto que encaja con la carga de trabajo»

Elegir el producto equivocado es la razón más común por la que una prueba rinde por debajo de lo esperado.

  • Residential Proxies: IPs residenciales rotativas, de forma que el tráfico parece proceder de muchos usuarios reales. Scraping, monitorización, verificación de anuncios, estudios de mercado y recopilación de SERP.
  • ISP Proxies: la misma ciudad y el mismo ISP (ASN) durante todo el periodo de facturación. Gestión de cuentas, sesiones largas de pago o inicio de sesión, y comprobaciones de anuncios desde una ciudad e ISP específicos.

Si no estás seguro, revisa Choosing a product.

Evalúa según tus cifras reales, no un puñado de llamadas de prueba.

  • Observa tu tasa de éxito y la calidad de los datos a un volumen similar al de producción. Un puñado de fallos es normal; lo que importa es la tasa a escala.
  • Confirma que la salida es la que pediste enviando una petición a través del proxy a un endpoint de consulta de IP como IP Info (http://ip-info.com/json), y comprobando la IP y el país.
  • Si los resultados no cuadran, revisa tres cosas antes de culpar a la red: que la rotación frente a sesión coincida con la tarea, que la ubicación de destino esté configurada correctamente y que la concurrencia no sea demasiado alta.

Cuanto más se parezca tu prueba a producción en tráfico, objetivos y ritmo temporal, más te dirá realmente la prueba. Configúrala para que se parezca a la situación real, y la decisión se toma sola.