Situación clásica: el script para monitorear precios en Wildberries o Ozon funciona perfectamente en la laptop de casa, pero después de trasladarlo a un VPS comienza a recibir 403, captcha o un bloqueo instantáneo por IP. El desarrollador cambia los encabezados, añade retrasos, pero el resultado no cambia. El problema casi nunca está en el código del parser en sí, sino en el entorno desde el cual hace las solicitudes. Analizamos 7 razones concretas y qué cambiar para que el parser funcione de manera estable en el servidor.
Por qué todo funciona localmente, pero en el servidor hay un bloqueo
Cuando ejecutas el parser desde una computadora de casa, el sitio ve la solicitud desde una IP residencial normal de tu proveedor, desde una región familiar, con un entorno de navegador real, si usas Selenium o Playwright con un perfil auténtico. Tan pronto como el mismo script se traslada a un VPS en Alemania, los Países Bajos o EE. UU., la situación cambia completamente: la IP pertenece a un centro de datos, la huella TLS puede diferir debido a diferentes versiones de bibliotecas, la zona horaria del servidor no coincide con la geolocalización de la IP, y la frecuencia de solicitudes aumenta drásticamente, porque el servidor opera 24/7 sin interrupciones.
Los sistemas anti-bot de Wildberries, Ozon, Avito y la mayoría de los grandes marketplaces ya no solo miran el User-Agent. Analizan la combinación de decenas de señales: tipo de IP, velocidad y regularidad de las solicitudes, comportamiento en la página, correspondencia de encabezados y parámetros TLS, presencia de cookies e historial de sesiones. La máquina local pasa la verificación por casualidad en la mayoría de los puntos, el servidor falla en casi todos. A continuación, un análisis detallado de cada razón.
Razón 1: IP de centro de datos en lugar de IP residencial
Esta es la razón número 1 en el 80% de los casos. Las direcciones IP de VPS y servidores en la nube (AWS, DigitalOcean, Hetzner, hospedajes VDS comunes) están en las bases de datos de centros de datos: los ASN de estos proveedores son públicamente conocidos y utilizados por los sistemas anti-bot para la filtración instantánea de tráfico. Los marketplaces utilizan estas listas en primer lugar, porque el 95% del scraping automatizado proviene precisamente de IP de servidores.
La solución es utilizar IP que visualmente no se diferencien de un usuario normal de Internet. Para el scraping de Wildberries, Ozon y Avito, los proxies residenciales son los más adecuados: son direcciones IP reales de proveedores domésticos, asignadas a abonados comunes. Los sistemas anti-bot ven tal solicitud como tráfico de un usuario real, y no de un servidor en un centro de datos, lo que elimina gran parte de los bloqueos de inmediato.
Razón 2: No hay rotación de IP y límite de frecuencia de solicitudes
En la máquina local, haces de 20 a 50 solicitudes manualmente durante las pruebas, y el sitio no lo nota. En el servidor, el script se ejecuta por cron cada 5 minutos y procesa miles de tarjetas de productos consecutivamente desde una sola IP. Tal patrón es una señal directa para el sistema anti-bot: una persona real no puede abrir 3000 páginas del catálogo en una hora sin una sola pausa.
Es necesario implementar la rotación de IP en el grupo de proxies y limitar el número de solicitudes a una dirección en un período de tiempo. Regla práctica: no más de 30 a 60 solicitudes desde una IP por minuto para las tarjetas de productos, con un cambio automático de dirección después de cada lote de solicitudes. Ejemplo de configuración de rotación en Python a través de un grupo de proxies:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.textAl recolectar un gran volumen de tarjetas por día, es más conveniente usar proxies con rotación automática de IP por solicitud o por temporizador, lo que elimina la necesidad de mantener manualmente una lista de direcciones.
Razón 3: Encabezados y User-Agent no parecen un navegador
Muchos parsers en requests o aiohttp envían solicitudes con un conjunto mínimo de encabezados o con el User-Agent estándar de la biblioteca, que revela inmediatamente el script (por ejemplo, python-requests/2.31.0). En la máquina local, a través del navegador, el conjunto de encabezados es completo: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer y otros; su conjunto se ve natural.
Es necesario copiar el conjunto completo de encabezados de un navegador real, incluyendo el orden en que se envían; algunos sistemas anti-bot incluso verifican esto. Además, es importante rotar el User-Agent sincrónicamente con la versión de la huella TLS (ver el siguiente punto), de lo contrario, la discrepancia entre el encabezado del navegador y el cliente TLS real se convertirá en una nueva señal de bot.
Razón 4: La huella TLS/JA3 revela el script
Esta es una razón menos conocida, pero extremadamente común para los bloqueos, especialmente en el servidor. Las bibliotecas requests, urllib, aiohttp utilizan su propia implementación del handshake TLS, que difiere de la implementación en Chrome o Firefox. Los sistemas anti-bot calculan la huella JA3/JA4 de la conexión TLS, y esta en el script de Python no se parece en nada a la huella de un navegador real, incluso si los encabezados están copiados a la perfección.
La solución es utilizar bibliotecas que emulen la huella TLS de un navegador (por ejemplo, curl_cffi, tls-client en Python, o un navegador headless completo basado en Chromium a través de Playwright/Puppeteer). La segunda opción es trabajar no a través de un cliente HTTP puro, sino a través de un motor de navegador gestionado en combinación con una herramienta anti-detección, donde TLS y los encabezados son formados por un núcleo de navegador real, y no por la emulación de la biblioteca.
Razón 5: Zona horaria, localización y servidores DNS
Si el script emula un navegador a través de Selenium o Playwright, el sistema anti-bot puede verificar la zona horaria del sistema, el idioma de la interfaz, el resolutor DNS e incluso la fuga WebRTC de la IP real del servidor. Un VPS en un centro de datos en Frankfurt con zona horaria del sistema UTC y un proveedor DNS del host, utilizando un proxy con IP de Moscú, crea una discrepancia clara en los datos geográficos; esta es una de las señales más confiables para la detección.
Todos los parámetros del entorno: zona horaria, idioma del navegador, DNS, geolocalización a través de WebRTC, deben coincidir con la región de la dirección IP que se utiliza para la solicitud. Precisamente para resolver esta tarea se han creado navegadores anti-detección: Dolphin Anty, AdsPower, Multilogin, Octo Browser y GoLogin permiten configurar un "perfil de navegador" separado para cada proxy, donde se ajustan automáticamente la zona horaria, la localización, la resolución de pantalla y WebRTC a la geolocalización de la IP.
Razón 6: El patrón de solicitudes es demasiado "robotizado"
Una persona navega por el catálogo con diferentes pausas, hace clic en productos aleatorios, a veces regresa, desplaza la página de manera desigual. El script del servidor generalmente hace solicitudes a intervalos iguales (por ejemplo, estrictamente cada 2 segundos) y solo se dirige a las URL necesarias sin "ruido" alrededor, sin cargar imágenes, scripts, sin visitar la página principal antes de la tarjeta del producto.
Qué cambiar: añadir retrasos aleatorios (no fijos de 2 segundos, sino aleatorios de 1.5 a 6 segundos), visitar ocasionalmente páginas intermedias (categoría → tarjeta, y no una solicitud directa a la API), emular el desplazamiento y los movimientos del mouse al trabajar a través de un navegador headless. Esto aumenta el tiempo de recolección de datos, pero reduce drásticamente la cantidad de bloqueos.
Razón 7: Las sesiones y cookies no se mantienen entre solicitudes
A menudo, el parser en el servidor crea una nueva sesión de requests para cada solicitud, sin cookies, sin un token de autorización guardado, sin historial de visitas. Los marketplaces como Wildberries y Ozon emiten cookies temporales y tokens en la primera visita, y las solicitudes posteriores sin ellos parecen sospechosas, como si cada solicitud la hiciera un nuevo visitante anónimo.
Esquema correcto: una sesión (requests.Session() o contexto del navegador) para una IP del grupo de proxies, con cookies guardadas durante toda la serie de solicitudes a esta IP. Al cambiar de proxy, se debe iniciar una nueva sesión con cookies limpias, simulando un nuevo usuario, y no continuar utilizando cookies antiguas con una nueva IP; esto también crea una discrepancia y activa el bloqueo.
Lista de verificación: qué cambiar en orden
Si el parser es bloqueado de manera estable en el servidor, pero funciona localmente, verifica los cambios en este orden: así encontrarás la razón más rápido:
| Paso | Qué verificar | Qué cambiar |
|---|---|---|
| 1 | Tipo de IP del servidor | Cambiar a proxies residenciales en lugar de IP directa de hosting |
| 2 | Frecuencia de solicitudes | Implementar rotación de IP y límite de solicitudes por dirección |
| 3 | Encabezados de la solicitud | Copiar el conjunto completo de encabezados de un navegador real |
| 4 | Huella TLS | Usar curl_cffi / navegador headless en lugar de requests puro |
| 5 | Zona horaria y localización | Configurar perfil en Dolphin Anty / AdsPower para la región de la IP |
| 6 | Patrón de comportamiento | Aleatorizar retrasos, añadir páginas intermedias |
| 7 | Sesiones y cookies | Vincular una sesión a una IP durante todo el ciclo de solicitudes |
Para el scraping de alta frecuencia de los catálogos de Wildberries y Ozon, donde la velocidad para recorrer miles de páginas es importante, a menudo se combinan dos tipos de proxies: proxies de centros de datos para solicitudes técnicas preliminares (verificación de disponibilidad, códigos de estado) y residenciales para la recolección final de datos de las tarjetas, donde la ocultación como un usuario real es crucial. Para aplicaciones móviles de marketplaces y Avito, a veces son más efectivos proxies móviles, ya que rara vez caen en listas de bloqueo automático por ASN.
Conclusión
El bloqueo del parser en el servidor mientras que la versión local funciona casi siempre está relacionado no con la lógica del script, sino con el entorno: tipo de IP, huella TLS, encabezados, zona horaria, patrón de solicitudes y gestión de sesiones. Al verificar cada una de las 7 razones en orden — desde la más común (IP de centro de datos) hasta la más sutil (desajuste de la zona horaria y la región de la IP) — se puede restaurar el funcionamiento estable del parser sin cambiar la lógica principal del negocio de recolección de datos.
Si estás recolectando precios y existencias en Wildberries, Ozon o Avito en volúmenes industriales, comienza por reemplazar la IP: prueba proxies residenciales en lugar de la dirección estándar de VPS; en la mayoría de los casos, esto elimina hasta el 70% de los bloqueos antes de que comiences a configurar encabezados y huellas TLS.