Las residential proxies son lo que vendemos, así que puede parecer extraño que escribamos sobre cuándo no se necesita una. 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 recopilación de datos web.
Para concretar esto, realizamos 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 luego 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.
Nuestra prueba: 30 páginas, IP de centro de datos frente a proxies residenciales
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 sociales, de empleo y de búsqueda. Cada solicitud usó el mismo User-Agent de navegador de escritorio y se comprobó en busca de contenido real, no solo un código de estado: una respuesta solo se contó como éxito si contenía un marcador que aparece únicamente en el contenido real, como una tarjeta de resultado de búsqueda. Las páginas de bloqueo que devuelven el estado 200, que son comunes, se contaron por tanto 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 pudimos distinguir el contenido real de un muro de inicio de sesión o 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 de navegador bien podrían tener éxito en esos sitios; esta prueba no lo intentó.
Por categoría, los resultados se suman así:
| Categoría | Páginas | No se necesita proxy | Se necesita IP residencial | Falló en ambos casos |
|---|---|---|---|---|
| APIs públicas y datos abiertos | 5 | 5 | 0 | 0 |
| Referencia y documentación | 6 | 5 | 0 | 1 |
| Noticias | 6 | 3 | 0 | 3 |
| Búsqueda de comercio electrónico | 5 | 1 | 1 | 3 |
| Viajes | 5 | 1 | 2 | 2 |
| Redes sociales, empleo y búsqueda | 3 | 1 | 0 | 2 |
| Total | 30 | 16 | 3 | 11 |
Qué muestra la prueba de 30 páginas
Las APIs públicas, los datos abiertos y la documentación no necesitan proxy. Todas las APIs y páginas de referencia que probamos, excepto una, funcionaron desde una IP de centro de datos en todos los intentos. Estos servicios están construidos para ser usados por programas. Lo que quieren es un User-Agent descriptivo, tasas de solicitud razonables y, para algunos, 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 recopilación de bajo volumen desde sitios como estos, empezar sin proxy es razonable, siempre que se respeten los términos y los límites de tasa del sitio.
Amazon y Airbnb funcionaron tres de tres veces desde la IP de centro de datos y dos de tres a través de salidas residenciales. Con tres intentos por sitio, un fallo está dentro de la variación normal, no es prueba de que las IP residenciales rindan peor ahí. Cada solicitud residencial sale desde una conexión doméstica distinta, y una salida concreta puede ser lenta, o haber sido vista recientemente por el mismo sitio, de una forma en que un servidor fijo en la nube no lo es. La lección es probar varias veces antes de decidir, lo que la comprobación de abajo facilita.
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 al cliente sencillo en Python desde ambas redes. Comprueban cómo se conecta y se comporta el cliente, como su huella 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 la huella TLS y HTTP/2 explica cómo funcionan esas comprobaciones.
Algunas páginas necesitan un navegador sea cual sea la red. La búsqueda de Google devolvió una página pidiendo JavaScript a ambas redes, sin resultados en el HTML. Para páginas así, la elección es entre un navegador sin interfaz (headless) y una API que devuelva los datos directamente.
Cómo saber qué necesita un sitio
Se puede 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 se consiguió 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 la repiten. Luego ejecútalo en 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 es ahí donde vive la producción), varias veces a lo largo de un día. Los resultados se corresponden con una decisión:
| Qué ves desde un servidor en la nube | Qué suele significar | Qué usar |
|---|---|---|
| Contenido real, de forma consistente | El sitio no bloquea el tráfico de centros de datos a tu volumen | Ningún 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 el cliente | Un navegador real o una API de scraping, normalmente con IP residenciales por 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 recopiles 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 al ritmo al que planeas operar, no solo una vez.
- La ubicación cambia la respuesta. Los sitios sirven contenido diferente y aplican reglas distintas según el país. Si necesitas datos tal como se ven desde Alemania, prueba desde Alemania.
Cuándo los datos específicos de ubicación necesitan un proxy residencial
Nuestra prueba planteaba una pregunta: ¿sirve el sitio su contenido en absoluto? Una segunda pregunta a menudo importa más: ¿sirve el contenido que vería una persona real en un lugar determinado?
Un servidor en la nube se encuentra en un puñado de ubicaciones de centros de datos, y muchos sitios reconocen las direcciones de centro de datos y les muestran una versión por defecto: la página de inicio global, precios en dólares estadounidenses, sin existencias locales, o sin anuncios en absoluto. Si tu trabajo depende de lo que ven los usuarios en un país o ciudad concretos, necesitas una salida allí, en una red que esos usuarios realmente usen. Esto cubre:
- Resultados y clasificaciones de búsqueda locales, que cambian según la ciudad.
- Precios, disponibilidad y opciones de entrega, que los minoristas y los sitios de viajes fijan por mercado.
- Anuncios y páginas de aterrizaje, que los anunciantes orientan por ubicación y que a menudo no se muestran al tráfico de centros de datos. Comprobarlos es el núcleo de la verificación de anuncios.
- Contenido con licencia o restringido por país.
En estos casos el sitio puede no bloquear nunca una IP de centro de datos, y aun así recopilarías los datos equivocados sin una salida residencial en el lugar correcto.
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 comparación de proxies ISP y de centro de datos cubre cuándo son suficientes.
- Los proxies ISP son direcciones registradas a proveedores de internet de consumo, mantenidas para ti durante un periodo más largo. Son adecuados para sesiones largas e inicios de sesión en tus propias cuentas. Los proxies ISP de Shifter permanecen en la ciudad y en el ISP (ASN) que elijas durante todo el periodo de facturación y vienen con tráfico ilimitado, por lo que también sirven para cargas de trabajo pesadas y constantes en sitios que los acepten.
- 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 el 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, incluyendo 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 primero tus objetivos, 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?
Generalmente porque el sitio está comprobando el cliente, no la IP. Muchos sitios bloquean clientes HTTP cuya huella 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 sencillo en Python. 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 el 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 IP, no. Prueba cada objetivo en lugar de dar por sentado.
¿Cuál es la diferencia entre una IP de centro de datos y una IP residencial?
Una IP de centro de datos pertenece a un proveedor de alojamiento o de nube. Una IP residencial pertenece a un proveedor de internet de consumo y la usa una conexión doméstica real. Muchos sitios confían más en las direcciones residenciales, porque los visitantes normales las usan.
¿Cómo compruebo si un sitio bloquea las IP de centro de datos?
Solicita algunas páginas desde un servidor en la nube y comprueba la respuesta en busca de un marcador que solo aparezca en el contenido real, no solo el código de estado. Luego repite a través de una salida residencial. Si se rechaza al servidor en la nube y se sirve a la salida residencial, el sitio bloquea por reputación de IP.
¿Necesito un proxy residencial para datos específicos de ubicación?
Normalmente, sí. Incluso los sitios que nunca bloquean servidores en la nube a menudo les muestran una versión por defecto de la página. Para ver los resultados, precios o anuncios locales que ven los usuarios de un país o ciudad, necesitas una salida en ese lugar.
¿Por qué funcionaron Amazon y Airbnb con menos frecuencia a través de proxies residenciales en vuestra prueba?
Cada uno falló una vez en tres intentos residenciales, lo que está dentro de la variación normal para tres intentos. Cada solicitud residencial sale desde una conexión doméstica distinta, y una salida concreta puede ser lenta o haber sido vista recientemente por el sitio. Prueba varias veces antes de sacar una conclusión.
La conclusión
Un proxy residencial resuelve un problema específico: un sitio que juzga las solicitudes por la red desde la que llegan. No ayuda con sitios que comprueban el 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 recopilación responsable.