Tutorials

Verwenden von Fiddler zur Überprüfung des CaptchaAI-API-Verkehrs

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.php echte Antworten statt ERROR_WRONG_USER_KEY liefert.
  • 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 Hostcontainsocr.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:

  1. Request-Body prüfen – stellen Sie sicher, dass alle Parameter korrekt sind
  2. Parameter bearbeiten – ändern Sie method, googlekey oder pageurl, um andere Werte zu testen
  3. Fortsetzen – klicken Sie auf „Bis zum Abschluss ausführen“, um die geänderte Anfrage zu senden
  4. 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 WiedergabeAnfragen 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.


Verwandte Leitfäden

Kommentare sind für diesen Artikel deaktiviert.