Proxys für Firecrawl, Crawl4AI und Crawlee: Erstellen Sie einen RAG-Korpus ohne Sperren

```html

Das Schema „Firecrawl in Docker gestartet, auf eine Liste von Domains gerichtet, Markdown für RAG erhalten“ funktioniert genau bis zur ersten tausend Seiten. Danach kommen zwei Rechnungen. Die erste — von Anti-Bots: Ein Teil der Domains beginnt, 403 anstelle von Inhalten zurückzugeben, und in der Wissensdatenbank entstehen Lücken, von denen Sie erfahren, wenn der Assistent antwortet: „In den bereitgestellten Materialien gibt es keine Informationen“. Die zweite Rechnung — für den Traffic: Der Crawler zieht ehrlich jedes Bild und jede Schriftart, die im endgültigen Markdown sowieso nicht landen werden.

Lassen Sie uns untersuchen, wie man Proxys an die drei beliebtesten LLM-Crawler des Jahres 2026 — Firecrawl, Crawl4AI und Crawlee — anschließt und wie man sie so konfiguriert, dass der Proxy nur dort funktioniert, wo er benötigt wird, und nicht Gigabytes auf jeder Seite verbraucht.

Für wen dieser Leitfaden ist

Wenn Sie einen Dokumentenkorpus für RAG sammeln, eine interne Wissensdatenbank füllen, eine Datenpipeline für das Fine-Tuning aufbauen oder einfach regelmäßig Hunderte von Domains herunterladen — dann ist dies Ihr Fall. Alle drei unten genannten Tools laufen in der Standardkonfiguration mit der IP Ihres Servers und laden die Seite vollständig. Beide Standardwerte müssen geändert werden.

Das Ausmaß des Problems wird durch die Zahlen der Popularität deutlich: Firecrawl hatte zum Zeitpunkt der Veröffentlichung etwa 170.000 Sterne auf GitHub (Lizenz AGPL-3.0), Crawl4AI etwa 79.000 und Crawlee von Apify etwa 25.000. Das sind keine Nischenexperimente mehr, sondern Standardwerkzeuge, und Anti-Bot-Systeme kennen ihr Verhalten nicht schlechter als Sie.

Rechnung eins: 403 anstelle von Inhalten

Der entscheidende Fehler beim Sammeln des Korpus ist zu glauben, dass der Crawler erfolgreich gearbeitet hat, wenn er nicht abgestürzt ist. Firecrawl und Crawl4AI geben auf einer blockierten Seite nicht eine Ausnahme zurück, sondern ein Ergebnis: eine Anti-Bot-Stoppseite, eine Seite mit einer Browserüberprüfung oder einen kurzen Text über den Zugang verweigert. Formal ist das ein gültiges Markdown, es landet problemlos in der Vektordatenbank und bleibt dort bis zur ersten Benutzeranfrage.

Daher ist das erste, was Sie vor jeglicher Proxy-Konfiguration tun müssen, die Qualitätskontrolle des Ergebnisses hinzuzufügen. Die minimale Variante: Dokumente, die kürzer als einen bestimmten Schwellenwert sind (für eine typische Inhaltsseite sind 500–800 Zeichen Text sinnvoll), auszusortieren und charakteristische Marker im Text separat zu erfassen — Erwähnungen von Verbindungsprüfungen, aktiviertem JavaScript, „Zugang verweigert“. Solche Dokumente werden nicht in die Datenbank gesendet, sondern in die Warteschlange für einen erneuten Crawl — bereits über den Proxy.

Rechnung zwei: Gigabytes, die Sie wegwerfen

Hier hilft die Arithmetik. Laut Web Almanac von HTTP Archive für das Jahr 2025 wiegt die mediane Hauptseite etwa 2,86 MB auf Desktop und 2,56 MB auf Mobilgeräten. Davon entfallen etwa 1.059 KB auf Bilder auf Hauptseiten und 911 KB auf internen Seiten, auf JavaScript — 697 KB und 632 KB jeweils. Das heißt, Bilder sind die schwerste Kategorie, etwa ein Drittel des Seitengewichts.

Und jetzt erinnern Sie sich, was Sie mit dem Ergebnis machen. Sie konvertieren die Seite in Markdown und schneiden sie in Chunks für Embeddings. Bilder gelangen überhaupt nicht in diese Pipeline — im besten Fall bleibt eine Zeile mit Alt-Text übrig. Videos, Schriften, Analyseskipte, Werbe-Pixel — auch vorbei.

Wenn Sie den Crawl über einen Residential Proxy mit Bezahlung pro Gigabyte durchführen, zahlen Sie buchstäblich für die Lieferung von Daten, die Sie im nächsten Schritt der Pipeline wegwerfen. Bei einem Korpus von 100.000 Seiten wird der Unterschied zwischen „alles ziehen“ und „nur HTML und Text ziehen“ nicht in Prozenten, sondern in Vielfachen gemessen. Die genaue Einsparung hängt vom Thema der Websites ab: Medien und E-Commerce sind schwerer als Dokumentationen und Blogs.

Schritt 1. Eskalation statt „Proxy für alles“

Die wichtigste architektonische Technik, die am meisten spart: den gesamten Traffic nicht über den Proxy leiten. Der Großteil der Domains beim Sammeln der Wissensdatenbank — Dokumentationen, Blogs, Hilfeseiten, Regierungsportale — gibt Inhalte direkt aus und blockiert niemanden. Der Proxy wird nur von einer Minderheit benötigt.

Das richtige Schema ist eine mehrstufige Eskalation: zuerst eine direkte Anfrage, bei Anzeichen einer Blockierung — Wechsel zur nächsten Stufe. Und das ist kein selbstgeschriebener Hack, beide großen Frameworks können das so out of the box.

In Crawlee gibt es dafür tieredProxyUrls. Die Ebenen werden von billig nach teuer aufgelistet, und der Crawler steigt bei Blockierungen selbst auf, um dann periodisch zu versuchen, zur unteren Ebene zurückzukehren:

const proxyConfiguration = new ProxyConfiguration({
    tieredProxyUrls: [
        [null],
        ['http://user:pass@datacenter-proxy:8080'],
        ['http://user:pass@residential-proxy:8000'],
    ]
});

Ein wichtiger Hinweis aus der Dokumentation: tieredProxyUrls funktioniert nur bei Verwendung über eine Crawler-Instanz. Direkte Aufrufe von newUrl() führen zu unerwarteten Ergebnissen.

In Crawl4AI erschien ein ähnlicher Mechanismus in Version 0.8.5 und lebt im aktuellen Branch (letzte Veröffentlichung zum Zeitpunkt der Veröffentlichung — v0.9.2 vom 15. Juli 2026). Er heißt Proxy-Eskalation und wird direkt in CrawlerRunConfig konfiguriert: dreistufige Blockerkennung — bekannte Anti-Bot-Anbieter, allgemeine Blockindikatoren und Überprüfung der strukturellen Integrität der Seite — plus automatischer Retry über die Proxy-Kette.

from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig

config = CrawlerRunConfig(
    proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
    max_retries=2,
)

Beachten Sie ProxyConfig.DIRECT als erstes Element — das ist „versuche zuerst ohne Proxy“.

Schritt 2. Proxy in jedem Tool anschließen

Als nächstes — Details zur Konfiguration. Die Reihenfolge der Schritte ist gleich: zuerst Proxy, dann Ausschneiden von überflüssigem Traffic, dann Überprüfung.

1. Firecrawl (self-hosted). Der Proxy wird durch drei Umgebungsvariablen festgelegt, die in Playwright übergeben werden: PROXY_SERVER, PROXY_USERNAME, PROXY_PASSWORD. Sie werden in .env für apps/api festgelegt; in den Kommentaren dazu schreiben die Entwickler direkt, dass anstelle einer statischen Adresse ein Proxy-Service angegeben werden kann, der die IP bei jeder Anfrage rotiert.
2. Crawl4AI. Der Proxy lebt in BrowserConfig, im Feld proxy_config — das ist ein Objekt ProxyConfig oder ein Dictionary mit den Feldern server, username, password. Eine Browserkonfiguration für die gesamte Crawling-Sitzung; eine separate CrawlerRunConfig wird bei jedem Aufruf von arun() übergeben.
3. Crawlee. Die Klasse ProxyConfiguration mit der Option proxyUrls — eine Liste von Adressen, über die die Bibliothek im Round-Robin-Verfahren geht. Der Wert null in der Liste bedeutet „ohne Proxy“. Die Integration ist durchgängig: HttpCrawler, CheerioCrawler, JSDOMCrawler, PlaywrightCrawler, PuppeteerCrawler.
4. Gezielte Regeln. Wenn bekannt ist, welche Domains blockieren und welche nicht, gibt es in Crawlee die newUrlFunction — eigene Logik zur Auswahl des Proxys basierend auf der URL-Anfrage. Für weiße Domains geben Sie null zurück, für die anderen — die Proxy-Adresse. Das ist die günstigste Variante, wenn die Liste der Ziele stabil ist.
5. Überprüfung. Vor dem produktiven Durchlauf lassen Sie die Seite, die Ihre externe IP zurückgibt, durch den konfigurierten Crawler laufen und stellen Sie sicher, dass Sie die Proxy-Adresse und nicht die des Servers sehen. Drei Zeilen, die einen Tag an Klärung sparen.

Schritt 3. Alles abschneiden, was nicht Text wird

Wenn der Proxy angeschlossen ist, aktivieren Sie die Traffic-Einsparung — sonst kommt die Rechnung für Gigabytes schneller, als der Korpus gesammelt wird.

In Firecrawl ist dafür die Variable BLOCK_MEDIA verantwortlich. Im offiziellen Beispiel der Konfiguration steht dazu ein wörtlicher Kommentar: Stellen Sie es ein, wenn Sie Medienanfragen blockieren möchten, um die Bandbreite des Proxys zu sparen. Das ist der schnellste Weg, um die Hauptausgaben zu reduzieren.

In Crawl4AI leben ähnliche Hebel in BrowserConfig: text_mode deaktiviert Bilder und beschleunigt den Text-Crawl, light_mode schaltet einige Hintergrundfunktionen des Browsers aus, avoid_css blockiert das Laden von CSS. Diese können kombiniert werden. Für das Sammeln eines Korpus für RAG ist dies fast immer die richtige Kombination — das Layout brauchen Sie nicht, sondern den Text.

In Crawlee ist die Logik anders: Wenn der Inhalt in HTML ausgegeben wird, verwenden Sie CheerioCrawler oder HttpCrawler anstelle von Browser-Crawlern. Eine normale HTTP-Anfrage anstelle einer vollständigen Renderung ist nicht nur eine Traffic-Einsparung, sondern auch eine andere Kostenordnung. Browser-Crawler (PlaywrightCrawler, PuppeteerCrawler) lassen Sie nur für Seiten, die ohne JavaScript nicht gecrawlt werden können.

Fallstricke

Sitzungen gegen Rotation. Die IP bei jeder Anfrage zu wechseln, sieht an sich verdächtig aus und stört mehrstufige Szenarien — Paginierung, interne Übergänge innerhalb einer Domain. In Crawlee verknüpft jeder Aufruf von newUrl() den Proxy mit dem Session-Objekt, und sie rotieren zusammen mit den Browser-Fingerabdrücken und Headern. Trennen Sie dieses Paar nicht manuell.

Medien deaktiviert, aber Inhalt verschwunden. Einige Websites ziehen mit Lazy Loading nicht nur Bilder, sondern auch Text nach. Nach der Aktivierung von text_mode oder BLOCK_MEDIA sollten Sie unbedingt eine Stichprobe von 20–30 Seiten durchlaufen und das Textvolumen mit dem Referenzwert vergleichen.

Retries ohne Obergrenze. Die Eskalation über die Proxy-Ebenen bedeutet, dass eine hartnäckige Seite dreimal heruntergeladen werden kann — und alle drei Male bezahlt werden. Begrenzen Sie max_retries und führen Sie eine Liste von Domains, die nach N Fehlschlägen ganz aus dem Crawl ausgeschlossen werden.

Robots.txt und rechtlicher Rahmen. Die Datensammlung für das Training und RAG im Jahr 2026 wird strenger reguliert als vor ein paar Jahren — von den Anforderungen an die Offenlegung der Quellen bis zu den Mechanismen zum Widerspruch gegen Text- und Datenmining. Stellen Sie sicher, dass Ihre Pipeline diese Signale respektiert, bevor sie auf Hunderttausenden von Seiten arbeitet.

Welchen Proxy-Typ für die RAG-Pipeline wählen

Die Antwort hängt davon ab, auf welcher Eskalationsstufe Sie sich befinden.

• Nullstufe — ohne Proxy. Dokumentationen, Open-Source-Projekte, Regierungswebsites, die meisten Unternehmensblogs. Hier funktioniert die IP des Servers normal, und es gibt nichts zu bezahlen.
• Mittlere Stufe — Datacenter-Proxys. Schnell und günstig, geeignet gegen einfaches Rate Limiting und regionale Einschränkungen. Bei der Sammlung großer Korpora ist dies das Arbeitspferd: Wenn das Volumen in Hunderten von Gigabytes gemessen wird, wird der Preis pro Gigabyte zum Hauptfaktor.
• Obere Stufe — Residential Proxys. Für Domains mit ernsthaften Anti-Bot-Schutz, wo Datacenter-Subnetze am Eingang herausgefiltert werden. Deshalb können sie nicht als Standardstufe eingestellt werden — die Bezahlung pro Gigabyte verwandelt jedes überflüssige Bild in eine Kostenstelle.

Bevor Sie eine Pipeline aufbauen, sollten Sie die Wirtschaftlichkeit ehrlich berechnen: Wir haben die Gesamtkosten für das Parsen von einer Million Seiten unter Berücksichtigung des Seitengewichts, der Retries und versteckter Kosten untersucht. Und eine separate Frage, die nützlich ist, bevor Sie die erste Zeile Code schreiben: Brauchen Sie überhaupt einen Crawl — in der Analyse offizieller APIs gegen fertige Datensätze und Parsing zeigt sich, dass für einige Quellen fertige Daten günstiger sind als ein eigener Crawler.

Fazit

Proxys im LLM-Crawler sind kein „Ein/Aus“-Schalter, sondern ein dreistufiges Schema. Direkte Anfragen als Standardstufe, Datacenter-Proxys auf mittlerer Ebene, Residential-Proxys nur für Domains, die sonst nicht erfasst werden können. Plus striktes Ausschneiden von Medien, denn Sie sammeln Text und zahlen für Bytes.

Die Reihenfolge der Arbeiten ist einfach: zuerst Qualitätskontrolle des Ergebnisses (sonst erfahren Sie nicht, dass die Hälfte des Korpus aus Stoppseiten besteht), dann Eskalation des Proxys mit den Mitteln des Frameworks selbst, dann Traffic-Einsparung. In dieser Reihenfolge — und der Korpus wird vollständig und die Rechnung vorhersehbar.