Guide
Daten von Cloudflare-geschützten öffentlichen Seiten lesen (der regelkonforme Weg)
Sie öffnen einen öffentlichen Katalog oder eine Inseratsseite im Browser, und die Daten stehen direkt da. Ihr Skript ruft dieselbe URL ab und erhält eine leere Seite zurück. Der übliche Schluss — „ein CAPTCHA blockiert“ — ist oft falsch. Häufiger ist es ein technischer Fingerprint-Check, der greift, bevor die Seite rendert. Hier lesen Sie, was wirklich passiert — und wie sich diese öffentlichen Seiten auf dem regelkonformen Weg lesen lassen.
„Leere Seite“ heißt meist nicht CAPTCHA
Wenn eine Cloudflare-geschützte Website einem Skript eine leere oder minimale Seite liefert, Ihrem Browser aber die volle, ist der häufigste Grund ein TLS-Fingerprint-Check. Bevor irgendein Inhalt gerendert wird, prüft der Server die technische Signatur des verbindenden Clients — die Form des TLS-Handshakes, die Reihenfolge der Header, die ausgehandelten Parameter. Ein echter Browser zeigt eine bestimmte Signatur; eine Standard-Scripting-Bibliothek eine deutlich andere. Sieht die Signatur nicht nach einem gewöhnlichen Browser aus, bricht der Server ab und liefert nichts Brauchbares.
Der entscheidende Punkt: das passiert auf der Verbindungsebene, vor jeder sichtbaren Challenge. Es gibt kein Rätsel zu lösen und keine „Sind Sie ein Roboter?“-Box. Die Seite wurde für diesen Client schlicht nie gerendert. Deshalb sehen viele „leere Seiten“ und vermuten fälschlich ein CAPTCHA — der eigentliche Mechanismus ist ein Handshake, der nicht dem entspricht, was ein Browser senden würde.
Wie eine Session mit korrektem Fingerprint die öffentliche Seite liest
Der regelkonforme Ansatz ist unkompliziert: mit einer echten Browser-Session mit korrektem Fingerprint verbinden, sodass die öffentliche Seite genauso lädt wie für jeden anderen Besucher — und das in respektvollem Tempo.
- Eine echte Browser-Session. Eine echte Browser-Engine, deren TLS-Handshake und Header dem entsprechen, was die Website von alltäglichen Besuchern ohnehin erwartet — so rendert die öffentliche Seite wie vorgesehen.
- Das Tempo eines Besuchers. Seiten in menschlichem, gemächlichem Rhythmus lesen — Anfragen mit Abstand, Crawl-Delay respektiert — statt die Quelle zu fluten. Ein respektvoller Fußabdruck hält den Zugang stabil und ist schlicht das Richtige.
- Nur öffentliche Seiten. Gelesen wird, was jeder Besucher ohne Login sehen kann. Nichts hinter Schranken, nichts Persönliches — nur die öffentlichen, faktischen Felder, um die es geht.
- Hidden API, wo es eine gibt. Rendert die Session korrekt, legt die Seite oft denselben internen JSON-Endpunkt offen, den ich in Was ist eine Hidden API beschreibe — meist der sauberste, leichteste Weg, die Daten zu lesen.
Eine Demonstration des Fingerprinting-Konzepts liegt offen einsehbar vor: das Repository tls-fingerprint-scraper-demo zeigt, warum ein Standard-Client eine leere Seite erhält, wo eine Session mit korrektem Fingerprint den öffentlichen Inhalt ganz normal liest.
Auf der richtigen Seite der Linie bleiben
Öffentliche Daten verlässlich zu lesen und verantwortungsvoll zu handeln sind ein und derselbe Job. Diese Regeln sind nicht verhandelbar:
- Die Nutzungsbedingungen der Website lesen und respektieren. Untersagen sie automatisierten Zugriff, gehe ich nicht weiter.
robots.txtund Rate-Limits einhalten — immer, per Design.- Nur öffentliche, faktische, nicht personenbezogene Daten. Keine Inhalte hinter Logins, keine persönlichen Informationen.
- Sie betreiben und besitzen den resultierenden Feed; ich baue ihn so, dass er sich wie ein höflicher Besucher der Quelle verhält.
Die Kurzfassung
Leere Seiten einer Cloudflare-geschützten öffentlichen Website sind meist ein TLS-Fingerprint-Check, kein CAPTCHA. Eine Browser-Session mit korrektem Fingerprint liest die öffentliche Seite wie jeder normale Besucher, in respektvollem Tempo, im Rahmen der Bedingungen der Website. So wird aus „im Browser geht es, im Skript nicht“ ein Feed, auf den Verlass ist.