Esta es la lista de comprobación previa para un primer proyecto de proxies residenciales: las cosas que confirmar, en el orden que hace que cada una sea barata de corregir. Se asume que sabes más o menos qué es un proxy, y si no es así, empieza con residential proxies for beginners y vuelve después.
Recórrela de arriba a abajo y evitarás los fallos que normalmente cuestan a un primer proyecto varias semanas: un plan dimensionado para la carga de trabajo equivocada, un proceso que parece funcionar pero no recopila nada, y una factura que nadie había previsto.
Antes de escribir código
1. Confirma que realmente necesitas residential. Si tus objetivos no examinan el tráfico con detalle, una infraestructura más económica hará el mismo trabajo. Prueba primero un objetivo desde una conexión normal y desde una dirección de datacenter; si ambas funcionan, te has ahorrado el sobrecoste. La comparación está en residential versus datacenter.
2. Decide entre rotating o static. Rotating para recopilación a volumen, direcciones ISP static cuando algo necesita persistir, como una cuenta o una sesión larga. Equivocarse aquí no se soluciona comprando más de lo que no toca, según shared versus dedicated.
3. Enumera tus mercados. Qué países, y si algún trabajo necesita precisión a nivel de ciudad. Esto determina tanto tu targeting como si la profundidad del pool en esos mercados es algo que hay que comprobar, según country availability.
4. Estima el ancho de banda antes de elegir un plan. Tamaño de la respuesta multiplicado por el volumen de peticiones, más margen para reintentos. El factor individual más importante es si obtienes datos de endpoints o renderizas páginas completas, lo cual puede diferir en un factor de cien, así que resuelve eso primero, según estimating monthly bandwidth.
Primera conexión
5. Consigue que una petición básica funcione. Sin flags de targeting, sin sesión, nada elaborado:
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonSi esto falla, nada más importa todavía. Un 407 significa credenciales o un nombre de usuario mal formado; elimina todo y añádelo de nuevo pieza por pieza, según fixing 407 errors.
6. Confirma la rotación. Ejecuta ese comando varias veces y comprueba que la dirección cambia. Si no cambia, y especialmente si cambia desde la línea de comandos pero no desde tu código, la causa es casi con toda seguridad la reutilización de conexiones en tu cliente HTTP y no el proxy, según IP not rotating.
7. Confirma la geografía. Solicita un país y verifica dos cosas: que la dirección de salida reporte ese país, y más importante aún, que un objetivo sensible a la geolocalización se comporte como si estuvieras allí, con moneda e idioma locales. Las bases de datos y la opinión propia del objetivo no siempre coinciden, y la del objetivo es la que importa.
8. Configura ambas entradas de proxy y gestiona los caracteres especiales. En el código, configura las entradas HTTP y HTTPS, no solo una, y codifica en percent-encoding una contraseña que contenga caracteres con significado especial en una URL. La referencia de formato está en how to connect.
Antes de escalar
9. Haz que tu petición coincida con tu salida. Envía un conjunto completo de cabeceras con forma de navegador en lugar de un User-Agent aislado, y vincula Accept-Language al país de salida para que ambos no se contradigan. Si controlas un navegador, ajusta también el locale y la zona horaria para que coincidan. Detalles en setting the right headers.
10. Valida los cuerpos de respuesta, no los códigos de estado. Esta es la comprobación que separa un pipeline que funciona de uno que recopila silenciosamente nada. Define, por objetivo, un marcador que solo aparezca en una página genuinamente buena, y cuenta una respuesta como éxito solo si lo cumple. Una página de challenge que devuelve 200 es el fallo más costoso en este trabajo, según detecting blocked or fake content.
11. Añade pacing y reintentos sensatos antes del volumen, no después. Un límite de tasa por objetivo con jitter, un tope de concurrencia, y una lógica de reintentos que clasifique los fallos en lugar de bucle infinito. En concreto: espera ante señales de límite de tasa en lugar de rotar direcciones para mantener el mismo ritmo, y nunca reintentes un error terminal. Ver rate limiting and throttling y retry logic.
12. Establece un límite de coste. Registra los bytes por petición y configura una alerta bastante antes de agotar la asignación de tu plan, porque la sorpresa habitual en un primer proyecto es un trabajo de renderizado que consume un mes de ancho de banda en tres días. Las palancas están en cutting bandwidth costs.
La verificación de cinco minutos
Antes de dejar nada funcionando sin supervisión, confirma todo esto en una ejecución corta:
- La dirección de salida no es la tuya
- Cambia entre peticiones cuando no has solicitado una sesión
- El país coincide con lo solicitado, y el objetivo lo confirma
- Una petición deliberadamente mala se clasifica como fallo en lugar de contarse como éxito
- Los bytes por petición son aproximadamente lo que estimaste
- Una respuesta de límite de tasa provoca una espera en lugar de un reintento inmediato
Si algo de esto falla, corrígelo ahora. Cada uno de estos puntos se vuelve considerablemente más caro una vez que hay un mes de datos construidos encima.
Errores habituales en un primer proyecto
Cuatro que explican la mayoría de los problemas.
Ir a máxima velocidad desde el principio. Los pipelines nuevos suelen escribirse para funcionar tan rápido como el código lo permita, que es la vía más rápida para acabar bloqueado. Empieza despacio y aumenta de forma deliberada.
Confiar en los códigos de estado. Ya se ha tratado antes, y merece la pena repetirlo porque es lo que la gente se salta y lo que corrompe un dataset en silencio.
Renderizar páginas que no necesitaban renderizado. Comprueba si los datos están disponibles desde un endpoint subyacente antes de automatizar un navegador, según when you need a headless browser.
Tratar una sesión sticky como garantizada. Las sesiones son best effort sobre conexiones domésticas reales, así que un flujo debe tolerar que la dirección cambie a mitad de secuencia, según sticky versus rotating.
En resumen
Confirma que realmente necesitas residential, elige rotating o static de forma deliberada, enumera tus mercados, y dimensiona el ancho de banda antes de elegir un plan. Después, consigue que una petición básica funcione antes de añadir nada más, confirma la rotación y la geografía, y configura ambas entradas de proxy en el código. Antes de escalar, haz que tus cabeceras concuerden con tu salida, valida los cuerpos de respuesta en lugar de los códigos de estado, añade pacing y reintentos clasificados, y establece una alerta de coste. Ejecuta la verificación de cinco minutos antes de dejar nada sin supervisión. Casi todos los fallos costosos de un primer proyecto se deben a uno de estos pasos omitidos, y cada uno es más barato de hacer ahora que de incorporar más adelante.
El producto que configuran estos pasos es residential proxies, un gateway con targeting por país y ciudad y sesiones sticky cuando un flujo lo necesita, facturado per GB para que un primer proyecto pequeño siga siendo una primera factura pequeña.