Google Colab e Jupyter Notebook sono strumenti comodi per scrivere e lanciare rapidamente script di parsing senza dover installare Python sulla macchina locale. Ma i notebook cloud hanno una caratteristica che spesso viene dimenticata: tutte le richieste provengono da indirizzi IP dei data center di Google, che sono da tempo noti ai sistemi anti-bot e vengono bannati quasi immediatamente. In questo articolo vedremo come collegare correttamente un proxy in Colab e Jupyter, quali limitazioni impone l'ambiente cloud e come strutturare il parsing in modo che non si interrompa dopo le prime 50 richieste.
Perché Google Colab viene bannato più frequentemente rispetto a un PC normale
Il principale problema di Colab per il parsing è il pool comune di indirizzi IP. Ogni volta che avvii un notebook, Google assegna una macchina virtuale con un IP proveniente dai suoi intervalli cloud (AS15169 e simili). Questi intervalli sono stati a lungo inseriti nelle liste nere della maggior parte dei sistemi anti-bot: Cloudflare, DataDome, PerimeterX, e anche la protezione integrata di Wildberries, Ozon e marketplace li riconoscono in frazioni di secondo. La richiesta non arriva nemmeno al sito — viene bloccata dal filtro ASN (Autonomous System Number) ancora prima di controllare l'User-Agent o il comportamento.
La seconda ragione è l'uso massiccio. Migliaia di sviluppatori eseguono contemporaneamente parser, bot e script ML tramite Colab, quindi la reputazione di questi IP presso molti siti target è già "bruciata" molto prima della tua richiesta. Anche se fai una singola richiesta GET ogni 10 secondi, il sito potrebbe restituire un 403 semplicemente perché dallo stesso intervallo un'ora fa qualcuno stava martellando il server con 500 thread.
La terza ragione è che Jupyter, eseguito localmente, di solito non ha questo problema (se hai un normale IP domestico o d'ufficio), ma non appena inizi a lavorare tramite JupyterHub su un server di hosting o in un container di un fornitore cloud — la situazione diventa la stessa di Colab. Pertanto, la questione "è necessario un proxy o no" per i notebook cloud è risolta in modo chiaro: senza di essi, il parsing praticamente non funziona oltre le prime poche richieste.
Quale tipo di proxy è adatto per il parsing cloud
La scelta del tipo di proxy dipende da cosa stai parsando e quanto è aggressiva la protezione del sito target. Per Colab e Jupyter è importante considerare un altro aspetto: la sessione del notebook è limitata nel tempo, quindi le sessioni sticky a lungo termine del proxy non sono sempre critiche — più spesso è importante la stabilità della connessione proprio nell'ambito di un singolo avvio.
| Tipo di proxy | Quando utilizzare in Colab/Jupyter | Caratteristiche |
|---|---|---|
| Proxy dei data center | Parsing di siti senza protezione rigorosa, API aperti, pagine statiche | Alta velocità, basso costo, ma possono anche essere bannati per ASN su siti aggressivi |
| Proxy residenziali | Parsing di Wildberries, Ozon, Avito, Google, social media con protezione anti-bot | IP di utenti reali, raramente finiscono nelle liste nere, latenza più alta |
| Proxy mobili | Parsing delle versioni mobili dei siti, TikTok, Instagram tramite API | Il massimo livello di fiducia, ma più costosi e rotazione più lenta |
Per la maggior parte delle attività di parsing di marketplace e motori di ricerca da Colab, il miglior equilibrio sarà una combinazione di proxy residenziali con rotazione per ogni richiesta — questo riduce la probabilità di ban per pattern comportamentali, anche se la richiesta stessa viene eseguita dall'ambiente cloud di Google.
Configurazione del proxy in requests e urllib
La configurazione di base del proxy in Colab non è diversa da un ambiente Python locale. L'unica differenza è che in Colab le librerie devono solitamente essere installate tramite !pip install, poiché l'immagine standard non contiene sempre tutto il necessario.
!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: in Colab non c'è un file di configurazione permanente, quindi il login e la password del proxy devono essere o hardcoded (cosa non sicura quando si pubblica il notebook), o memorizzati nelle variabili d'ambiente di Colab tramite google.colab.userdata, oppure collegati tramite Colab Secrets. Questo è più comodo che memorizzare la password direttamente nel codice, specialmente se condividi il notebook con i colleghi.
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 e Chrome headless in Colab
Se il sito rende il contenuto tramite JavaScript (situazione tipica per Wildberries, Ozon, Avito), un semplice requests non è sufficiente — è necessario un browser headless. In Colab questo è solitamente Selenium con Chromium, che deve essere installato manualmente, poiché non è presente nell'immagine di 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()
Il problema è che il flag --proxy-server non supporta l'autenticazione con login e password direttamente. Per i proxy con autenticazione in Selenium è necessario utilizzare l'autenticazione IP (whitelisting tramite IP statico del notebook, che in Colab è instabile, poiché l'IP della macchina cambia ad ogni nuovo avvio), oppure generare un'estensione Chrome "al volo" con le credenziali del proxy, oppure utilizzare un tunnel proxy tramite una libreria come selenium-wire, che supporta i proxy autenticati di default.
!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: locale vs cloud
Jupyter Notebook, eseguito su una macchina locale (tramite Anaconda o direttamente tramite pip), utilizza il tuo indirizzo IP domestico o d'ufficio — e in questo caso i proxy sono necessari solo per mascherare o bypassare le restrizioni geografiche, e non per proteggersi dai ban per ASN del data center. La configurazione in questo caso è completamente identica a quella di un normale script Python: stesso requests, stesso Selenium, senza limitazioni sull'installazione di driver e pacchetti di sistema.
La situazione cambia se utilizzi Jupyter tramite un servizio cloud: JupyterHub su VPS, Kaggle Notebooks, Deepnote, Binder o un cluster cloud aziendale. In questi casi, l'IP appartiene nuovamente al data center del fornitore, e tutti i problemi di Colab sono attuali uno a uno. La principale differenza rispetto a Colab è che questi servizi spesso hanno un IP più stabile durante la sessione (non cambia ad ogni riavvio del kernel), il che semplifica la configurazione del whitelisting per IP, se il tuo fornitore di proxy lo supporta.
Conclusione pratica: se il parsing è critico per il business (ad esempio, monitoraggio quotidiano dei prezzi dei concorrenti sui marketplace), è meglio non affidarsi ai notebook cloud gratuiti come ambiente di produzione, ma usarli solo per sviluppare e testare lo script, trasferendo il parser finale su un server con IP permanente e proxy configurati.
Limitazioni dei notebook cloud che rompono il parsing
Oltre ai problemi di reputazione degli IP, Google Colab ha una serie di limitazioni tecniche che influenzano direttamente la stabilità del parsing:
- Timeout di inattività. La versione gratuita di Colab disattiva il notebook dopo ~90 minuti di inattività e termina forzatamente la sessione dopo 12 ore di lavoro continuo — il lungo parsing di migliaia di pagine deve essere suddiviso in parti o salvato risultati intermedi su Google Drive.
- Cambio di IP ad ogni nuovo runtime. Se hai disattivato e riconnesso l'ambiente di esecuzione, l'indirizzo IP della macchina virtuale cambia — questo rompe qualsiasi configurazione di whitelisting per IP sul lato del servizio proxy.
- Limitazione sulle connessioni in uscita. Google limita il numero di connessioni di rete simultanee da una singola macchina virtuale, quindi l'aggressiva multithreading con decine di richieste parallele può urtare non nel blocco del sito, ma nei limiti di Colab stesso.
- Assenza di storage persistente senza montaggio del disco. I cookie, le sessioni del browser e la cache delle connessioni proxy scompaiono ad ogni riavvio — per il parsing con autenticazione è necessario salvare esplicitamente i cookie in un file su Google Drive.
- Ritardi di rete imprevedibili. L'infrastruttura cloud di Google a volte provoca picchi di latenza, per cui i timeout delle richieste devono essere impostati con margine (15-30 secondi invece dei normali 5-10).
Queste limitazioni rendono Colab uno strumento eccellente per sviluppare e debuggare la logica del parser, ma poco adatto per compiti di produzione a lungo termine — per questi è meglio trasferire lo script pronto su un VPS o server dedicato con IP proprio.
Rotazione dei proxy e gestione degli errori in un ciclo
Affinché il parsing non si interrompa al primo blocco, nel codice è necessaria una logica di retry con sostituzione del proxy. Di seguito un esempio di un semplice ciclo con rotazione e gestione degli errori, che può essere eseguito direttamente in 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"Attempt {attempt+1}: status {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Attempt {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("All attempts exhausted")
Per il parsing di grandi cataloghi (ad esempio, migliaia di schede prodotto su Wildberries) questa logica viene ulteriormente avvolta in una coda di task con pause tra le richieste e salvataggio dei risultati intermedi in CSV o database direttamente su Google Drive, per non perdere progressi in caso di interruzione della sessione Colab.
Checklist prima di avviare il parser in Colab
- I proxy sono collegati e testati con una richiesta di test separata prima del ciclo principale
- Login e password del proxy sono memorizzati in Colab Secrets, e non nel codice aperto
- Per i siti JS si utilizza Selenium con selenium-wire o un'estensione di autorizzazione specificata
- Il codice contiene logica di retry e rotazione dei proxy in caso di errori 403/429
- I risultati intermedi vengono salvati su Google Drive ogni N registrazioni
- I timeout delle richieste sono aumentati tenendo conto dei possibili ritardi della rete cloud
- La parallelizzazione delle richieste è limitata per non urtare i limiti delle connessioni in uscita di Colab
- Per compiti di produzione è previsto il trasferimento dello script su un server separato con IP permanente
Conclusione
Google Colab e Jupyter cloud sono eccellenti per lo sviluppo rapido e il test della logica del parser, ma a causa degli IP comuni dei data center richiedono quasi sempre proxy già ai primi passi. Per siti semplici senza protezione aggressiva bastano i proxy dei data center, mentre per il parsing di marketplace, motori di ricerca e social media funzionano meglio gli IP residenziali e mobili, che raramente finiscono sotto i filtri per ASN.
Se prevedi un monitoraggio regolare dei prezzi su Wildberries o Ozon direttamente da Colab, ti consigliamo di iniziare con proxy residenziali — offrono accesso stabile senza frequenti blocchi, mentre per script di test una tantum puoi accontentarti di proxy dei data center più economici, collegandoli con lo stesso schema tramite requests o Selenium.