Proxys für KI-Agenten 2026: Einrichtung von Playwright MCP, Browser-Nutzung und Cloud-Browsern

Der KI-Agent, der selbstständig durch Websites navigiert – Claude mit Playwright MCP, browser-use, Cloud Browserbase – stößt auf dieselbe Wand wie ein gewöhnlicher Parser: Nach ein paar Dutzend Anfragen von einer Adresse kommt anstelle der Seite eine Cloudflare-Herausforderung. Der Unterschied besteht darin, dass der Agent nicht beleidigt ist und einfach in eine Schleife gerät, indem er Token für Versuche „drückt, auf einen nicht vorhandenen Knopf“ verbraucht.

Dies wird durch Proxys behoben. Aber es stellt sich als unerwartet nicht offensichtlich heraus, wie man einen Proxy mit dem Agenten verbindet: Die Hälfte der Anleitungen im Internet bietet eine Syntax an, die Chromium stillschweigend ignoriert. Im Folgenden finden Sie funktionierende Konfigurationen für die drei gängigsten Stacks des Jahres 2026 und eine Analyse der Fallen, über die alle stolpern.

Wer braucht das

Ein Leitfaden für diejenigen, die bereits einen Agenten gestartet haben und eines der Symptome festgestellt haben:

• Der Agent führt 10–20 Schritte aus, und jeder folgende Schritt bringt ein Captcha oder die Seite „Verifizieren Sie, dass Sie ein Mensch sind“;
• Der Agent sieht nicht den gleichen Inhalt wie Sie: Preise, Ergebnisse und Verfügbarkeit werden unter Ihrer Server-IP angezeigt, nicht unter dem gewünschten Land;
• Der Agent läuft in der Cloud (VPS, GitHub Actions, Container), und die Adresse des Rechenzentrums des Hosters ist bereits als bot-verdächtig markiert;
• Sie haben einen Proxy mit Benutzername und Passwort konfiguriert, und der Browser startet so, als ob es keinen Proxy gäbe.

Wenn Sie sich noch in der Phase „Warum werden Agenten überhaupt blockiert“ befinden – lesen Sie zuerst die Analyse darüber, wie Anti-Bot-Systeme den Agentenbrowser vom Menschen unterscheiden: Dort geht es um Erkennungssignale, und hier – um die praktische Verbindung.

Falle Nr. 1: Chromium akzeptiert Benutzername und Passwort nicht in der Proxy-Zeile

Der häufigste Fehler, der den Menschen Stunden der Fehlersuche kostet. Die klassische Form der Zeile vom Anbieter ist user:pass@host:port. Sie setzen sie in das Startflag des Browsers ein:

--proxy-server="http://user:[email protected]:8080"

Und nichts funktioniert. Chromium unterstützt die Übertragung von Anmeldeinformationen innerhalb des Flags --proxy-server nicht: In der Konsole erscheint ein Fehler über einen nicht unterstützten Proxy, und der Datenverkehr geht vorbei. Wenn Sie die Anmeldeinformationen entfernen und nur host:port belassen, zeigt der Browser im normalen Modus ein Systemfenster zur Eingabe von Benutzername und Passwort an – und damit ist alles vorbei, denn im Headless-Modus gibt es kein Fenster und niemand kann darin klicken.

Das führt zu drei funktionierenden Wegen, aus denen man bewusst wählen sollte:

1. IP-Authentifizierung (Whitelist). Die sauberste Option für Agenten. Sie fügen die Adresse der Maschine, auf der der Agent läuft, in die Whitelist im Anbieter-Dashboard ein – und verbinden sich dann ganz ohne Benutzername und Passwort, einfach mit der Zeile host:port. Das Flag --proxy-server funktioniert dann wie vorgesehen, headless fragt nichts weiter.
2. Übertragung der Anmeldeinformationen auf API-Ebene, nicht über das Flag. Playwright, Puppeteer und browser-use können username und password als separate Felder akzeptieren – das ist nicht dasselbe Mechanismus wie das Kommandozeilenflag, und es funktioniert. Dies ist geeignet, wenn Sie den Agenten selbst programmieren.
3. Lokaler Relay. Sie richten einen Proxy ohne Passwort ein, der Anfragen an einen Upstream mit Passwort weiterleitet, und geben dem Agenten die lokale Adresse an. Dies ist eine Option für Fälle, in denen die Whitelist nicht verfügbar ist: zum Beispiel, wenn die IP der Maschine schwankt.

Playwright MCP: eine Konfiguration, die wirklich funktioniert

Playwright MCP von Microsoft ist heute der De-facto-Standard für Agenten, die einen echten Browser benötigen. Der Proxy wird direkt in der Konfiguration des MCP-Clients über Serverargumente festgelegt:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

Wichtig hier sind die Punkte:

