Los proxies residenciales son lo que vendemos, así que puede parecer extraño que escribamos sobre cuándo no se necesita uno. Pero los equipos que compran proxies para cada tarea gastan de más, y los equipos que culpan al proxy de cada fallo pierden semanas. Saber qué sitios necesitan una IP residencial, cuáles no necesitan nada y cuáles necesitan algo completamente distinto es la optimización más barata en la recolección de datos web.
Para concretarlo, hicimos una pequeña prueba. El 9 de octubre de 2026 solicitamos 30 páginas públicas, tres veces cada una, desde un servidor en la nube con una dirección IP de centro de datos, y después de nuevo a través de proxies residenciales de Shifter con salidas en EE. UU. Ambas ejecuciones usaron el mismo cliente HTTP simple en Python. Dieciséis de las 30 páginas funcionaron desde la IP de centro de datos todas las veces. Tres funcionaron solo a través de salidas residenciales. Las once restantes fallaron en ambos casos, por razones que una IP residencial no soluciona.
La prueba
Los objetivos abarcaban seis tipos de sitio: APIs públicas y datos abiertos, sitios de referencia y documentación, portadas de noticias, páginas de búsqueda de comercio electrónico, páginas de búsqueda de viajes, y un conjunto de páginas de redes sociales, empleo y búsqueda. Cada solicitud usó el mismo User-Agent de navegador de escritorio y se comprobó que contuviera contenido real, no solo un código de estado: una respuesta solo se contaba como éxito si contenía un marcador que aparece únicamente en el contenido real, como la tarjeta de un resultado de búsqueda. Las páginas de bloqueo que devuelven el estado 200, algo habitual, por tanto se contaron como fallos.
Elegimos los marcadores inspeccionando respuestas guardadas de ambas redes antes de la ejecución final, y descartamos cinco páginas candidatas en las que no podíamos distinguir contenido real de un muro de inicio de sesión o de una capa vacía de JavaScript.
| Categoría | Sitio | IP de centro de datos | Salidas residenciales | Veredicto |
|---|---|---|---|---|
| APIs públicas y datos abiertos | en.wikipedia.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| APIs públicas y datos abiertos | api.github.com | 3 de 3 | 3 de 3 | No se necesita proxy |
| APIs públicas y datos abiertos | data.sec.gov | 3 de 3 | 3 de 3 | No se necesita proxy |
| APIs públicas y datos abiertos | api.worldbank.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| APIs públicas y datos abiertos | ecb.europa.eu | 3 de 3 | 3 de 3 | No se necesita proxy |
| Referencia y documentación | docs.python.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| Referencia y documentación | developer.mozilla.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| Referencia y documentación | rfc-editor.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| Referencia y documentación | en.wikipedia.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| Referencia y documentación | arxiv.org | 3 de 3 | 3 de 3 | No se necesita proxy |
| Referencia y documentación | stackoverflow.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Noticias | bbc.com | 3 de 3 | 3 de 3 | No se necesita proxy |
| Noticias | reuters.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Noticias | nytimes.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Noticias | theguardian.com | 3 de 3 | 3 de 3 | No se necesita proxy |
| Noticias | edition.cnn.com | 3 de 3 | 3 de 3 | No se necesita proxy |
| Noticias | bloomberg.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Búsqueda de comercio electrónico | amazon.com | 3 de 3 | 2 de 3 | No se necesita proxy |
| Búsqueda de comercio electrónico | walmart.com | 0 de 3 | 3 de 3 | Se necesita IP residencial |
| Búsqueda de comercio electrónico | ebay.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Búsqueda de comercio electrónico | bestbuy.com | 0 de 3 | 0 de 3 | Tiempo de espera agotado en ambos casos |
| Búsqueda de comercio electrónico | etsy.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Viajes | booking.com | 0 de 3 | 2 de 3 | Se necesita IP residencial |
| Viajes | expedia.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Viajes | airbnb.com | 3 de 3 | 2 de 3 | No se necesita proxy |
| Viajes | tripadvisor.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Viajes | kayak.com | 0 de 3 | 3 de 3 | Se necesita IP residencial |
| Redes sociales, empleo y búsqueda | linkedin.com | 3 de 3 | 3 de 3 | No se necesita proxy |
| Redes sociales, empleo y búsqueda | indeed.com | 0 de 3 | 0 de 3 | Bloqueado en ambos casos |
| Redes sociales, empleo y búsqueda | google.com | 0 de 3 | 0 de 3 | Necesita un navegador |
“Bloqueado en ambos casos” significa que un cliente HTTP sencillo fue bloqueado desde ambas redes. Un navegador real o una API de scraping que gestione las comprobaciones del navegador bien podrían tener éxito en esos sitios; esta prueba no lo intentó.
Qué dicen los resultados
Las APIs públicas, los datos abiertos y la documentación no necesitan proxy. Todas las APIs y páginas de referencia que probamos, salvo una, funcionaron desde una IP de centro de datos en todos los intentos. Estos servicios están diseñados para que los usen programas. Lo que quieren es un User-Agent descriptivo, tasas de solicitud razonables y, en algunos casos, una clave de API. Un proxy añade coste y nada más.
Muchos sitios grandes no bloquean en absoluto las IP de centro de datos. Tres de las seis portadas de noticias, la búsqueda de Amazon, la búsqueda de Airbnb y una página de empresa de LinkedIn sirvieron contenido real a un servidor en la nube tres de tres veces. Para la recolección de bajo volumen en sitios como estos, empezar sin proxy es razonable, siempre que se respeten los términos y los límites de tasa del sitio.
Algunos sitios bloquean por reputación de IP, y ahí es donde importan las salidas residenciales. Walmart, Kayak y Booking.com rechazaron la IP de centro de datos todas las veces y sirvieron contenido a través de salidas residenciales. Estos sitios puntúan la red desde la que llega una solicitud, y la dirección de un servidor en la nube puntúa mal. Este es el caso para el que existen los proxies residenciales.
Algunos sitios bloquean al cliente, no a la IP. eBay, Etsy, Expedia, Tripadvisor, Indeed, Stack Overflow y tres sitios de noticias bloquearon el cliente Python sencillo desde ambas redes. Comprueban cómo se conecta y se comporta el cliente, como su huella de TLS, sus cabeceras HTTP y si ejecuta JavaScript, antes de fijarse en de dónde viene. Una IP residencial no arregla un cliente que se anuncia como un script. Nuestra guía sobre huella digital de TLS y HTTP/2 explica cómo funcionan esas comprobaciones.
Algunas páginas necesitan un navegador sea cual sea la red. Google Search devolvió una página que pedía JavaScript a ambas redes, sin resultados en el HTML. Para páginas así, la elección está entre un navegador sin interfaz y una API que devuelva los datos directamente.
Cómo saber qué necesita un sitio
Puedes clasificar la mayoría de los objetivos en estos grupos en una tarde, antes de comprar nada. La función de abajo es la comprobación que usamos en la prueba: obtiene una página y decide si has conseguido el contenido real, un bloqueo, un error o una capa vacía.
import re
import requests
BLOCK = re.compile(r"captcha|access denied|are you a robot|just a moment|unusual traffic|"
r"verify you are human|request blocked|pardon our interruption|enable javascript and cookies",
re.IGNORECASE)
HEADERS = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
}
def check(url, marker, proxies=None):
"""Did this request get the real content, or a block, an error or an empty shell?"""
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=30)
except requests.RequestException as error:
return {"url": url, "result": "error", "detail": type(error).__name__}
body = response.text
if response.status_code != 200:
result = "blocked" if response.status_code in (202, 401, 403, 429, 503) else "error"
elif BLOCK.search(body[:20000]) and marker.lower() not in body.lower():
result = "blocked"
elif marker.lower() not in body.lower():
result = "no content"
else:
result = "ok"
return {"url": url, "result": result, "status": response.status_code, "bytes": len(response.content)}Elige un marcador que solo aparezca en el contenido que quieres, como el nombre de clase de una tarjeta de resultado o un campo en una respuesta JSON. No uses una palabra del título de la página: las páginas de bloqueo y los muros de inicio de sesión a menudo lo repiten. Luego ejecútalo sobre algunas páginas de cada objetivo:
from check import check
print(check("https://api.github.com/repos/python/cpython", '"full_name"'))
print(check("https://www.ebay.com/sch/i.html?_nkw=laptop", "srp-results")){'url': 'https://api.github.com/repos/python/cpython', 'result': 'ok', 'status': 200, 'bytes': 6617}
{'url': 'https://www.ebay.com/sch/i.html?_nkw=laptop', 'result': 'blocked', 'status': 403, 'bytes': 1832}Ejecútalo desde donde realmente se ejecutará tu scraper (un servidor en la nube, no tu portátil, si ahí es donde vive la producción), varias veces a lo largo de un día. Los resultados se traducen en una decisión:
| Lo que ves desde un servidor en la nube | Lo que suele significar | Qué usar |
|---|---|---|
| Contenido real, de forma constante | El sitio no bloquea el tráfico de centro de datos a tu volumen | Sin proxy, o una IP de centro de datos para escalar |
| Bloqueos o retos, y contenido real desde una conexión doméstica | El sitio bloquea por reputación de IP | Proxies residenciales |
| Bloqueos desde todas las redes | El sitio comprueba al cliente | Un navegador real o una API de scraping, normalmente con IP residenciales debajo |
| Capas vacías sin datos | El contenido se renderiza mediante JavaScript | Un navegador sin interfaz, o la API que llama la página |
| Muros de inicio de sesión | El contenido no es público | No lo recolectes sin permiso |
Dos matices:
- El volumen cambia la respuesta. Un sitio que ignora diez solicitudes desde un servidor en la nube puede bloquear diez mil. Vuelve a probar a la tasa a la que planeas operar, no solo una vez.
- La ubicación cambia la respuesta. Los sitios sirven contenido distinto y aplican reglas distintas según el país. Si necesitas datos tal como se ven desde Alemania, prueba desde Alemania.
Las opciones intermedias
La elección no es solo entre ningún proxy y proxies residenciales.
- Las IP de centro de datos son baratas y rápidas, y sirven bien para sitios que no las bloquean. Nuestra comparativa de proxies ISP y de centro de datos cubre cuándo son suficientes.
- Los proxies ISP son direcciones estáticas registradas a proveedores de internet de consumo. Son adecuados para sesiones largas e inicios de sesión en tus propias cuentas, donde quieres la misma IP durante días. Los proxies ISP de Shifter vienen con tráfico ilimitado, por lo que también son adecuados para cargas de trabajo intensas y constantes en sitios que los aceptan.
- Una API de scraping gestiona el navegador, los reintentos y la elección de IP por ti, y cobra por página conseguida en lugar de por gigabyte. A menudo es la opción más barata para sitios que comprueban al cliente, porque no tienes que construir y mantener tú mismo la capa de navegador. Consulta nuestra guía sobre scraping de sitios con mucho JavaScript.
- Los proxies residenciales son la herramienta adecuada cuando un sitio juzga la red desde la que llega una solicitud: cuando el mismo cliente tiene éxito desde una conexión doméstica y falla desde un servidor en la nube.
Preguntas frecuentes
¿Necesito un proxy para hacer web scraping?
No siempre. En nuestra prueba, 16 de 30 páginas públicas, incluidas todas las APIs públicas y la mayoría de los sitios de documentación, sirvieron contenido real a un servidor en la nube sin proxy. Prueba tus objetivos primero, desde donde se ejecutará tu scraper.
¿Cuándo necesito un proxy residencial?
Cuando un sitio bloquea las solicitudes desde IP de centro de datos pero sirve al mismo cliente desde una conexión doméstica. En nuestra prueba, tres de 30 sitios (Walmart, Kayak y Booking.com) se comportaron así.
¿Por qué sigo bloqueado con un proxy residencial?
Normalmente porque el sitio está comprobando al cliente, no a la IP. Muchos sitios bloquean clientes HTTP cuya huella de TLS, cabeceras o falta de JavaScript los identifican como scripts. Once de las 30 páginas de nuestra prueba fallaron desde ambas redes con un cliente Python sencillo. La solución es un navegador real o una API de scraping, no una IP distinta.
¿Son suficientes los proxies de centro de datos para hacer scraping?
Para APIs públicas, documentación, muchos sitios de noticias y algunos grandes minoristas, sí, a volúmenes moderados. Para sitios que puntúan la reputación de la IP, no. Prueba cada objetivo en lugar de asumir.
Conclusión
Un proxy residencial resuelve un problema concreto: un sitio que juzga las solicitudes por la red desde la que llegan. No ayuda con sitios que comprueban al cliente, y es innecesario para APIs públicas y sitios que no bloquean el tráfico en la nube. Prueba cada objetivo desde donde se ejecutará tu scraper, clasifícalo en uno de esos grupos, y paga por tráfico residencial solo donde cambie el resultado. Nuestras buenas prácticas de web scraping cubren el resto de la recolección responsable.