Klassische Situation: Das Skript zur Preisüberwachung auf Wildberries oder Ozon funktioniert hervorragend auf dem heimischen Laptop, und nach dem Umzug auf einen VPS erhält es 403, ein Captcha oder eine sofortige IP-Sperre. Der Entwickler ändert die Header, fügt Verzögerungen hinzu – aber das Ergebnis bleibt gleich. Das Problem liegt fast nie im Code des Parsers selbst, sondern in der Umgebung, aus der er Anfragen stellt. Wir analysieren 7 konkrete Gründe und was geändert werden muss, damit der Parser stabil auf dem Server funktioniert.
Warum funktioniert alles lokal, aber auf dem Server gibt es eine Sperre
Wenn Sie den Parser von Ihrem Heimcomputer aus starten, sieht die Website die Anfrage von einer normalen Wohn-IP-Adresse Ihres Providers, aus einer gewohnten Region, mit einer realen Browserumgebung, wenn Sie Selenium oder Playwright mit einem echten Profil verwenden. Sobald dasselbe Skript auf einen VPS in Deutschland, den Niederlanden oder den USA umzieht, ändert sich das Bild vollständig: Die IP gehört zu einem Rechenzentrum, der TLS-Fingerabdruck kann sich aufgrund anderer Bibliotheksversionen unterscheiden, die Zeitzone des Servers stimmt nicht mit der Geolokation der IP überein, und die Anfragefrequenz steigt sprunghaft an, da der Server 24/7 ohne Unterbrechungen arbeitet.
Antibot-Systeme von Wildberries, Ozon, Avito und den meisten großen Marktplätzen achten schon lange nicht mehr nur auf den User-Agent. Sie analysieren eine Kombination aus Dutzenden von Signalen: IP-Typ, Geschwindigkeit und Regelmäßigkeit der Anfragen, Verhalten auf der Seite, Übereinstimmung von Headern und TLS-Parametern, Vorhandensein von Cookies und Sitzungshistorie. Der lokale Computer besteht zufällig die Prüfung in den meisten Punkten, der Server hingegen fällt in fast allen durch. Im Folgenden finden Sie eine detaillierte Analyse jedes Grundes.
Grund 1: IP des Rechenzentrums statt einer Wohn-IP
Dies ist der Grund Nr. 1 in 80% der Fälle. Die IP-Adressen von VPS und Cloud-Servern (AWS, DigitalOcean, Hetzner, gewöhnliche VDS-Hosting) befinden sich in den Datenbanken der Rechenzentren – die ASN dieser Anbieter sind öffentlich bekannt und werden von Antibot-Systemen zur sofortigen Filterung des Traffics verwendet. Marktplätze verwenden solche Listen in erster Linie, da 95% des automatisierten Parsings von Server-IP ausgeht.
Die Lösung besteht darin, IPs zu verwenden, die visuell nicht von einem normalen Internetnutzer zu unterscheiden sind. Für das Parsen von Wildberries, Ozon und Avito sind residential Proxys am besten geeignet: das sind echte IP-Adressen von heimischen Anbietern, die an gewöhnliche Abonnenten vergeben werden. Antibot-Systeme sehen eine solche Anfrage als Traffic von einem lebenden Benutzer und nicht von einem Server in einem Rechenzentrum, was sofort einen Großteil der Sperren aufhebt.
Grund 2: Keine IP-Rotation und keine Anfragefrequenzbegrenzung
Auf dem lokalen Computer führen Sie während der Tests 20–50 Anfragen manuell aus, und die Website bemerkt dies nicht. Auf dem Server wird das Skript alle 5 Minuten über cron ausgeführt und verarbeitet Tausende von Produktkarten hintereinander von einer IP. Ein solches Muster ist ein direktes Signal für das Antibot-System: Ein echter Mensch kann nicht 3000 Katalogseiten in einer Stunde ohne eine einzige Pause öffnen.
Es ist notwendig, eine IP-Rotation für den Proxy-Pool einzuführen und die Anzahl der Anfragen an eine Adresse in einem bestimmten Zeitraum zu begrenzen. Praktische Regel: nicht mehr als 30–60 Anfragen von einer IP pro Minute für Produktkarten, mit automatischem Wechsel der Adresse nach jedem Batch von Anfragen. Beispiel für eine Rotationskonfiguration in Python über einen Proxy-Pool:
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.textBei der Sammlung einer großen Anzahl von Karten pro Tag ist es bequemer, Proxys mit automatischer IP-Rotation pro Anfrage oder nach Timer zu verwenden – dies beseitigt die Notwendigkeit, die Liste der Adressen manuell zu führen.
Grund 3: Header und User-Agent unterscheiden sich vom Browser
Viele Parser, die requests oder aiohttp verwenden, senden Anfragen mit einem minimalen Satz von Headern oder mit dem Standard-User-Agent der Bibliothek, der sofort das Skript verrät (zum Beispiel python-requests/2.31.0). Auf dem lokalen Computer ist der Satz der Header vollständig: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer und andere – ihre Kombination sieht natürlich aus.
Es ist notwendig, den vollständigen Satz von Headern eines echten Browsers zu kopieren, einschließlich der Reihenfolge, in der sie gesendet werden – einige Antibot-Systeme überprüfen sogar dies. Außerdem ist es wichtig, den User-Agent synchron mit der Version des TLS-Fingerabdrucks zu rotieren (siehe nächsten Punkt), andernfalls wird die Diskrepanz zwischen dem Browser-Header und dem echten TLS-Client zu einem neuen Signal für den Bot.
Grund 4: TLS/JA3-Fingerabdruck gibt das Skript preis
Dies ist ein weniger bekannter, aber äußerst häufiger Grund für Sperren, insbesondere auf dem Server. Die Bibliotheken requests, urllib, aiohttp verwenden ihre eigene Implementierung des TLS-Handshakes, die sich von der Implementierung in Chrome oder Firefox unterscheidet. Antibot-Systeme berechnen den JA3/JA4-Fingerabdruck der TLS-Verbindung – und dieser unterscheidet sich bei Python-Skripten erheblich vom Fingerabdruck eines echten Browsers, selbst wenn die Header perfekt kopiert sind.
Die Lösung besteht darin, Bibliotheken zu verwenden, die den TLS-Fingerabdruck eines Browsers emulieren (zum Beispiel curl_cffi, tls-client in Python oder einen vollwertigen Headless-Browser auf Basis von Chromium über Playwright/Puppeteer). Die zweite Option besteht darin, nicht über einen reinen HTTP-Client zu arbeiten, sondern über eine verwaltete Browser-Engine in Verbindung mit einem Antidetect-Tool, bei dem TLS und Header von einem echten Browser-Kern und nicht von einer Bibliotheks-Emulation generiert werden.
Grund 5: Zeitzone, Locale und DNS-Server
Wenn das Skript den Browser über Selenium oder Playwright emuliert, kann das Antibot-System die Systemzeitzone, die Sprache der Benutzeroberfläche, den DNS-Resolver und sogar einen WebRTC-Lecktest der echten IP des Servers überprüfen. Ein VPS in einem Rechenzentrum in Frankfurt mit einer Systemzeitzone von UTC und dem DNS-Anbieter des Hosters, der gleichzeitig einen Proxy mit einer IP aus Moskau verwendet, schafft eine offensichtliche Diskrepanz in den Geodaten – dies ist eines der zuverlässigsten Signale für die Erkennung.
Alle Umgebungsparameter – Zeitzone, Sprache des Browsers, DNS, Geolokation über WebRTC – müssen mit der Region der IP-Adresse übereinstimmen, die für die Anfrage verwendet wird. Um dieses Problem zu lösen, wurden Antidetect-Browser entwickelt: Dolphin Anty, AdsPower, Multilogin, Octo Browser und GoLogin ermöglichen es, ein separates „Browserprofil“ für jeden Proxy einzurichten, bei dem automatisch die Zeitzone, Locale, Bildschirmauflösung und WebRTC an die Geolokation der IP angepasst werden.
Grund 6: Anfrage-Muster ist zu „robotisch“
Ein Mensch blättert durch den Katalog mit unterschiedlichen Pausen, klickt auf zufällige Produkte, kehrt manchmal zurück, scrollt die Seite unregelmäßig. Das Server-Skript führt normalerweise Anfragen in gleichmäßigen Intervallen aus (zum Beispiel genau alle 2 Sekunden) und greift nur auf die benötigten URLs zu, ohne „Rauschen“ darum herum – ohne das Laden von Bildern, Skripten, ohne die Hauptseite vor der Produktkarte zu besuchen.
Was zu ändern ist: zufällige Verzögerungen hinzufügen (nicht feste 2 Sekunden, sondern zufällig von 1,5 bis 6 Sekunden), gelegentlich auf Zwischenseiten gehen (Kategorie → Karte, nicht direkte Anfrage an die API), Scrollen und Mausbewegungen emulieren, wenn Sie über einen Headless-Browser arbeiten. Dies erhöht die Zeit für das Sammeln von Daten, reduziert jedoch erheblich die Anzahl der Sperren.
Grund 7: Sitzungen und Cookies werden nicht zwischen Anfragen gespeichert
Oft erstellt der Parser auf dem Server für jede Anfrage eine neue requests-Sitzung – ohne Cookies, ohne gespeicherten Autorisierungstoken, ohne Besuchshistorie. Marktplätze wie Wildberries und Ozon geben temporäre Cookies und Tokens beim ersten Besuch aus, und weitere Anfragen ohne diese sehen verdächtig aus, als würde jeder Anfrage ein neuer anonymer Besucher machen.
Das richtige Schema: eine Sitzung (requests.Session() oder Browser-Kontext) – für eine IP aus dem Proxy-Pool, mit der Speicherung von Cookies während der gesamten Serie von Anfragen an diese IP. Bei einem Proxywechsel sollte eine neue Sitzung mit leeren Cookies begonnen werden, um einen neuen Benutzer zu imitieren, und nicht weiterhin alte Cookies mit einer neuen IP zu verwenden – dies schafft ebenfalls eine Diskrepanz und löst eine Sperre aus.
Checkliste: Was der Reihenfolge nach geändert werden muss
Wenn der Parser konstant auf dem Server gesperrt wird, aber lokal funktioniert, überprüfen Sie die Änderungen in dieser Reihenfolge – so finden Sie schneller die Ursache:
| Schritt | Was zu überprüfen ist | Was zu ändern ist |
|---|---|---|
| 1 | Typ der Server-IP | Wechsel zu residential Proxys anstelle der direkten IP des Hostings |
| 2 | Anfragefrequenz | IP-Rotation und Anfragebegrenzung einführen |
| 3 | Anfrage-Header | Vollständigen Satz von Headern eines echten Browsers kopieren |
| 4 | TLS-Fingerabdruck | curl_cffi / Headless-Browser anstelle von reinem requests verwenden |
| 5 | Zeitzone und Locale | Profil in Dolphin Anty / AdsPower für die IP-Region einrichten |
| 6 | Verhaltensmuster | Verzögerungen randomisieren, Zwischenseiten hinzufügen |
| 7 | Sitzungen und Cookies | Eine Sitzung an eine IP für den gesamten Anfragezyklus binden |
Für das hochfrequente Parsen von Katalogen bei Wildberries und Ozon, wo die Geschwindigkeit beim Durchblättern von Tausenden von Seiten wichtig ist, kombinieren viele zwei Arten von Proxys: Rechenzentrums-Proxys für grobe technische Anfragen (Verfügbarkeit prüfen, Statuscodes) und residential Proxys für die finale Datensammlung von Karten, wo die Maskierung als echter Benutzer wichtig ist. Für mobile Anwendungen von Marktplätzen und Avito sind manchmal mobile Proxys effektiver, da sie seltener in automatische Sperrlisten aufgrund von ASN gelangen.
Fazit
Die Sperrung des Parsers auf dem Server bei der Ausführung der lokalen Version hängt fast immer nicht von der Logik des Skripts ab, sondern von der Umgebung: IP-Typ, TLS-Fingerabdruck, Header, Zeitzone, Anfrage-Muster und Sitzungsverwaltung. Wenn Sie jeden der 7 Gründe der Reihe nach überprüfen – vom häufigsten (IP des Rechenzentrums) bis zum unauffälligsten (Diskrepanz zwischen Zeitzone und Region der IP) – können Sie die stabile Funktion des Parsers wiederherstellen, ohne die grundlegende Geschäftslogik der Datensammlung zu ändern.
Wenn Sie Preise und Bestände bei Wildberries, Ozon oder Avito in industriellen Mengen sammeln, beginnen Sie mit dem Austausch der IP: Probieren Sie residential Proxys anstelle der Standard-VPS-Adresse – in den meisten Fällen beseitigt dies bis zu 70% der Sperren, noch bevor Sie beginnen, Header und TLS-Fingerabdrücke einzustellen.