• --proxy-server akzeptiert sowohl HTTP- als auch SOCKS5-Adressen in der Form socks5://host:port. Ohne Anmeldeinformationen – siehe die vorherige Falle.
• --proxy-bypass – eine durch Kommas getrennte Liste von Domains, die den Proxy umgehen. Keine dekorative Option: Wenn der Agent interne Dienste oder eine lokale API hat, ist es überflüssiger Datenverkehr, sie über einen Residenzkanal zu leiten – das kostet pro Gigabyte.
• --isolated hält das Profil im Speicher und schreibt es nicht auf die Festplatte. Nützlich, wenn jede Aufgabe mit einem leeren Blatt beginnen soll. Die Kehrseite ist, dass Cookies nicht über Neustarts hinweg bestehen bleiben und jede Sitzung für die Website wie ein neuer Besucher aussieht.
• --user-data-dir – im Gegensatz dazu ein dauerhaftes Profil. Für Szenarien mit Authentifizierung verwenden Sie dies, nicht die Isolation, und stellen Sie sicher, dass die IP festgelegt ist (siehe den Abschnitt über Sticky weiter unten).
• --storage-state ermöglicht es, gespeicherte Cookies und localStorage in eine isolierte Sitzung einzufügen – ein Kompromiss zwischen den beiden vorherigen.
• --allowed-origins und --blocked-origins beschränken, wohin der Agent überhaupt gehen kann. Unterschätzte Einsparungen: Ein Agent, der sich in Analytik und Werbedomains vertieft, kann leicht den Datenverbrauch verdreifachen.
• --device (zum Beispiel "iPhone 15") und --user-agent ändern, als welcher Browser sich der Agent präsentiert. Stellen Sie sie konsistent mit dem Typ des Proxys ein: Ein mobiler User-Agent über einer Rechenzentrums-IP ist ein Widerspruch, den das Anti-Bot-System sofort erkennt.

Besonders zu --cdp-endpoint: Es verbindet MCP mit einem bereits laufenden Browser. Dann wird der Proxy nicht über die MCP-Flags, sondern beim Start dieses Browsers konfiguriert – ein typischer Grund, warum „der Proxy konfiguriert ist, die IP aber die alte bleibt“.

browser-use: Proxy über ProxySettings

Wenn der Agent auf browser-use basiert, geht die Konfiguration in ein Einstellungsobjekt, und hier können Benutzername und Passwort übergeben werden – sie gehen über die API, nicht über die Kommandozeile:

from browser_use import Browser, ProxySettings
proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1')
browser = Browser(proxy=proxy)

Das Feld server ist obligatorisch, die anderen sind optional. Dasselbe Prinzip gilt auch im reinen Playwright: Der Proxy wird entweder global beim Start des Browsers oder separat für jeden Kontext über browser.newContext({ proxy: { server: ... } }) festgelegt. Letzteres ist der Schlüssel zu parallelen Agenten: Jeder Kontext erhält seine eigene Ausgangsadresse, und zehn Aufgaben teilen sich nicht eine IP.

Cloud-Browser: Proxy auf Sitzungsebene

Bei Browserbase und ähnlichen Diensten lebt der Browser in einer fremden Cloud, daher sind Ihnen die Startflags nicht zugänglich – der Proxy wird in den Sitzungseinstellungen konfiguriert, normalerweise in einer Zeile wie http://benutzer:passwort@gateway:port in der Umgebungsvariable des MCP-Servers. Die Einschränkung von Chromium stört hier nicht: Der Cloud-Anbieter analysiert selbst die Zeile und konfiguriert den Browser von innen.

Praktischer Hinweis: Cloud-Browser haben einen eigenen Pool von Proxys, und dieser ist für alle Kunden gemeinsam. Wenn die Aufgabe empfindlich auf den Ruf der Adresse reagiert – z.B. beim Einloggen oder bei der Arbeit mit einer Plattform, auf der Sie bereits bekannt sind – ist Ihr Kanal vorhersehbarer als der allgemeine.

Rotation oder Fixierung: Wählen Sie je nach Aufgabentyp

Ein Anfängerfehler ist es, die Rotation für jede Anfrage zu aktivieren und sich zu wundern, warum der Agent sich abmeldet. Agentenszenarien haben zwei Modi, die nicht austauschbar sind:

• Rotation für jede Anfrage (bei ProxyCove ist das Port 824) – für Erkundungen: Um 100 Produktkarten zu durchlaufen, Ergebnisse zu sammeln, Preise in verschiedenen Regionen zu überprüfen. Jede Anfrage kommt von einer neuen Adresse, es ist schwierig, sie miteinander zu verbinden.
• Fixierte Sitzung (Ports 10000+, Wechselintervall von 1 bis 120 Minuten) – für alles, was aus Schritten besteht: Einloggen, Warenkorb, mehrseitiges Formular, langer Dialog mit der Benutzeroberfläche. Wenn sich die IP mitten in der Kette ändert, wird die Website im besten Fall um eine erneute Authentifizierung bitten, im schlimmsten Fall die Sitzung als verdächtig markieren.

