Google Colab y Jupyter Notebook son herramientas convenientes para escribir y ejecutar rápidamente scripts de scraping sin necesidad de instalar Python en la máquina local. Pero los notebooks en la nube tienen una particularidad que a menudo se olvida: todas las solicitudes provienen de direcciones IP de los centros de datos de Google, que son bien conocidas por los sistemas anti-bot y son bloqueadas casi instantáneamente. En este artículo, analizaremos cómo conectar correctamente un proxy en Colab y Jupyter, qué limitaciones impone el entorno en la nube y cómo estructurar el scraping para que no falle después de las primeras 50 solicitudes.
Por qué Google Colab es bloqueado con más frecuencia que un PC normal
El principal problema de Colab para el scraping es el pool común de direcciones IP. Cada vez que inicias un notebook, Google asigna una máquina virtual con una IP de sus rangos en la nube (AS15169 y similares). Estos rangos han sido incluidos en las listas negras de la mayoría de los sistemas anti-bot: Cloudflare, DataDome, PerimeterX, así como la protección integrada de Wildberries, Ozon y otros marketplaces los reconocen en fracciones de segundo. La solicitud ni siquiera llega al sitio: es bloqueada por un filtro por ASN (Número de Sistema Autónomo) antes de verificar el User-Agent o el comportamiento.
La segunda razón es la masividad del uso. Miles de desarrolladores ejecutan simultáneamente scrapers, bots y scripts de ML a través de Colab, por lo que la reputación de estas IP en muchos sitios objetivo ya está "quemada" mucho antes de tu solicitud. Incluso si haces una solicitud GET cuidadosa cada 10 segundos, el sitio puede devolver un 403 simplemente porque desde ese mismo rango, hace una hora, alguien estaba golpeando el servidor con 500 hilos.
La tercera razón es que Jupyter, ejecutado localmente, generalmente no tiene este problema (si tienes una IP doméstica o de oficina normal), pero al comenzar a trabajar a través de JupyterHub en un servidor de hosting o en un contenedor de un proveedor de nube, la situación se vuelve la misma que en Colab. Por lo tanto, la pregunta "¿se necesitan proxies o no?" para los notebooks en la nube se responde de manera inequívoca: sin ellos, el scraping prácticamente no funciona más allá de las primeras solicitudes.
Qué tipo de proxy es adecuado para scraping en la nube
La elección del tipo de proxy depende de lo que estés scrapeando y cuán agresiva sea la protección del sitio objetivo. Para Colab y Jupyter, es importante tener en cuenta otro matiz: la sesión del notebook está limitada en el tiempo, por lo que las sesiones sticky de proxy de larga duración no siempre son críticas; lo que más importa es la estabilidad de la conexión dentro de un solo lanzamiento.
| Tipo de proxy | Cuándo usar en Colab/Jupyter | Características |
|---|---|---|
| Proxies de centros de datos | Scraping de sitios sin protección estricta, APIs abiertas, páginas estáticas | Alta velocidad, bajo costo, pero también pueden ser bloqueados por ASN en sitios agresivos |
| Proxies residenciales | Scraping de Wildberries, Ozon, Avito, Google, redes sociales con protección anti-bot | IP de usuarios reales, rara vez entran en listas negras, mayor latencia |
| Proxies móviles | Scraping de versiones móviles de sitios, TikTok, Instagram a través de API | La mayor confianza, pero más caros y con rotación más lenta |
Para la mayoría de las tareas de scraping de marketplaces y motores de búsqueda desde Colab, la combinación óptima será la de proxies residenciales con rotación en cada solicitud; esto reduce la probabilidad de bloqueo por patrón de comportamiento, incluso si la propia solicitud se realiza desde el entorno en la nube de Google.
Configuración de proxy en requests y urllib
La configuración básica de proxy en Colab no difiere de un entorno Python local. La única diferencia es que en Colab las bibliotecas generalmente deben instalarse a través de !pip install, ya que la imagen estándar no siempre contiene todo lo necesario.
!pip install requests
import requests
proxy = {
"http": "http://login:[email protected]:9000",
"https": "http://login:[email protected]:9000"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
response = requests.get(
"https://example.com/catalog",
proxies=proxy,
headers=headers,
timeout=15
)
print(response.status_code)
print(response.text[:500])
Un punto importante: en Colab no hay un archivo de configuración persistente, por lo que el login y la contraseña del proxy deben ser o bien codificados (lo cual no es seguro al publicar el notebook), o almacenados en variables de entorno de Colab a través de google.colab.userdata, o conectados a través de Colab Secrets. Esto es más conveniente que almacenar la contraseña directamente en el código, especialmente si compartes el notebook con colegas.
from google.colab import userdata
proxy_login = userdata.get('PROXY_LOGIN')
proxy_pass = userdata.get('PROXY_PASS')
proxy_url = f"http://{proxy_login}:{proxy_pass}@gate.proxycove.com:9000"
proxies = {"http": proxy_url, "https": proxy_url}
Proxy con Selenium y Chrome sin cabeza en Colab
Si el sitio renderiza contenido a través de JavaScript (una situación típica para Wildberries, Ozon, Avito), un simple requests no es suficiente; se necesita un navegador sin cabeza. En Colab, esto suele ser Selenium con Chromium, que debe instalarse manualmente, ya que no está en la imagen base.
!apt-get update
!apt install chromium-chromedriver
!pip install selenium
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--no-sandbox')
chrome_options.add_argument('--disable-dev-shm-usage')
chrome_options.add_argument('--proxy-server=http://gate.proxycove.com:9000')
driver = webdriver.Chrome(options=chrome_options)
driver.get("https://example.com/catalog")
print(driver.page_source[:500])
driver.quit()
El problema es que la bandera --proxy-server no soporta la autenticación con login y contraseña directamente. Para proxies con autenticación en Selenium, debes usar IP-autorization (whitelisting por IP estática del notebook, lo que en Colab es inestable, ya que la IP de la máquina cambia con cada nuevo lanzamiento), o generar una extensión de Chrome "sobre la marcha" con las credenciales del proxy, o usar un túnel proxy a través de una biblioteca como selenium-wire, que soporta proxies autenticados de forma nativa.
!pip install selenium-wire
from seleniumwire import webdriver
proxy_options = {
'proxy': {
'http': 'http://login:[email protected]:9000',
'https': 'http://login:[email protected]:9000',
}
}
driver = webdriver.Chrome(seleniumwire_options=proxy_options, options=chrome_options)
driver.get("https://example.com/catalog")
Jupyter Notebook: local vs en la nube
Jupyter Notebook, ejecutado en una máquina local (a través de Anaconda o directamente a través de pip), utiliza tu dirección IP doméstica o de oficina; en este caso, los proxies son necesarios solo para enmascarar o eludir restricciones geográficas, y no para evitar bloqueos por ASN del centro de datos. La configuración en este caso es completamente idéntica a un script de Python normal: el mismo requests, el mismo Selenium, sin limitaciones en la instalación de controladores y paquetes del sistema.
La situación cambia si usas Jupyter a través de un servicio en la nube: JupyterHub en VPS, Kaggle Notebooks, Deepnote, Binder o un clúster de nube corporativa. En estos casos, la IP nuevamente pertenece al centro de datos del proveedor, y todos los problemas de Colab son relevantes uno a uno. La principal diferencia con Colab es que estos servicios a menudo tienen una IP más estable durante la sesión (no cambia con cada reinicio del núcleo), lo que simplifica la configuración de whitelisting por IP, si tu proveedor de proxy lo soporta.
Conclusión práctica: si el scraping es crítico para el negocio (por ejemplo, monitoreo diario de precios de competidores en marketplaces), es mejor no depender de notebooks en la nube gratuitos como entorno de producción, sino usarlos solo para desarrollar y probar el script, trasladando el scraper final a un servidor con IP constante y proxies configurados.
Limitaciones de los notebooks en la nube que rompen el scraping
Además de los problemas con la reputación de las IP, Google Colab tiene una serie de limitaciones técnicas que afectan directamente la estabilidad del scraping:
- Timeout de inactividad. La versión gratuita de Colab desconecta el notebook después de ~90 minutos de inactividad y finaliza la sesión forzosamente después de 12 horas de trabajo continuo; el scraping prolongado de miles de páginas debe dividirse en partes o guardar resultados intermedios en Google Drive.
- Cambio de IP en cada nuevo runtime. Si desconectas y vuelves a conectar el entorno de ejecución, la dirección IP de la máquina virtual cambia; esto rompe cualquier configuración de whitelisting por IP del servicio proxy.
- Limitación en conexiones salientes. Google limita el número de conexiones de red simultáneas desde una máquina virtual, por lo que la multihilo agresiva con decenas de solicitudes paralelas puede toparse no con el bloqueo del sitio, sino con los límites de Colab.
- No hay almacenamiento persistente sin montar un disco. Las cookies, sesiones del navegador y caché de conexiones proxy se pierden en cada reinicio; para el scraping con autenticación, es necesario guardar explícitamente las cookies en un archivo en Google Drive.
- Retrasos de red impredecibles. La infraestructura en la nube de Google a veces presenta picos de latencia, por lo que los timeouts de las solicitudes deben establecerse con un margen (15-30 segundos en lugar de los estándar 5-10).
Estas limitaciones hacen de Colab una excelente herramienta para desarrollar y depurar la lógica del scraper, pero poco adecuada para tareas de producción prolongadas; para ello, es mejor trasladar el script terminado a un VPS o servidor dedicado con su propia IP.
Rotación de proxies y manejo de errores en un ciclo
Para que el scraping no falle ante el primer bloqueo, el código necesita una lógica de reintentos con reemplazo de proxies. A continuación, un ejemplo de un ciclo simple con rotación y manejo de errores que se puede ejecutar directamente en Colab.
import requests
import time
import random
proxy_pool = [
"http://login:[email protected]:9000",
"http://login:[email protected]:9001",
"http://login:[email protected]:9002",
]
def get_with_retry(url, max_retries=5):
for attempt in range(max_retries):
proxy_url = random.choice(proxy_pool)
proxies = {"http": proxy_url, "https": proxy_url}
try:
response = requests.get(url, proxies=proxies, timeout=20)
if response.status_code == 200:
return response
else:
print(f"Intento {attempt+1}: estado {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Intento {attempt+1}: error {e}")
time.sleep(random.uniform(2, 5))
return None
result = get_with_retry("https://example.com/catalog")
if result:
print(result.status_code)
else:
print("Se han agotado todos los intentos")
Para el scraping de grandes catálogos (por ejemplo, miles de tarjetas de productos en Wildberries), esta lógica se envuelve adicionalmente en una cola de tareas con pausas entre solicitudes y guardando resultados intermedios en CSV o en una base de datos directamente en Google Drive, para no perder el progreso en caso de interrupción de la sesión de Colab.
Lista de verificación antes de ejecutar el scraper en Colab
- Los proxies están conectados y probados con una solicitud de prueba separada antes del ciclo principal
- El login y la contraseña del proxy se almacenan en Colab Secrets, y no en el código abierto
- Para sitios JS, se utiliza Selenium con selenium-wire o una extensión de autorización configurada
- El código tiene lógica de reintento y rotación de proxies en caso de errores 403/429
- Los resultados intermedios se guardan en Google Drive cada N registros
- Los timeouts de las solicitudes se han incrementado teniendo en cuenta posibles retrasos de la red en la nube
- La paralelización de las solicitudes está limitada para no toparse con los límites de conexiones salientes de Colab
- Para tareas de producción, se prevé trasladar el script a un servidor separado con IP constante
Conclusión
Google Colab y Jupyter en la nube son excelentes para el desarrollo rápido y la prueba de la lógica del scraper, pero debido a las IP comunes de los centros de datos, casi siempre requieren proxies desde los primeros pasos. Para sitios simples sin protección agresiva, bastarán los proxies de centros de datos, mientras que para el scraping de marketplaces, motores de búsqueda y redes sociales, los IP residenciales y móviles funcionan de manera más confiable, ya que rara vez caen bajo los filtros por ASN.
Si planeas un monitoreo regular de precios en Wildberries o Ozon directamente desde Colab, te recomendamos comenzar con proxies residenciales; ofrecen acceso estable sin bloqueos frecuentes, y para scripts de prueba únicos, puedes optar por proxies de centros de datos más económicos, conectándolos de la misma manera a través de requests o Selenium.