Wie man Seiten hinter einem Login scrapt: Sessions, Cookies und Sticky Proxies im großen Maßstab

Viele der sammelnswerten Daten sitzen hinter einem Login, und sie zu scrapen ist eine andere Disziplin als öffentliche Seiten zu scrapen. In dem Moment, in dem du dich authentifizierst, hörst du auf, ein anonymer Besucher zu sein, und beginnst, ein Konto zu betreiben, und Konten werden rate-limitiert, herausgefordert und gesperrt, wie es anonyme Anfragen nie werden. Das ganze Spiel verschiebt sich von “rotiere frei, damit keine einzelne Identität auffällt” zu “halte eine Identität stabil, damit das Konto wie ein echter, konsistenter Nutzer aussieht”.

Ein Vorbehalt vor dem Wie: scrape nur Daten, zu denen du berechtigt bist, deine eigenen Konten, die Daten eines Partners, die du ziehen darfst, eine API, zu deren Nutzung du berechtigt bist. Eingeloggte Daten sind eine andere rechtliche und ethische Kategorie als öffentliche Daten, und ob das Scrapen legal ist, hängt stark von dieser Linie ab. Dieser Leitfaden setzt voraus, dass du auf der richtigen Seite davon stehst.

Öffentliches Scrapen rotiert. Authentifiziertes Scrapen bleibt konsistent.

Der Instinkt aus dem öffentlichen Scrapen ist, alles zu rotieren, eine neue IP pro Anfrage hält jede einzelne Identität davon ab, aufzufallen. Hinter einem Login ist dieser Instinkt genau verkehrt. Du hast jetzt eine persistente Identität, das Konto, und Konsistenz ist das, was es legitim aussehen lässt. Ein Konto, das sich in einer Stunde aus fünfzig Ländern einloggt, oder mitten in der Session die IP wechselt, sieht nicht wie ein Power-User aus. Es sieht kompromittiert aus, und das ist es, was eine Sperre auslöst.

Also läuft authentifiziertes Scrapen auf zwei gut gemachte Dinge hinaus: die Session so zu verwalten, dass du effizient eingeloggt bleibst, und jedes Konto an eine stabile, saubere Identität zu binden, damit es nie so aussieht, als hätte es sich teleportiert.

Die Session verwalten

Wenn du dich einloggst, gibt der Server Session-Status zurück, meist Cookies, manchmal ein Token. Der mit Abstand größte Fehler ist, sich bei jeder Anfrage neu einzuloggen. Erneute Authentifizierung ist langsam, und eine Flut von Logins ist selbst ein Warnsignal, das Login-Endpunkte hart rate-limitieren. Logge dich einmal ein, erfasse die Session, und verwende sie wieder.

Mit einem schlichten HTTP-Client heißt das ein persistentes Session-Objekt, das den Cookie-Topf behält und über den Proxy reitet:

import requests

proxies = {"https": "http://customer-USER-country-us-sid-acct42-ttl-600:PASS@p.shifter.io:443"}
s = requests.Session()
s.proxies.update(proxies)

# Einmal einloggen; die Set-Cookie-Antwort befüllt den Topf.
s.post("https://example.com/login", data={"user": USER, "password": PW})

# Dieselbe Session (und dieselbe Sticky-IP) für jede weitere Anfrage wiederverwenden.
r = s.get("https://example.com/account/data")

Darüber hinaus zählen zwei Details. Viele Seiten verlangen einen CSRF- oder Anti-Forgery-Token pro Session, den du aus einem Formular oder einer vorherigen Seite scrapst und mit Schreibaktionen sendest, also lies ihn aus der Session, statt ihn hartzukodieren. Und viele Seiten legen nach dem Login eine saubere JSON-API offen, die das eigene Frontend der Seite aufruft; den Netzwerk-Tab zu beobachten, offenbart sie oft, und diese authentifizierte API direkt mit deinen erfassten Cookies oder deinem Token anzusprechen ist weit schneller und leichter, als Seiten neu zu rendern.

Binde jedes Konto an eine saubere, Sticky-IP

Hier verdient sich die Proxy-Schicht ihren Platz. Ein Konto sollte einen konsistenten Standort präsentieren, also bekommt jedes Konto seine eigene Sticky Session: es tritt für die Lebensdauer dieser Session immer über dieselbe Residential-IP aus, hier als sid im Benutzernamen kodiert. IPs auf einem eingeloggten Konto zu rotieren ist ein klassischer Sperr-Auslöser, denn das Konto scheint mitten in der Session zwischen Standorten zu springen.

Drei Dinge lassen die Identität standhalten:

• Geo-Übereinstimmung. Die IP sollte zu dem passen, wo das Konto normalerweise operiert. Ein US-Konto, das plötzlich auf einer deutschen IP auftaucht, sieht wie eine Übernahme aus, und viele Seiten reagieren mit einem Re-Verifizierungs-Prompt oder einer Sperre.
• Saubere Reputation. Login-Endpunkte prüfen die IP-Reputation härter als öffentliche Seiten, denn dort passieren Kontoübernahmen. Eine markierte Adresse bekommt zusätzliche Reibung, 2FA-Prompts, CAPTCHAs, “bestätige, dass du es bist”-Bildschirme, bevor sie überhaupt zu den Daten gelangt.
• Ein Konto, eine Identität. Betreibst du mehrere Konten, braucht jedes seine eigene Sticky-IP, keine geteilte. Konten, die sich alle von einer einzigen Adresse einloggen, werden verknüpft und gemeinsam markiert. Das ist die Konto-Skalen-Version der Zwei-Ebenen-Identität, die ein Antidetect-Browser auf Geräteebene handhabt: eigenes Konto, eigene IP, und wenn du einen Browser nutzt, eigener Fingerabdruck.

