Was es Neues gibt
Exit-Nodes zu rotieren automatisiert jeder. Die Browser-Signatur darunter ändert sich meistens nie.
Single und Proxy Finder akzeptieren jetzt vier optionale Felder, die bestimmen, welchen Browser dein Request vorgibt: browser, os, version und profile. Der Katalog dahinter ist unter GET /api/profiles öffentlich und erfordert keinen API-Key. Aktuell enthält er 79 Profile für Chrome, Edge, Safari, Firefox und Tor unter Windows, macOS, Android und iOS.
Wenn du keines angibst, ändert Proxy Finder es für dich. Allerdings erst, nachdem eine Site zweimal gezeigt hat, dass sie dein gesendetes Profil ablehnt.
Funktionsweise
Drei der Felder sind für Menschen gedacht, eines für Maschinen.
browser, os und version grenzen den Katalog ein, und du kannst eine beliebige Teilmenge davon senden. os gleicht die Familie ab. Die Angabe von macOS akzeptiert also jedes macOS-Release in der Liste, während das exakte Release-Label auf genau diese Version filtert. Passen weiterhin mehrere Profile, gewinnt die neueste Version, da Aktualität der eigentliche Zweck ist. Alte Major-Versionen sind genau das, worauf Blocklists anspringen.
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://example.com/listing/42",
"browser": "Safari",
"os": "iOS"
}'
Das löst auf das neueste Safari auf iOS im Katalog auf und sendet den User-Agent, die Client Hints und die Header-Reihenfolge, die dazu gehören, genau in dieser Reihenfolge. Die Header-Reihenfolge ist selbst ein Signal, daher wird beim Senden nichts umsortiert.
profile ist das vierte Feld: eine exakte ID aus dem Katalog für Code, der denselben Client weiterverwenden muss, nachdem eine neuere Version erschienen ist. Proxy Finder akzeptiert alle vier in seinem request-Objekt. Die vollständige Parameterliste findest du in der API-Referenz. Die Playground liest denselben Katalog, sodass ihre Dropdowns nur anbieten können, was dein Code auch anfordern kann. Dieselben vier Felder befinden sich in foura_single und foura_proxy auf dem MCP-Server. So kann ein Agent einen Retry als anderer Browser ausführen, anstatt einen reinen 403 zurückzugeben.
Zwei Dinge, die hier bewusst verweigert werden.
Eine Kombination, die der Katalog nicht abbilden kann, führt zu einem Fehler, der nennt, was für diesen Browser verfügbar ist. Ein Fallback auf einen Standardwert würde einen Client senden, den du nicht gewählt hast und in der Response nicht siehst. Eine Profilauswahl mit unblocker: false wird ebenfalls verweigert, da dieses Flag die Header überträgt (was dieses Flag tatsächlich tut). Ein halbes Profil ist schlimmer als gar keins.
Der Katalog selbst wird gemessen, nicht von Hand getippt. Ein Skript schickt jedes Profil durch den realen Request-Pfad und zeichnet auf, was tatsächlich über die Leitung ging. Das ist wichtiger, als es klingt: Zwischen zwei aktuellen Major-Versionen eines Browsers änderte sich der Platzhalter-Brand-String und die Brand-Reihenfolge drehte sich um. Genau solche Details liest ein Detection Service aus.
Impact
Hier ist der Teil, den wir nicht erwartet hatten.
Ein Standardwert ist ein geteilter Standardwert. Der Client, den dein Request vorweist, wenn du nichts angibst, ist genau der, den jeder Request vorweist, der nichts angegeben hat. Eine Defense, die nach einem günstigen Merkmal filtern will, filtert genau danach. Es schlägt zudem auf eine Weise fehl, die unverwechselbar ist: Eine Site, die einen Browser ablehnt, lehnt ihn an jedem deiner Exits ab. Du verbrauchst dein gesamtes Retry-Budget nur, um zu belegen, dass derselbe Client unerwünscht ist.
Wir haben das dreimal bei drei Anbietern gemessen, und das Muster war jedes Mal identisch.
Ein Immobilienportal hinter PerimeterX lehnte neun Versuche mit dem Standardwert ab. Das Ändern nur der Plattform, die der Request angibt (alles andere identisch, derselbe Pool), lieferte die Seite sechs von sechs Malen zurück. Ein Händler für Nahrungsergänzungsmittel hinter Akamai lehnte den Standardwert ab und bediente zwei andere Browser-Familien anstandslos. Eine Finanznachrichten-Site hinter DataDome beantwortete den Standardwert mit einem 401 und einem 774-Byte-Interstitial, während drei andere Profile die echte Seite (etwa 760 KB) jeweils zwölfmal abriefen. Wir haben diesen Test vorwärts und rückwärts laufen lassen, um sicherzugehen, dass die Reihenfolge keinen Einfluss hatte.
Proxy Finder rotiert jetzt also die Browser-Familie, nicht mehr nur den Exit-Node. Zwei unabhaengige Exits muessen ablehnen, bevor rotiert wird, denn eine einzelne Ablehnung ist nur die Meinung eines Exits. Danach folgt das System einer Stufenleiter: Es beginnt mit der kleinstmoeglichen Aenderung, der Plattform, und testet erst danach andere Familien.
Das kostet nichts extra. Die Rotation aendert nur, was ein Retry sendet, nicht, ob ein Retry stattfindet. Requests und Credits pro Task bleiben exakt gleich.
Fuer Power-User
Die Rotation stoert deinen Workflow nicht, und die Regeln dafuer sollte man kennen.
Sie greift nie, wenn du selbst ein Profil benannt hast. Sie greift auch nie, wenn du einen eigenen Header user-agent oder cookie mitgeschickt hast. Das ist der entscheidende Punkt: Ein Clearance-Cookie ist an den Client gebunden, der ihn erhalten hat. Wuerde man die Signatur unter einem funktionierenden Session-Replay rotieren, wuerde das einen bisher erfolgreichen Request zerstoeren. Was du pinnst, bleibt gepinnt.
Nicht jeder Fehler gilt als Grund, das Profil zu wechseln. Ein bekannter Bot-Protection-Vendor zaehlt dazu. Ein reiner Refusal-Status (401, 403, 429, 503) ohne erkannte Vendor-Signatur zaehlt ebenfalls, und genau das war entscheidend. Ein Task meldete acht Status-Ablehnungen und keine Vendor-Erkennung: echte Ablehnungen, die die Rotation ignorierte, weil sie sich ausschliesslich auf den Detektor verliess. Eine fehlende Seite oder ein Laenderblock zaehlen nicht. Das sind Antworten ueber deine URL und deinen Standort, nicht ueber deinen Client.
Du hast vollen Einblick. Eine erfolgreiche Response von Proxy Finder enthaelt profile nur, wenn wir das Profil gewaehlt haben, nie bei deiner eigenen Wahl. Ein fehlgeschlagener Task liefert attemptReport.profilesTried: die gesendeten Familien in Reihenfolge der Nutzung, mit default fuer einen unveraenderten Request. Ohne dieses Feld saehen "wir haben vier Browser getestet und alle wurden abgelehnt" und "wir haben den Browser nie gewechselt" von aussen identisch aus.
Eine Gewohnheit, die sich lohnt: Wenn du testest, ob ein Profil hilft, halte alle anderen Parameter konstant. Scrapflys Uebersicht 2026 ueber Fingerprint-Testing-Tools bringt es auf den Punkt: Wer drei Variablen zwischen Runs aendert, weiss zwar, dass etwas funktioniert hat, aber nicht, welche Aenderung den Ausschlag gab. Gleiches Ziel, gleicher Exit, genau ein Feld geaendert. So sind auch alle oben genannten Zahlen entstanden.
Was kommt als Naechstes?
Die Kandidaten-Stufenleiter waechst nur durch Messung, Ziel fuer Ziel. Eine Familie wird erst aufgenommen, wenn sie nachweislich ein Ziel oeffnet, an dem der Standard gescheitert ist, nicht wegen einer Vermutung. Der Katalog wird bei jedem Engine-Update neu vermessen statt einfach uebernommen.
Das ist die unbequeme Realitaet des Problems. Die beste Client-Signatur ist ein bewegliches Ziel. Sie zu verfolgen ist permanente Arbeit, kein einmaliges Release. Was letztes Quartal gewonnen hat, steht laengst auf einer Blockliste. Genau deshalb ist es ein Feld, das du steuern kannst, und ein lesbarer Katalog, statt eines fest von uns vorgegebenen Werts.