Google Colab und Jupyter Notebook sind praktische Werkzeuge zum schnellen Schreiben und Ausführen von Parsing-Skripten, ohne Python auf dem lokalen Computer installieren zu müssen. Aber bei Cloud-Notebooks gibt es eine Besonderheit, die oft vergessen wird: Alle Anfragen kommen von IP-Adressen der Google-Rechenzentren, die seit langem von Anti-Bot-Systemen erkannt werden und fast sofort gesperrt werden. In diesem Artikel werden wir besprechen, wie man Proxys in Colab und Jupyter richtig einrichtet, welche Einschränkungen die Cloud-Umgebung mit sich bringt und wie man das Parsen so gestaltet, dass es nach den ersten 50 Anfragen nicht abbricht.
Warum Google Colab häufiger gesperrt wird als ein normaler PC
Das Hauptproblem von Colab beim Parsen ist der gemeinsame Pool von IP-Adressen. Jedes Mal, wenn Sie ein Notebook starten, weist Google eine virtuelle Maschine mit einer IP aus seinen Cloud-Bereichen (AS15169 und ähnliche) zu. Diese Bereiche sind seit langem auf die schwarzen Listen der meisten Anti-Bot-Systeme gesetzt: Cloudflare, DataDome, PerimeterX, sowie der integrierte Schutz von Wildberries, Ozon und Marktplätzen erkennen sie in Bruchteilen von Sekunden. Die Anfrage erreicht die Website nicht einmal — sie wird vom Filter nach ASN (Autonomous System Number) noch vor der Überprüfung des User-Agent oder des Verhaltens abgefangen.
Ein weiterer Grund ist die Massenverwendung. Tausende von Entwicklern betreiben gleichzeitig Parser, Bots und ML-Skripte über Colab, weshalb der Ruf dieser IPs bei vielen Zielwebsites bereits "verbrannt" ist, lange bevor Ihre Anfrage eingeht. Selbst wenn Sie alle 10 Sekunden eine einzige saubere GET-Anfrage durchführen, kann die Website 403 zurückgeben, nur weil vor einer Stunde jemand von demselben Bereich aus 500 Threads auf den Server zugeschlagen hat.
Ein dritter Grund ist, dass lokal ausgeführtes Jupyter dieses Problem normalerweise nicht hat (wenn Sie eine normale Heim- oder Büro-IP haben), aber sobald Sie über JupyterHub auf einem Hosting-Server oder in einem Container eines Cloud-Anbieters arbeiten, wird die Situation die gleiche wie in Colab. Daher ist die Frage "Sind Proxys notwendig oder nicht" für Cloud-Notebooks eindeutig zu beantworten: Ohne sie funktioniert das Parsen praktisch nicht über die ersten paar Anfragen hinaus.
Welcher Proxy-Typ für Cloud-Parsing geeignet ist
Die Wahl des Proxy-Typs hängt davon ab, was genau Sie parsen und wie aggressiv der Schutz der Zielwebsite ist. Für Colab und Jupyter ist es wichtig, noch einen weiteren Punkt zu beachten: Die Sitzung des Notebooks ist zeitlich begrenzt, daher sind langlebige sticky-Sitzungen von Proxys nicht immer kritisch — oft ist die Stabilität der Verbindung innerhalb eines einzelnen Starts wichtiger.
| Proxy-Typ | Wann in Colab/Jupyter verwenden | Besonderheiten |
|---|---|---|
| Rechenzentrums-Proxys | Parsen von Websites ohne strengen Schutz, offene APIs, statische Seiten | Hohe Geschwindigkeit, niedriger Preis, können aber auch nach ASN auf aggressiven Websites gesperrt werden |
| Residential Proxys | Parsen von Wildberries, Ozon, Avito, Google, sozialen Netzwerken mit Anti-Bot-Schutz | IPs echter Benutzer, selten auf schwarzen Listen, höhere Latenz |
| Mobile Proxys | Parsen von mobilen Versionen von Websites, TikTok, Instagram über APIs | Höchstes Vertrauen, aber teurer und langsamere Rotation |
Für die meisten Parsing-Aufgaben von Marktplätzen und Suchmaschinen aus Colab ist eine Kombination aus Residential Proxys mit Rotation bei jeder Anfrage der optimale Kompromiss — dies verringert die Wahrscheinlichkeit einer Sperrung aufgrund von Verhaltensmustern, selbst wenn die Anfrage aus der Cloud-Umgebung von Google ausgeführt wird.
Proxy in requests und urllib einrichten
Die grundlegende Einrichtung von Proxys in Colab unterscheidet sich nicht von einer lokalen Python-Umgebung. Der einzige Unterschied besteht darin, dass in Colab die Bibliotheken normalerweise über !pip install installiert werden müssen, da das Standard-Image nicht immer alles Notwendige enthält.
!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])
Ein wichtiger Punkt: In Colab gibt es keine permanente Konfigurationsdatei, daher müssen Login und Passwort des Proxys entweder hardcodiert werden (was bei der Veröffentlichung des Notebooks unsicher ist), oder sie müssen in den Umgebungsvariablen von Colab über google.colab.userdata gespeichert werden, oder sie müssen über Colab Secrets verbunden werden. Dies ist bequemer, als das Passwort direkt im Code zu speichern, insbesondere wenn Sie das Notebook mit Kollegen teilen.
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}
Proxys mit Selenium und headless Chrome in Colab
Wenn die Website Inhalte über JavaScript rendert (typische Situation für Wildberries, Ozon, Avito), reicht einfaches requests nicht aus — ein headless-Browser ist erforderlich. In Colab ist dies normalerweise Selenium mit Chromium, das manuell installiert werden muss, da es im Basis-Image nicht enthalten ist.
!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()
Das Problem ist, dass das Flag --proxy-server die Authentifizierung mit Login und Passwort nicht direkt unterstützt. Für Proxys mit Authentifizierung in Selenium müssen Sie entweder die IP-Authentifizierung verwenden (Whitelisting über die statische IP des Notebooks, was in Colab instabil ist, da sich die IP der Maschine bei jedem neuen Start ändert), oder ein Chrome-Erweiterung "on-the-fly" mit den Proxy-Anmeldedaten generieren, oder einen Proxy-Tunnel über eine Bibliothek wie selenium-wire verwenden, die authentifizierte Proxys direkt unterstützt.
!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: lokal vs. in der Cloud
Jupyter Notebook, das auf einem lokalen Computer (über Anaconda oder direkt über pip) ausgeführt wird, verwendet Ihre Heim- oder Büro-IP-Adresse — und in diesem Fall sind Proxys nur zur Maskierung oder Umgehung von Geo-Einschränkungen erforderlich, nicht um sich vor einer Sperrung durch das ASN-Rechenzentrum zu schützen. Die Einrichtung ist in diesem Fall identisch mit einem normalen Python-Skript: dasselbe requests, dasselbe Selenium, ohne Einschränkungen bei der Installation von Treibern und Systempaketen.
Die Situation ändert sich, wenn Sie Jupyter über einen Cloud-Dienst verwenden: JupyterHub auf einem VPS, Kaggle Notebooks, Deepnote, Binder oder einem Unternehmens-Cloud-Cluster. In diesen Fällen gehört die IP erneut zum Rechenzentrum des Anbieters, und alle Probleme von Colab sind eins zu eins relevant. Der Hauptunterschied zu Colab ist, dass solche Dienste oft eine stabilere IP während der Sitzung haben (sie ändert sich nicht bei jedem Neustart des Kernels), was die Einrichtung von Whitelisting nach IP erleichtert, wenn Ihr Proxy-Anbieter dies unterstützt.
Praktische Schlussfolgerung: Wenn das Parsen für das Geschäft kritisch ist (z. B. tägliche Überwachung der Preise von Wettbewerbern auf Marktplätzen), ist es besser, sich nicht auf kostenlose Cloud-Notebooks als Produktionsumgebung zu verlassen, sondern sie nur für die Entwicklung und das Testen des Skripts zu verwenden und den endgültigen Parser auf einen Server mit fester IP und konfigurierten Proxys zu übertragen.
Einschränkungen von Cloud-Notebooks, die das Parsen stören
Neben den Problemen mit dem Ruf der IP hat Google Colab eine Reihe technischer Einschränkungen, die sich direkt auf die Stabilität des Parsens auswirken:
- Timeout bei Inaktivität. Die kostenlose Version von Colab schaltet das Notebook nach ca. 90 Minuten Inaktivität ab und beendet die Sitzung nach 12 Stunden ununterbrochener Arbeit zwangsweise — langwieriges Parsen von Tausenden von Seiten muss in Teile aufgeteilt oder Zwischenresultate auf Google Drive gespeichert werden.
- IP-Wechsel bei jedem neuen Lauf. Wenn Sie die Ausführungsumgebung getrennt und erneut verbunden haben, ändert sich die IP-Adresse der virtuellen Maschine — dies bricht jede Einstellung mit Whitelisting nach IP auf der Seite des Proxy-Dienstes.
- Einschränkung der ausgehenden Verbindungen. Google begrenzt die Anzahl gleichzeitiger Netzwerkverbindungen von einer virtuellen Maschine, daher kann aggressive Multithreading mit Dutzenden paralleler Anfragen nicht an der Blockierung der Website scheitern, sondern an den Limits von Colab selbst.
- Kein persistentes Speichern ohne Festplattenerstellung. Cookies, Browsersitzungen und Cache von Proxy-Verbindungen gehen bei jedem Neustart verloren — für das Parsen mit Authentifizierung müssen Cookies explizit in einer Datei auf Google Drive gespeichert werden.
- Unvorhersehbare Netzwerkverzögerungen. Die Cloud-Infrastruktur von Google kann manchmal Sprünge in der Latenz verursachen, weshalb die Timeout-Werte für Anfragen großzügig gesetzt werden sollten (15-30 Sekunden statt der Standardwerte von 5-10).
Diese Einschränkungen machen Colab zu einem ausgezeichneten Werkzeug zur Entwicklung und Fehlersuche der Logik des Parsers, aber schlecht geeignet für langfristige Produktionsaufgaben — für diese ist es besser, das fertige Skript auf einen VPS oder dedizierten Server mit eigener IP zu übertragen.
Proxy-Rotation und Fehlerbehandlung in Schleifen
Damit das Parsen bei der ersten Sperrung nicht abbricht, ist eine Logik für Wiederholungsversuche mit Proxy-Wechsel im Code erforderlich. Unten finden Sie ein Beispiel für eine einfache Schleife mit Rotation und Fehlerbehandlung, die Sie direkt in Colab ausführen können.
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"Versuch {attempt+1}: Status {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"Versuch {attempt+1}: Fehler {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("Alle Versuche erschöpft")
Für das Parsen großer Kataloge (z. B. Tausende von Produktkarten auf Wildberries) wird diese Logik zusätzlich in eine Aufgabenwarteschlange mit Pausen zwischen den Anfragen und dem Speichern von Zwischenresultaten in CSV oder einer Datenbank direkt auf Google Drive eingebettet, um den Fortschritt bei einem Abbruch der Colab-Sitzung nicht zu verlieren.
Checkliste vor dem Start des Parsers in Colab
- Proxys sind verbunden und wurden vor der Hauptschleife mit einer separaten Testanfrage getestet
- Login und Passwort des Proxys werden in Colab Secrets gespeichert, nicht im offenen Code
- Für JS-Websites wird Selenium mit selenium-wire oder einer festgelegten Authentifizierungserweiterung verwendet
- Im Code gibt es eine Retry-Logik und Proxy-Rotation bei Fehlern 403/429
- Zwischenresultate werden alle N Einträge auf Google Drive gespeichert
- Timeouts für Anfragen wurden unter Berücksichtigung möglicher Verzögerungen im Cloud-Netzwerk erhöht
- Die Parallelität der Anfragen ist begrenzt, um nicht an den Limits der ausgehenden Verbindungen von Colab zu scheitern
- Für Produktionsaufgaben ist eine Übertragung des Skripts auf einen separaten Server mit fester IP vorgesehen
Fazit
Google Colab und Cloud-Jupyter eignen sich hervorragend für die schnelle Entwicklung und das Testen der Logik des Parsers, erfordern jedoch aufgrund der gemeinsamen IPs der Rechenzentren fast immer Proxys bereits in den ersten Schritten. Für einfache Websites ohne aggressive Schutzmaßnahmen genügen Rechenzentrums-Proxys, während für das Parsen von Marktplätzen, Suchmaschinen und sozialen Netzwerken Residential und mobile IPs zuverlässiger funktionieren, da sie seltener unter ASN-Filtern fallen.
Wenn Sie eine regelmäßige Preisüberwachung auf Wildberries oder Ozon direkt aus Colab planen, empfehlen wir, mit Residential Proxys zu beginnen — sie bieten stabilen Zugang ohne häufige Sperrungen, und für einmalige Testskripte können Sie mit kostengünstigeren Rechenzentrums-Proxys auskommen, die Sie auf dieselbe Weise über requests oder Selenium verbinden.