Un script de recolección funciona en el ordenador (computadora) de casa y falla en el servidor. La petición ni siquiera devuelve la página: llega una pantalla de desafío, un error de acceso o una respuesta vacía. En la mayoría de los casos, el motivo no está en el código: está en el tipo de dirección desde la que sale la petición.
Cómo sabe el sitio que es datacenter
Toda IP pertenece a un bloque de direcciones anunciado por una organización, identificada por un ASN. Las bases de clasificación de redes asocian cada ASN a un tipo:
- proveedor de internet residencial;
- operador móvil;
- proveedor de hosting y nube (datacenter);
- red corporativa o educativa.
Cuando llega una petición, la capa de protección del sitio puede consultar esa clasificación en milisegundos. Una dirección de datacenter significa "aquí detrás hay un servidor".
Por qué eso provoca el bloqueo
Ser un servidor no está prohibido. El problema es estadístico: las personas navegan con conexiones domésticas o móviles; el tráfico de datacenter, en volumen, suele ser automatización. Para los sitios que quieren limitar robots, el origen de hosting es una señal barata y rápida de filtrar.
Qué es un bloqueo en el borde
Los sitios grandes suelen tener una capa de protección delante de la aplicación: un servicio que recibe todas las conexiones y decide cuáles pasan. Cuando esa capa rechaza una petición, la página ni siquiera se procesa: es lo que se llama bloqueo en el borde.
Es lo que ocurre, por ejemplo, en portales que están detrás de un desafío gestionado y frenan las direcciones de datacenter antes de entregar el contenido. En esos casos, ninguna optimización del código lo resuelve mientras el origen siga siendo de hosting.
Si lo que ves es un aviso del tipo "proxy o VPN detectado" en una web o app de consumo, el mecanismo es parecido y lo explicamos en proxy o VPN detectado.
Cómo identificar si es el tipo de IP
| Prueba | Resultado | Lectura |
|---|---|---|
| Misma petición desde la conexión de casa | Funciona | El origen del servidor es la causa probable |
| Misma petición desde otro datacenter | Falla igual | Confirma el bloqueo por tipo de red |
| Misma petición con cabeceras de navegador | Sigue fallando | No es solo la identificación del cliente |
| Misma petición más despacio | Sigue fallando | No es solo un límite de frecuencia |
Qué cambia con una IP residencial
El proxy residencial sale por conexiones domésticas reales, clasificadas como proveedor residencial. La petición pasa a leerse como si viniera de una persona, no de un servidor.
Eso resuelve la clasificación de la red. No resuelve:
- volumen abusivo: una dirección residencial haciendo miles de peticiones por minuto sigue llamando la atención;
- comportamiento de robot: patrones idénticos y sin pausas;
- términos de uso: si el sitio prohíbe la recolección, cambiar el tipo de IP no cambia eso.
Cuándo el datacenter sigue siendo la opción correcta
- APIs y sitios que aceptan conexiones de servidor con normalidad.
- Cuentas y paneles sin fricción ligada al origen.
- Volumen alto en destinos compatibles, con un coste por IP mucho menor.
La comparación entre residencial, ISP y datacenter, con el mecanismo de cada uno, está en residencial vs datacenter.
Resumen
- Falla en el servidor y funciona en casa → prueba la clasificación de la red.
- Confirmado el bloqueo por tipo de IP → la residencial resuelve el origen.
- El volumen, el comportamiento y los términos de uso siguen contando con cualquier IP.
Cuándo usar residencial rotativo, cuándo no, y cómo se cobra, está en proxies residenciales. Nuestro residencial rotativo por GB sale con IP de Brasil; si necesitas una IP fija de otro país, mira el proxy ISP residencial estático, con el país elegido en el checkout.