Der Agent arbeitet fast immer im zweiten Modus: Er führt per Definition eine Abfolge von Schritten aus, nicht nur einen Schuss. Einzelheiten zur Auswahl des Intervalls und typische Fehler sind im Leitfaden beschrieben, wann Sticky-Sitzungen benötigt werden und wie man sie konfiguriert.

Fünf Fallstricke

1. SOCKS5 mit Authentifizierung in Chromium. Die Syntax socks5:// gibt es in Playwright, aber die Kombination „SOCKS5 plus Benutzername und Passwort“ ist in Chromium-basierten Browsern historisch problematisch – der entsprechende Antrag im Playwright-Tracker ist seit November 2021 offen. Wenn es eine Wahl gibt, verwenden Sie für Agenten den HTTP(S)-Kanal, er ist vorhersehbarer.
2. DNS- und WebRTC-Lecks. Der Datenverkehr läuft über den Proxy, während die Namen direkt aufgelöst werden oder WebRTC die echte Adresse preisgibt – und die ganze Tarnung verliert ihren Sinn. Dies sollte vor dem Start des Agenten überprüft werden: wie man WebRTC beim Arbeiten über Proxys verbirgt.
3. Asynchronität von Geo und Locale. IP in Deutschland, Zeitzone der Maschine in Moskau, Sprache der Benutzeroberfläche auf Englisch – eine Kombination, die von selbst wie Automatisierung aussieht. In Playwright werden Locale und Zeitzone über die Kontextparameter festgelegt, bringen Sie sie mit dem Land des Proxys in Einklang.
4. Datenverkehr, den Sie nicht bestellt haben. Der Agent öffnet die Seite vollständig, einschließlich Bilder, Schriftarten und Werbeskripte. Auf einem Residenzkanal mit Bezahlung pro Gigabyte ist dies ein erheblicher Kostenfaktor – blockieren Sie überflüssige Domains und deaktivieren Sie, wo möglich, das Laden von Medien.
5. Proxy ist nicht dort konfiguriert, wo der Browser startet. Bei der Arbeit über --cdp-endpoint, über eine Docker-Hülle oder über einen Cloud-Service haben die MCP-Flags keinen Einfluss auf die tatsächliche Verbindung. Das Erste, was Sie nach der Konfiguration tun sollten, ist, den Agenten zu zwingen, einen beliebigen IP-Prüfdienst zu öffnen und sicherzustellen, dass die Adresse und das Land die richtigen sind.

Welchen Proxy-Typ für den Agenten wählen

Die Regel ist einfach: Je näher die Aufgabe an einem echten Benutzer ist, desto „menschlicher“ sollte die Adresse sein.

• Residenzproxies – die Basis für Agenten. Dies sind Adressen von Heim-Anbietern, und für die Website sieht der Agent aus wie ein normaler Besucher. Notwendig überall dort, wo es Cloudflare, regionale Preise und jegliche Hinweise auf Anti-Bots gibt.
• Mobile Proxys – schwere Artillerie für soziale Netzwerke und Plattformen, wo man mit Konten besonders sensibel umgeht. Hinter einer mobilen Adresse sitzen Tausende von echten Abonnenten, weshalb es teuer für die Plattform ist, sie ganz zu sperren.
• Rechenzentrumsproxies – für interne APIs, Testumgebungen und offene Quellen ohne Schutz. Schnell und günstig, aber auf geschützten Websites wird der Agent fast sofort auf eine Herausforderung stoßen.

Ein nützlicher Punkt für Agentenszenarien: Der Wechsel des Protokolls bei ProxyCove erfolgt durch Ersetzen des Präfixes in der Verbindungszeile – HTTP, HTTPS und SOCKS5 sind auf demselben Proxy verfügbar, der Proxy selbst muss nicht umkonfiguriert werden. Es gibt mehr als 195 Länder im Pool, sodass „dem Agenten lokale Ergebnisse zu zeigen“ durch die Auswahl des Landes beim Kauf gelöst wird.

Fazit

Die Verbindung eines Proxys mit einem KI-Agenten ist nicht nur eine Zeile, sondern drei aufeinanderfolgende Lösungen: wie man sich authentifiziert (für einen headless-Agenten ist es fast immer die IP-Whitelist, nicht das Passwort), wo man den Proxy festlegt (MCP-Flags, Einstellungsobjekt oder Parameter der Cloud-Sitzung – aber unbedingt dort, wo der Browser tatsächlich gestartet wird) und in welchem Modus man arbeitet (für mehrstufige Szenarien – eine feste Adresse, nicht Rotation für jede Anfrage). Plus eine obligatorische Überprüfung auf DNS- und WebRTC-Lecks vor dem produktiven Start.

Führen Sie dies einmal sorgfältig durch – und der Agent wird aufhören, Token für Gespräche mit Captchas zu verschwenden. Residenzproxies von ProxyCove werden in wenigen Minuten mit Playwright MCP und browser-use verbunden, die Abrechnung erfolgt nach Datenverkehr, die IP-Whitelist für den Headless-Modus wird im Dashboard aktiviert.