La mayoría de las personas que compran proxies por primera vez lo abordan como una única pregunta, qué plan, y terminan eligiendo solo por el precio. Eso suele producir uno de dos resultados: un plan demasiado pequeño para el trabajo, descubierto a mitad de mes, o un plan comprado para una capacidad que nunca se llega a usar. Ninguno de los dos es realmente un error de precio. Ambos vienen de saltarse las dos decisiones que deberían tomarse antes de mirar siquiera un precio.
Elegir bien son tres decisiones en orden: qué tipo de proxy necesita tu proyecto, cuánto ancho de banda consumirá realmente ese proyecto, y qué funciones son genuinamente necesarias en lugar de simplemente estar listadas. Si aciertas en eso, el plan se elige solo.
Decisión uno: qué producto necesita tu proyecto
Los tipos de producto no son niveles de la misma cosa. Se comportan de forma distinta, y elegir el equivocado no se arregla comprando más cantidad de él.
Residencial rotativo es la opción por defecto para la recolección de datos. Extraes de un gran pool de direcciones domésticas reales, y por defecto cada solicitud sale por una diferente, lo que reparte tu volumen para que ninguna dirección concreta llame la atención. Elige esto cuando el trabajo sea scraping, monitorización de precios o disponibilidad, recolección de SERP y rankings, verificación de anuncios, o cualquier tarea cuya forma sea muchas solicitudes a muchos objetivos o mercados.
Residencial estático, o proxies ISP, son direcciones alojadas registradas a un proveedor de internet de consumo, por lo que tienen la confianza propia de lo residencial pero se mantienen iguales con el tiempo. Elige esto cuando la persistencia es el requisito en lugar del volumen: gestionar cuentas que deberían verse siempre desde la misma dirección, sesiones de larga duración, o cualquier caso en el que una dirección que cambie debajo de ti sea el problema y no la solución. El compromiso se trata en ISP frente a residencial y qué son los proxies residenciales estáticos.
Datacenter es el más barato y rápido, y es la respuesta correcta cuando a tus objetivos no les importa. Si accedes a una API abierta, tu propia infraestructura, o sitios sin defensas relevantes, pagar precios residenciales es un desperdicio. La comparación honesta está en residencial frente a datacenter.
La regla práctica es usar el tipo más barato que supere de forma fiable tus objetivos reales, y establecer eso mediante pruebas en lugar de suposiciones. Muchos proyectos terminan siendo mixtos: datacenter para las fuentes fáciles, residencial para las defendidas.
Decisión dos: cuánto ancho de banda
Los proxies residenciales se facturan por datos transferidos en lugar de por el número de direcciones que tocas, así que el ancho de banda es el número que determina tu plan. El razonamiento detrás de ese modelo está en por qué la era del per-port ha terminado, y el método de dimensionamiento es sencillo.
Calcula el tamaño medio de una respuesta de tus objetivos, multiplícalo por el número de solicitudes que esperas en un mes, y añade margen para reintentos y fallos. Una página HTML plana o una respuesta de API JSON suele ser de decenas de kilobytes; una página completa renderizada en un navegador, con imágenes, fuentes y scripts, puede ser de varios megabytes, lo que es la variable individual más grande de todo el cálculo. Diez mil llamadas JSON al día son un plan muy distinto de diez mil páginas completamente renderizadas al día, y la diferencia es de aproximadamente dos órdenes de magnitud. El método detallado está en estimar el ancho de banda mensual.
Dos cosas reducen esa cifra antes de comprar. Obtener el endpoint de datos subyacente en lugar de renderizar la página completa es la palanca más grande, y bloquear imágenes, medios y fuentes cuando genuinamente hay que renderizar es la segunda, ambas tratadas en reducir los costes de ancho de banda de proxy. Merece la pena hacer esa optimización antes de dimensionar un plan, porque puede hacerte bajar de nivel.
Fíjate en lo que no está en esta lista: cuántas IPs obtienes. En una red agrupada eso no es la cantidad que compras, y el razonamiento está en cuántas IPs de proxy necesitas realmente. La única excepción son las sesiones fijas concurrentes, que es un requisito real que hay que especificar si tu trabajo necesita identidades mantenidas.
Decisión tres: qué funciones son realmente necesarias
Las listas de funciones son donde los planes empiezan a parecer complicados. La mayor parte se reduce a cinco preguntas.
Granularidad geográfica. La segmentación por país cubre la mayoría de proyectos. Si tu trabajo depende de resultados locales, precios locales o datos a nivel de tienda, necesitas segmentación a nivel de ciudad, y si tratas con comportamiento específico de operadora necesitas segmentación por ASN. Comprueba que los países que te importan estén bien cubiertos, no solo que se anuncie una gran cifra global.
Control de sesión. Confirma que puedes tanto rotar por solicitud como mantener una sesión fija cuando un flujo de varios pasos lo necesite. La mayoría de proyectos reales necesitan ambas cosas en distintos momentos.
Concurrencia. Pregunta qué límite se aplica a las conexiones simultáneas, porque un plan que mide la concurrencia por separado limitará un trabajo que un plan basado solo en ancho de banda ejecutaría sin problemas. Consulta conexiones concurrentes ilimitadas.
Protocolos e integración. HTTP y SOCKS5 cubren casi todo; lo que importa más es que la segmentación se exprese de una forma que tu stack pueda controlar por solicitud, lo que en una puerta de enlace significa credenciales en el nombre de usuario en lugar de un interruptor en un panel.
Todo lo demás suele ser secundario hasta que operas a gran escala, momento en el que la capacidad de respuesta del soporte y la flexibilidad de facturación empiezan a importar más que cualquier casilla de funciones.
Emparejar formas comunes de proyecto con planes
Unos pocos patrones cubren la mayoría de primeras compras.
Un proyecto pequeño de investigación o monitorización, que rastrea unos pocos cientos de páginas al día, suele ser unos pocos gigabytes al mes en residencial rotativo con segmentación por país. Empieza por el nivel más pequeño que cubra tu estimación con margen, ya que subir de nivel después es fácil y comprar un nivel grande para un proyecto que aún no has validado no lo es.
Un pipeline de scraping en producción a través de muchos objetivos es donde la estimación de ancho de banda demuestra su valor, y donde el trabajo de optimización se rentabiliza directamente. Dimensiona según el uso medido en una prueba en lugar de una suposición, y espera que la cifra real difiera de tu estimación en ambas direcciones.
El trabajo basado en cuentas o sesiones apunta hacia direcciones ISP estáticas y un número declarado de sesiones concurrentes en lugar de un gran pool rotativo.
Las cargas de trabajo mixtas son habituales y están bien: datacenter para fuentes sin defensas, residencial para el resto. Dimensionar cada una por separado es más barato que hacer pasar todo por la vía cara.
Valida antes de comprometerte
Sea cual sea tu conclusión, trátala como una hipótesis y pruébala en una prueba o en una primera compra pequeña antes de escalar. Ejecuta contra tus objetivos reales, no una URL de prueba genérica, y mide la tasa de éxito con validación de la respuesta en lugar de solo con los códigos de estado, ya que una página de desafío devuelta con un 200 parecerá, de otro modo, un éxito. Confirma que la geografía que has pagado es la geografía que obtienes. Mide los bytes reales por solicitud para que tu estimación de ancho de banda se convierta en una medición. El método está en probar velocidad, tasa de éxito y precisión de ubicación, y los criterios a nivel de proveedor están en cómo elegir una red de proxies.
Una semana de uso real te dice más que cualquier hoja de especificaciones, y convierte las tres decisiones anteriores de estimaciones en hechos.
La conclusión
Elige el tipo de producto según lo que exijan tus objetivos, no según el precio: residencial rotativo para volumen y geografía, ISP estático para persistencia, datacenter donde a los objetivos no les importe. Dimensiona el plan por ancho de banda, lo que significa estimar el tamaño de la respuesta multiplicado por el volumen de solicitudes y optimizar lo que obtienes antes de comprar, ya que eso por sí solo puede hacerte bajar de nivel. Exige solo las funciones que tu proyecto realmente usa, siendo la granularidad geográfica y el control de sesión las dos que más suelen importar. Luego valida contra objetivos reales antes de escalar, porque el uso medido supera a cualquier estimación.
Si eso te lleva hacia el residencial rotativo, proxies residenciales te ofrecen segmentación por país y ciudad, rotación por defecto, y sesiones fijas cuando un flujo lo necesita, con precios por GB para que el plan siga el ritmo de los datos que realmente mueves en lugar de un recuento de puestos o una asignación de puertos.