Fiddler ist ein lokaler HTTPS-Proxy, der jede Anfrage und Antwort zwischen Ihrem Code und der CaptchaAI-API im Klartext sichtbar macht – inklusive Payload, Header und Timing. Genau das brauchen Sie, wenn ein Solve fehlschlägt, Ihre Logs aber zu wenig verraten: Sie sehen, welcher Sitekey ankommt, welchen Fehlercode res.php liefert und wie lange der Server wirklich braucht.
Voraussetzungen für die Traffic-Analyse
Bevor Sie den ersten Request mitschneiden, sollten drei Dinge bereitstehen:
- Fiddler – Everywhere läuft plattformübergreifend, Classic nur unter Windows (dafür mit FiddlerScript).
- Ein gültiger CaptchaAI-API-Schlüssel, damit
in.phpechte Antworten stattERROR_WRONG_USER_KEYliefert. - Zugriff auf den eigenen Client-Code – hier am Beispiel Python und Node.js über den Proxy umgeleitet.
Wann sich Fiddler zum Debuggen lohnt
| Szenario | Was Fiddler sichtbar macht |
|---|---|
| Die API liefert Fehler, aber Ihre Logs bleiben dünn | Vollständiger Request-Body, Header und Antwort |
| Solve-Anfragen scheinen zu hängen | Ob die Anfrage den Server erreicht oder in ein Timeout läuft |
| Ein Token wirkt beim Einfügen ungültig | Exakter Token-Inhalt und mögliche Encoding-Probleme |
| Proxy-bezogene Fehler | Ob die Anfrage über den erwarteten Proxy läuft |
| Rate-Limiting | Request-Timing und 429-Antwortmuster |
HTTPS-Entschlüsselung in Fiddler einrichten
Schritt 1: Stammzertifikat installieren und HTTPS-Entschlüsselung aktivieren
Fiddler fängt als lokaler Proxy den HTTPS-Verkehr ab. Für Klartext-Payloads der CaptchaAI-API aktivieren Sie zuerst die HTTPS-Entschlüsselung – die Menüpfade unterscheiden sich je nach Variante:
| Schritt | Fiddler Everywhere | Fiddler Classic (Windows) |
|---|---|---|
| Einstellungen öffnen | Einstellungen → HTTPS | Extras → Optionen → HTTPS |
| Entschlüsselung aktivieren | „HTTPS-Verkehr erfassen“ einschalten | „HTTPS-Verkehr entschlüsseln“ aktivieren |
| Zertifikat vertrauen | Stammzertifikat installieren und im OS-Zertifikatspeicher bestätigen | „Aktionen“ → „Stammzertifikat vertrauen“ |
Schritt 2: Ihren Code über den Fiddler-Proxy leiten
Fiddler lauscht auf 127.0.0.1:8866 (Everywhere) oder 127.0.0.1:8888 (Classic). Richten Sie Ihren Client auf diesen Proxy aus:
Python (requests):
import requests
proxies = {
"http": "http://127.0.0.1:8866",
"https": "http://127.0.0.1:8866",
}
# Submit CAPTCHA task through Fiddler
response = requests.post(
"https://ocr.captchaai.com/in.php",
data={
"key": "YOUR_API_KEY",
"method": "userrecaptcha",
"googlekey": "SITE_KEY",
"pageurl": "https://example.com",
"json": 1,
},
proxies=proxies,
verify=False, # Required for Fiddler's self-signed cert
)
print(response.json())
JavaScript (Node.js mit Axios):
const axios = require("axios");
const HttpsProxyAgent = require("https-proxy-agent");
const agent = new HttpsProxyAgent("http://127.0.0.1:8866");
async function submitTask() {
const response = await axios.post(
"https://ocr.captchaai.com/in.php",
new URLSearchParams({
key: "YOUR_API_KEY",
method: "userrecaptcha",
googlekey: "SITE_KEY",
pageurl: "https://example.com",
json: 1,
}),
{
httpsAgent: agent,
proxy: false, // Disable axios default proxy handling
}
);
console.log(response.data);
}
submitTask();
Hinweis:
verify=False(Python) deaktiviert die SSL-Prüfung für das Abfangzertifikat von Fiddler. Nutzen Sie das nur beim Debuggen – in der Produktion gehört die Zeile wieder entfernt.
CaptchaAI-Traffic gezielt filtern
Ein Host-Filter auf ocr.captchaai.com blendet in einer belebten Sitzung alles Übrige aus:
| Schritt | Fiddler Everywhere | Fiddler Classic |
|---|---|---|
| Filter öffnen | Registerkarte Filter öffnen | Registerkarte Filter öffnen, „Filter verwenden“ aktivieren |
| Host-Regel setzen | Regel Host → contains → ocr.captchaai.com hinzufügen |
unter „Hosts“ die Option „Nur folgende Hosts anzeigen“ wählen und ocr.captchaai.com eintragen |
Danach erscheinen nur noch CaptchaAI-API-Anfragen in der Sitzungsliste.
Anfrage und Antwort im Detail prüfen
Task-Übermittlung (in.php)
Erfassen Sie eine Aufgabenübermittlung, prüfen Sie diese Felder:
| Panel | Worauf Sie achten |
|---|---|
| Header | Content-Type sollte application/x-www-form-urlencoded sein |
| Request-Body | Prüfen Sie, ob key, method, googlekey/sitekey und pageurl korrekt sind |
| Response-Body | Bei Erfolg: {"status":1,"request":"TASK_ID"} |
| Response-Code | 200 = OK, 403 = Problem mit dem API-Schlüssel, 429 = Rate-Limit erreicht |
Ergebnis-Polling (res.php)
Beim Abfragen des Ergebnisses:
| Panel | Worauf Sie achten |
|---|---|
| Request-Body | key, action=get, id=TASK_ID, json=1 |
| Response-Body | CAPCHA_NOT_READY während der Verarbeitung, {"status":1,"request":"TOKEN"} bei Erfolg |
| Timing | Intervall zwischen den Abfragen – mindestens 5 Sekunden |
Typische Fehlerbilder in Fiddler
| Was Sie sehen | Bedeutung |
|---|---|
Im Request-Body ist googlekey leer |
Die Sitekey-Extraktion ist im Upstream fehlgeschlagen |
Antwort: {"status":0,"request":"ERROR_WRONG_USER_KEY"} |
Der API-Schlüssel ist ungültig |
Antwort: {"status":0,"request":"ERROR_ZERO_BALANCE"} |
Das Konto hat kein Guthaben |
Antwort: {"status":0,"request":"ERROR_NO_SLOT_AVAILABLE"} |
Server ausgelastet – erneut versuchen |
| Keine Antwort (Timeout) | Netzwerk oder Proxy blockiert die Verbindung |
| Statuscode 429 | Zu viele Anfragen – Polling verlangsamen |
Timing und Latenz analysieren
Die Timeline-Ansicht zerlegt die Dauer einer Anfrage. Läuft ein Worker etwa auf einem Hetzner-VPS, sehen Sie hier, ob DNS, TCP oder der Server selbst bremst:
| Metrik | Normalwert | Warnsignal |
|---|---|---|
| DNS-Auflösung | < 50 ms | > 500 ms = DNS-Problem |
| TCP-Verbindung | < 100 ms | > 1.000 ms = Netzwerkproblem |
| TLS-Handshake | < 200 ms | > 1.000 ms = Zertifikatsproblem |
| Serverantwort (in.php) | < 500 ms | > 2.000 ms = Serverüberlastung |
| Serverantwort (res.php) | < 200 ms | > 1.000 ms = ungewöhnlich – Status prüfen |
Anfragen mit Breakpoints anhalten und ändern
Breakpoints halten eine Anfrage vor dem Senden an, sodass Sie sie noch verändern können:
Breakpoint setzen
| Aktion | Fiddler Everywhere | Fiddler Classic |
|---|---|---|
| Breakpoint anlegen | Regeln → Regel hinzufügen, Bedingung „URL enthält ocr.captchaai.com/in.php“, Aktion „Pause vor dem Senden“ |
Regeln → Automatische Breakpoints → Vor Anfragen |
| Schnellbefehl | – | bpu ocr.captchaai.com in der QuickExec-Leiste eingeben |
Was Sie am Breakpoint tun
Sobald eine Anfrage pausiert:
- Request-Body prüfen – stellen Sie sicher, dass alle Parameter korrekt sind
- Parameter bearbeiten – ändern Sie
method,googlekeyoderpageurl, um andere Werte zu testen - Fortsetzen – klicken Sie auf „Bis zum Abschluss ausführen“, um die geänderte Anfrage zu senden
- Antwort prüfen – kontrollieren Sie, ob Ihre Änderung das Problem behoben hat
Fehlgeschlagene Anfragen erneut senden
Schlägt eine Anfrage fehl, wiederholen Sie sie direkt aus Fiddler: Rechtsklick auf die fehlgeschlagene Sitzung, dann Wiedergabe → Anfragen erneut ausstellen – identische Header und identischer Body inklusive. Für eine Wiederholung mit Änderungen nutzen Sie den Composer: Rechtsklick → In Composer bearbeiten, Parameter anpassen, Ausführen klicken. So prüfen Sie Fixes ohne Neustart der Anwendung.
Testanfragen im Composer bauen
Mit dem Composer bauen Sie CaptchaAI-Anfragen von Grund auf – schneller, als Code zu schreiben, nur um zu prüfen, ob die API antwortet:
Aufgabenübermittlung:
POST https://ocr.captchaai.com/in.php
Content-Type: application/x-www-form-urlencoded
key=YOUR_API_KEY&method=userrecaptcha&googlekey=SITE_KEY&pageurl=https://example.com&json=1
Ergebnisabfrage:
GET https://ocr.captchaai.com/res.php?key=YOUR_API_KEY&action=get&id=TASK_ID&json=1
Sitzungen für den Support exportieren
Um Debug-Daten mit dem CaptchaAI-Support zu teilen, wählen Sie die relevanten Sitzungen aus und exportieren Sie sie über Datei → Sitzungen exportieren → Ausgewählte Sitzungen im Format HTTPArchive (.har). Entfernen Sie zuerst Ihren API-Schlüssel aus der Exportdatei.
Eine .har-Datei enthält neben dem key auch IP-Adressen und vollständige Header – nach DSGVO personenbezogene Daten. Prüfen Sie vor dem Teilen, was wirklich hinein muss, und schwärzen Sie den Rest:
Find and replace your actual API key with "REDACTED" in the .har file
Fehlerbehebung
| Problem | Ursache | Lösung |
|---|---|---|
| Fiddler zeigt gar keinen Traffic | Code läuft nicht über den Fiddler-Proxy | Proxy auf 127.0.0.1:8866 (Everywhere) bzw. 8888 (Classic) setzen |
| SSL-Zertifikatsfehler | Fiddler-Stammzertifikat ist nicht vertrauenswürdig | Zertifikat neu installieren und in die vertrauenswürdigen Stammzertifikate aufnehmen |
| Response-Body erscheint verstümmelt | Antwort ist komprimiert | „Decode“ in der Symbolleiste aktivieren (oder Regeln → Remove All Encodings) |
| Breakpoints lösen nicht aus | Filter oder Regel passt nicht | Prüfen, ob das URL-Muster exakt ocr.captchaai.com trifft |
| Traffic erscheint, aber der Body ist leer | Content-Length-Mismatch oder Streaming-Antwort | Sitzung anklicken und auf die vollständige Antwort warten |
Häufige Fragen
Warum erscheint kein CaptchaAI-Traffic in Fiddler?
Meist läuft Ihr Code nicht über den Proxy. Prüfen Sie, dass der Client auf 127.0.0.1:8866 (Everywhere) oder 127.0.0.1:8888 (Classic) zeigt und die HTTPS-Entschlüsselung aktiv ist. Ein Host-Filter auf ocr.captchaai.com blendet zusätzlich alles andere aus.
Muss ich verify=False nach dem Debuggen wieder entfernen?
Ja. Die Zeile deaktiviert die SSL-Prüfung und ist nur vertretbar, solange Fiddler mit seinem Abfangzertifikat dazwischenhängt. In der Produktion entfernen Sie sie, damit Zertifikate wieder normal validiert werden.
Funktioniert Fiddler unter macOS und Linux?
Fiddler Everywhere schon – es läuft plattformübergreifend unter Windows, macOS und Linux. Fiddler Classic ist Windows-only, bietet dafür aber FiddlerScript für erweiterte Automatisierung. Für das Debuggen der CaptchaAI-API genügt jede Variante.
Wie verhindere ich, dass mein API-Schlüssel in geteilten Logs landet?
Ersetzen Sie den Schlüssel vor jedem Export durch REDACTED und behandeln Sie .har-Dateien wie sensible Daten – sie enthalten neben dem key auch IP-Adressen und Header. Wer regelmäßig exportiert, rotiert den Schlüssel zusätzlich turnusmäßig.