Proxy no Google Colab e Jupyter para scraping: configuração

Google Colab e Jupyter Notebook são ferramentas convenientes para escrever e executar scripts de scraping rapidamente, sem a necessidade de instalar Python na máquina local. Mas os notebooks em nuvem têm uma particularidade que muitas vezes é esquecida: todas as requisições são feitas a partir de endereços IP dos data centers do Google, que são bem conhecidos pelos sistemas anti-bot e são banidos quase instantaneamente. Neste artigo, vamos discutir como conectar corretamente um proxy no Colab e Jupyter, quais limitações a nuvem impõe e como estruturar o scraping para que ele não falhe após as primeiras 50 requisições.

Por que o Google Colab é banido com mais frequência do que um PC comum

O principal problema do Colab para scraping é o pool comum de endereços IP. Cada vez que você inicia um notebook, o Google aloca uma máquina virtual com um IP de seus intervalos em nuvem (AS15169 e semelhantes). Esses intervalos estão há muito tempo na lista negra da maioria dos sistemas anti-bot: Cloudflare, DataDome, PerimeterX, além da proteção embutida do Wildberries, Ozon e marketplaces que os reconhecem em frações de segundo. A requisição nem chega ao site — ela é bloqueada pelo filtro de ASN (Número do Sistema Autônomo) antes mesmo da verificação do User-Agent ou do comportamento.

A segunda razão é a massividade do uso. Milhares de desenvolvedores estão executando simultaneamente scrapers, bots e scripts de ML através do Colab, portanto, a reputação desses IPs em muitos sites-alvo já está "queimada" muito antes da sua requisição. Mesmo que você faça uma requisição GET cuidadosa a cada 10 segundos, o site pode retornar 403 simplesmente porque, a partir do mesmo intervalo, alguém estava atacando o servidor com 500 threads uma hora atrás.

A terceira razão é que o Jupyter, quando executado localmente, geralmente não tem esse problema (se você tiver um IP doméstico ou de escritório comum), mas assim que você começa a trabalhar através do JupyterHub em um servidor de hospedagem ou em um contêiner de provedor de nuvem — a situação se torna a mesma que no Colab. Portanto, a questão "proxies são necessários ou não" para notebooks em nuvem é resolvida de forma inequívoca: sem eles, o scraping praticamente não funciona além das primeiras requisições.

Qual tipo de proxy é adequado para scraping em nuvem

A escolha do tipo de proxy depende do que exatamente você está raspando e quão agressiva é a proteção do site-alvo. Para Colab e Jupyter, é importante considerar mais um detalhe: a sessão do notebook é limitada em tempo, portanto, sessões sticky de longa duração de proxies nem sempre são críticas — o que importa mais é a estabilidade da conexão dentro de uma única execução.

Tipo de proxy	Quando usar no Colab/Jupyter	Características
Proxies de data center	Scraping de sites sem proteção rigorosa, APIs abertas, páginas estáticas	Alta velocidade, baixo custo, mas também podem ser banidos por ASN em sites agressivos
Proxies residenciais	Scraping de Wildberries, Ozon, Avito, Google, redes sociais com proteção anti-bot	IPs de usuários reais, raramente entram em listas negras, maior latência
Proxies móveis	Scraping de versões móveis de sites, TikTok, Instagram via API	Maior confiança, mas mais caros e rotação mais lenta

Para a maioria das tarefas de scraping em marketplaces e motores de busca a partir do Colab, o equilíbrio ideal será uma combinação de proxies residenciais com rotação a cada requisição — isso reduz a probabilidade de banimento por padrão comportamental, mesmo que a própria requisição seja feita a partir do ambiente em nuvem do Google.

Configuração de proxy em requests e urllib

A configuração básica de proxy no Colab não difere da configuração local do Python. A única diferença é que, no Colab, as bibliotecas geralmente precisam ser instaladas através de !pip install, já que a imagem padrão nem sempre contém tudo o que é necessário.

!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])

Um ponto importante: no Colab não há um arquivo de configuração persistente, portanto, o login e a senha do proxy precisam ser ou codificados diretamente (o que não é seguro ao publicar o notebook), ou armazenados em variáveis de ambiente do Colab através de google.colab.userdata, ou conectados através do Colab Secrets. Isso é mais conveniente do que armazenar a senha diretamente no código, especialmente se você estiver compartilhando o notebook com 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 com Selenium e Chrome headless no Colab

Se o site renderiza conteúdo através de JavaScript (situação típica para Wildberries, Ozon, Avito), apenas requests não são suficientes — um navegador headless é necessário. No Colab, isso geralmente é feito com Selenium e Chromium, que precisam ser instalados manualmente, pois não estão disponíveis na imagem 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()

O problema é que a flag --proxy-server não suporta autenticação com login e senha diretamente. Para proxies com autenticação no Selenium, você precisa usar autenticação por IP (whitelisting por um IP estático do notebook, o que é instável no Colab, já que o IP da máquina muda a cada nova execução), ou gerar uma extensão do Chrome "em tempo real" com as credenciais do proxy, ou usar um túnel de proxy através de uma biblioteca como selenium-wire, que suporta proxy autenticado nativamente.

!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 na nuvem