Auf viele Konten skalieren

Das Muster skaliert, indem du jedes Konto seiner eigenen stabilen Identität zuordnest und diese Zuordnung hältst. Denk an ein Register: Konto zu Sticky-sid, Konto zu Cookie-Topf, und, wenn du einen Browser fährst, Konto zu Browser-Profil.

# Eine dauerhafte Identität pro Konto: gleiche sid -> gleiche Exit-IP, eigener Topf.
def session_for(account):
    s = requests.Session()
    sid = f"acct-{account['id']}"
    s.proxies.update({
        "https": f"http://{BASE_USER}-country-{account['geo']}-sid-{sid}-ttl-600:{PW}@p.shifter.io:443"
    })
    load_cookies(s, account)     # persistierten Topf wiederherstellen, oder einloggen, wenn keiner da
    return s

Dann verteile die Last über Konten, statt ein Konto hart zu drücken, und begrenze die Nebenläufigkeit pro Konto und pro Ziel, da jedes Konto sein eigenes Rate-Limit hat. Das Lastausgleich-Prinzip gilt, aber die Einheit, über die du verteilst, sind Konten, jedes auf seiner festen Identität, nicht rohe IPs.

Handhabe die Fehlermodi

Drei Dinge gehen schief, und jedes hat eine spezifische Antwort.

Session-Ablauf. Sessions laufen ab. Erkenne es, ein Redirect zur Login-Seite, oder ein 401, und authentifiziere dich auf derselben Identität neu, dann fahre fort. Die kritische Regel ist, bei der Neu-Authentifizierung die IP nicht zu wechseln; ein Re-Login von einem neuen Standort ist weit verdächtiger als der Ablauf selbst.

Stiller Logout. Manchmal bekommst du ein 200, das in Wahrheit die ausgeloggte Version der Seite ist, das ganze öffentliche Drumherum, nichts von den Kontodaten. Das ist der authentifizierte Vetter eines Soft-Blocks: validiere, dass du noch eingeloggt bist, indem du auf ein Element prüfst, das nur ein angemeldeter Nutzer sieht, statt dem Statuscode zu trauen. Ist der Nur-für-Konten-Marker weg, authentifiziere dich neu, bevor du leere Zeilen notierst.

Erzwungene Re-Verifizierung. Ein 2FA-Prompt oder eine “bestätige, dass du es bist”-Challenge bedeutet meist, dass die Identität riskant aussah, oft weil die IP markiert war oder der Standort sich verschob. Eine saubere, stabile, geo-passende IP ist das, was diese selten hält. Feuert eine doch, behandle diese Identität als verdächtig und fahre zurück, statt hindurchzuhämmern.

Browser oder HTTP für den Login selbst

Passe das Werkzeug an den Login an, nicht an den ganzen Scrape. Ein einfacher Formular-Login, der Cookies zurückgibt, funktioniert gut mit einem schlichten HTTP-Client, erfasse die Cookies, verwende sie wieder, bleib leichtgewichtig. Aber Login-Seiten sind häufig der am schwersten verteidigte Teil einer Seite, mit JS-Challenges, SSO-Redirects, dynamischen Tokens und aggressivem Fingerprinting, gerade weil dort Betrug passiert. Wenn der Login einem schlichten Client widersteht, logge dich mit einem echten Browser ein (Playwright, Puppeteer oder Selenium), und fahre ihn dann entweder weiter oder exportiere die Cookies an einen leichteren Client für die Massenarbeit. Hier beißt auch das TLS- und HTTP/2-Fingerprinting am härtesten, also macht der Netzwerk-Fingerabdruck eines echten Browsers am Login-Schritt oft den Unterschied, selbst wenn der Rest des Scrapes auf einem einfachen Client in Ordnung ist.

Verifiziere, bevor du einem Lauf traust

Nach dem Authentifizieren bestätige zwei Dinge: dass du tatsächlich eingeloggt bist (hole einen Nur-für-Konten-Endpunkt und prüfe auf einen Angemeldet-Marker), und dass du über die Sticky-IP austrittst, die du erwartest (eine IP-Echo-Prüfung sollte für die Lebensdauer der Session dieselbe Adresse zurückgeben). Wenn der Login “erfolgreich” war, aber der Konto-Marker fehlt, oder die Exit-IP zwischen Anfragen driftet, behebe das, bevor du irgendetwas sammelst, beides wird in den Timeout- und Erkennungs-Leitfäden behandelt.

Das Fazit

Scrapen hinter einem Login dreht sich um Identitäts-Konsistenz, nicht um Rotation. Logge dich einmal ein und verwende die Session wieder, statt dich ständig neu zu authentifizieren, binde jedes Konto an eine saubere, geo-passende, Sticky-Residential-IP, halte ein Konto zu einer Identität, authentifiziere dich auf derselben Identität neu, wenn eine Session abläuft, und validiere, dass du noch eingeloggt bist, statt einem 200 zu trauen. Skaliere, indem du Konten hinzufügst, jedes mit seiner eigenen stabilen Identität, nicht indem du ein einzelnes Konto über Adressen rotierst.

Mach das richtig, und authentifizierte Sammlung ist dauerhaft statt einer Kette von Sperren. Eine saubere, Sticky-Residential-IP pro Konto ist das Fundament, auf dem das Ganze ruht, und die Pro-GB-Preisgestaltung lässt dich viele stabile Konto-Identitäten fahren und nur für die Daten zahlen, die jede tatsächlich zieht.