O Jupyter Notebook, quando executado na máquina local (via Anaconda ou diretamente via pip), usa seu endereço IP doméstico ou de escritório — e nesse caso, proxies são necessários apenas para mascarar ou contornar restrições geográficas, e não para evitar banimentos por ASN do data center. A configuração nesse caso é totalmente idêntica a um script Python comum: o mesmo requests, o mesmo Selenium, sem limitações na instalação de drivers e pacotes de sistema.

A situação muda se você estiver usando Jupyter através de um serviço em nuvem: JupyterHub em VPS, Notebooks Kaggle, Deepnote, Binder ou um cluster de nuvem corporativo. Nesses casos, o IP novamente pertence ao data center do provedor, e todos os problemas do Colab são relevantes um a um. A principal diferença em relação ao Colab é que esses serviços frequentemente têm um IP mais estável durante a sessão (não muda a cada reinício do kernel), o que facilita a configuração de whitelisting por IP, se o seu provedor de proxy suportar isso.

Conclusão prática: se o scraping for crítico para o negócio (por exemplo, monitoramento diário de preços de concorrentes em marketplaces), é melhor não depender de notebooks em nuvem gratuitos como ambiente de produção, mas usá-los apenas para desenvolver e testar o script, transferindo o scraper final para um servidor com IP fixo e proxies configurados.

Limitações dos notebooks em nuvem que quebram o scraping

Além dos problemas de reputação do IP, o Google Colab possui uma série de limitações técnicas que afetam diretamente a estabilidade do scraping:

Timeout de inatividade. A versão gratuita do Colab desliga o notebook após ~90 minutos de inatividade e encerra a sessão forçadamente após 12 horas de trabalho contínuo — scraping longo de milhares de páginas precisa ser dividido em partes ou salvar resultados intermediários no Google Drive.
Mudança de IP a cada nova execução. Se você desconectar e reconectar o ambiente de execução, o endereço IP da máquina virtual muda — isso quebra qualquer configuração de whitelisting por IP do lado do serviço de proxy.
Limitação de conexões de saída. O Google limita o número de conexões de rede simultâneas de uma única máquina virtual, portanto, multithreading agressivo com dezenas de requisições paralelas pode esbarrar não no bloqueio do site, mas nos limites do próprio Colab.
Sem armazenamento persistente sem montagem de disco. Cookies, sessões de navegador e cache de conexões proxy desaparecem a cada reinício — para scraping com autenticação, é necessário salvar explicitamente cookies em um arquivo no Google Drive.
Latências de rede imprevisíveis. A infraestrutura em nuvem do Google às vezes apresenta picos de latência, fazendo com que os timeouts das requisições precisem ser ajustados para cima (15-30 segundos em vez dos padrões de 5-10).

Essas limitações tornam o Colab uma excelente ferramenta para desenvolver e depurar a lógica do scraper, mas pouco adequada para tarefas de produção de longa duração — para isso, é melhor transferir o script pronto para um VPS ou servidor dedicado com IP próprio.

Rotação de proxies e tratamento de erros em loop

Para que o scraping não falhe na primeira bloqueio, o código precisa de uma lógica de tentativas com troca de proxies. Abaixo está um exemplo de um loop simples com rotação e tratamento de erros, que pode ser executado diretamente no 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"Tentativa {attempt+1}: status {response.status_code}")
        except requests.exceptions.RequestException as e:
            print(f"Tentativa {attempt+1}: erro {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("Todas as tentativas esgotadas")

Para scraping de grandes catálogos (por exemplo, milhares de cartões de produtos no Wildberries), essa lógica é adicionalmente envolvida em uma fila de tarefas com pausas entre as requisições e salvamento de resultados intermediários em CSV ou banco de dados diretamente no Google Drive, para não perder o progresso em caso de interrupção da sessão do Colab.

Checklist antes de executar o scraper no Colab

Proxies conectados e testados com uma requisição de teste separada antes do loop principal
Login e senha do proxy armazenados no Colab Secrets, e não no código aberto
Para sites JS, utiliza-se Selenium com selenium-wire ou extensão de autenticação configurada
O código possui lógica de retry e rotação de proxies em caso de erros 403/429
Resultados intermediários salvos no Google Drive a cada N registros
Timeouts de requisições aumentados considerando possíveis latências da rede em nuvem
Paralelismo de requisições limitado para não esbarrar nos limites de conexões de saída do Colab
Para tarefas de produção, o script deve ser transferido para um servidor separado com IP fixo

Conclusão

Google Colab e Jupyter em nuvem são excelentes para desenvolvimento rápido e teste da lógica do scraper, mas devido aos IPs comuns dos data centers, quase sempre exigem proxies já nos primeiros passos. Para sites simples sem proteção agressiva, proxies de data center são suficientes, enquanto para scraping de marketplaces, motores de busca e redes sociais, proxies residenciais e móveis funcionam de forma mais confiável, pois raramente caem sob filtros por ASN.

Se você planeja monitorar regularmente os preços no Wildberries ou Ozon diretamente do Colab, recomendamos começar com proxies residenciais — eles oferecem acesso estável sem bloqueios frequentes, e para scripts de teste pontuais, você pode se contentar com proxies de data center mais econômicos, conectando-os da mesma forma através de requests ou Selenium.