Was ist ein MITM-Proxy? Charles, Fiddler und mitmproxy

Ihr Scraper bekommt auf einer Kategorieseite einen 403, obwohl sich dieselbe Seite im Browser problemlos öffnen lässt, und die Fehlermeldung verrät nichts außer dem Statuscode. Nebeneinander würden die Anfrage des Browsers und die Python-Anfrage den Unterschied in einer Minute zeigen, doch HTTPS hält beide verschlossen. Ein MITM-Proxy auf Ihrem eigenen Computer öffnet dieses Siegel, und zwar nur für Sie.

Dieser Leitfaden erklärt, wie ein MITM-Proxy HTTPS lesbar macht, vergleicht Charles, Fiddler und mitmproxy samt ihren Lizenzbedingungen von 2026 und behandelt das Root-Zertifikat, Ihre eigenen mobilen Apps, ein getestetes Python-Setup und die Verkettung mit einem Upstream-Proxy. Alles setzt Ihr eigenes Gerät und Ihre eigene App voraus oder ein System, für dessen Test Sie eine schriftliche Erlaubnis haben.

Was ist ein MITM-Proxy?#

„Man-in-the-Middle“ bezeichnet einen Angriff: Jemand schiebt sich unbemerkt zwischen zwei Parteien und liest mit, was sie einander senden. Ein MITM-Proxy nutzt dieselbe Position zum Debuggen. Sie installieren das Tool, es geht um Ihren eigenen Datenverkehr, und seinem Zertifikat vertrauen Sie selbst. Getäuscht wird also niemand. Unternehmen nutzen die Technik zur TLS-Inspektion auf den Rechnern ihrer Mitarbeitenden; darum geht es in Proxy und Firewall.

Ein normaler Forward-Proxy (wie ein Proxy-Server funktioniert) sieht bei einer HTTPS-Anfrage nur den Zielhost, und zwar aus der Zeile CONNECT example.com:443, und transportiert danach verschlüsselte Bytes. Ein MITM-Proxy beendet die verschlüsselte Verbindung auf Ihrem Rechner und sieht deshalb die vollständige URL, jeden Header und den Body.

Wie öffnet ein MITM-Proxy HTTPS-Verkehr?#

RFC 9110 beschreibt einen Tunnel als blindes Relais, das Nachrichten unverändert weiterreicht. Ein normaler Proxy hält sich nach CONNECT an diese Regel; ein MITM-Proxy bricht sie absichtlich, und zwar für Clients, die seinem Zertifikat vertrauen. Nach der Beschreibung des Ablaufs in der mitmproxy-Dokumentation:

1. Der Client sendet CONNECT example.com:443 an das lokale Tool.
2. Das Tool antwortet mit 200 Connection Established, als hätte es den Tunnel geöffnet.
3. Der Client beginnt den TLS-Handshake und nennt den Host im SNI-Feld.
4. Das Tool verbindet sich per TLS mit diesem Host und liest die Namen (CN und SAN) im Zertifikat des Servers.
5. Es erzeugt ein Zertifikat mit diesen Namen und signiert es mit seinem lokalen Root-Zertifikat (der CA, Certificate Authority, also Zertifizierungsstelle).
6. Vertraut der Client dieser CA, wird der Handshake abgeschlossen, und das Tool liest den Verkehr im Klartext, bevor es ihn zum Server hin neu verschlüsselt.

Vertraut der Client der CA nicht, scheitert Schritt 6 mit einem Zertifikatsfehler, und genau so soll es sein. Ein Proxynet-Gateway führt Schritt 5 nie aus: Es leitet den CONNECT-Tunnel blind weiter, deshalb braucht ein HTTPS-Proxy kein Root-Zertifikat auf Ihrem Gerät.

Charles, Fiddler und mitmproxy im Vergleich#

Grundlage sind die eigenen Seiten der Hersteller im September 2026; verglichen werden nur Lizenzmodelle, keine Preise.

Charles und Fiddler Everywhere passen zu mobilen QA-Teams, die Anfragen in einem Fenster bearbeiten. mitmproxy passt zu Entwicklern, die die Prüfung in einer Testsuite oder in der CI haben wollen, wo jeder Schritt eine Python-Funktion ist. Burp Suite zielt auf Sicherheitstests, und die sind nicht Thema dieses Leitfadens.

Was ist Charles Proxy und wann sollten Sie das Tool wählen?#

Charles ist eine Desktop-App, die Sie 30 Tage lang testen können, bevor Sie eine Nutzerlizenz kaufen. Charles entschlüsselt nur die Hosts, die auf der Liste unter SSL Proxying stehen (* steht für alle Hosts), und leitet anderen HTTPS-Verkehr ungeöffnet weiter. Ein Tester stellt den WLAN-Proxy des iPhones auf den Laptop und Port 8888 ein, erlaubt das Gerät, wenn Charles nachfragt, und nutzt dann Breakpoints, um Anfragen zu bearbeiten, Map Local, um aus einer Datei zu antworten, und Throttling, um ein langsames Netz nachzuahmen.

Was ist Fiddler? Classic und Everywhere#

Fiddler Classic läuft nur unter Windows, wird nicht mehr weiterentwickelt und bietet FiddlerScript. Seit dem 3. August 2026 erlaubt seine Lizenz nur noch die nicht kommerzielle Nutzung. Kommerzielle Nutzer hatten bis zum 17. September 2026 Zeit für den Umstieg, und eine kostenpflichtige Classic-Lizenz gibt es nicht.

Fiddler Everywhere ist das kommerzielle Produkt: Windows, macOS und Linux, ein Abonnement nach 10 Tagen Testphase, Unterstützung für HTTP/2 und TLS 1.3 sowie Port 8866. Sie schalten die HTTPS-Erfassung ein, vertrauen seinem Root-Zertifikat und filtern die Sitzungen nach Host.

Was ist mitmproxy? Drei Oberflächen und Python-Addons#

mitmproxy steht unter der MIT-Lizenz; Version 12.2.3 (12. Mai 2026) setzt Python 3.12 oder neuer voraus. Es bringt mitmproxy (Terminalansicht), mitmweb (Browseransicht) und mitmdump (ohne Oberfläche, für Skripte und CI) mit, alle standardmäßig auf Port 8080.

Beim ersten Start erzeugt mitmproxy seine CA in ~/.mitmproxy, einmalig für diese Installation: Der private Schlüssel (mitmproxy-ca.pem) liegt neben den Zertifikatsdateien für die einzelnen Plattformen (mitmproxy-ca-cert.pem, .p12, .cer). Ist der Proxy auf einem Gerät eingestellt, bietet mitm.it die passende Datei und die Installationsschritte an. Ein Addon ist eine Python-Datei, deren Funktionen nach Ereignissen wie response benannt sind.

Wozu brauchen Sie ein Root-Zertifikat, und ist das sicher?#

Wer den privaten Schlüssel einer CA besitzt, kann für jede Website ein Zertifikat erzeugen, das auf jedem Gerät, das dieser CA vertraut, gültig aussieht. Das Risiko liegt in diesem Schlüssel, nicht im Tool:

• Nur eine CA, die Ihr eigenes Tool erzeugt hat. Unser Leitfaden zur Sicherheit kostenloser Proxys rät davon ab, ein Zertifikat zu installieren, das ein Proxy-Dienst verlangt, und das gilt weiterhin: Mit einer fremden CA kann ein Unbekannter Ihren Verkehr lesen. Ein Tool auf Ihrem eigenen Computer ist etwas anderes, denn sein Schlüssel verlässt Ihren Rechner nie.
• Nur auf Testgeräten, nur für den Test. Geben Sie ~/.mitmproxy nicht weiter, committen Sie den Ordner nicht, und entfernen Sie die CA, wenn Sie fertig sind.
• Lassen Sie die Prüfungen des Tools eingeschaltet. Die Option ssl_insecure von mitmproxy überspringt die Zertifikatsprüfung zum Server hin, und ihr Hilfetext warnt, dass mitmproxy selbst dadurch abgehört werden kann.

So entfernen Sie die CA:

• Windows: certmgr.msc > Vertrauenswürdige Stammzertifizierungsstellen > Zertifikate.
• macOS: Löschen Sie das Zertifikat des Tools in der Schlüsselbundverwaltung.
• iPhone: Einstellungen > Allgemein > VPN und Geräteverwaltung > das Profil > Profil entfernen.
• Android (Pixel): Einstellungen > Sicherheit und Datenschutz > Weitere Sicherheitseinstellungen > Verschlüsselung und Anmeldedaten > Nutzeranmeldedaten; bei anderen Herstellern weicht der Weg vor den letzten beiden Schritten ab.

Den Datenverkehr Ihrer eigenen mobilen App auf Android und iPhone sehen#

Stellen Sie den WLAN-Proxy des Smartphones auf die IP-Adresse Ihres Computers und den Port des Tools ein, wie in Proxy auf dem Android-Smartphone einrichten oder Proxy auf iPhone und iPad einrichten beschrieben.

Android. Laut der Dokumentation zur Netzwerksicherheitskonfiguration vertrauen Apps, die auf Android 7.0 (API-Level 24) oder neuer ausgerichtet sind, standardmäßig nur System-CAs. Ihre App kann also mit einem TLS-Fehler scheitern, während der Browser funktioniert. Fügen Sie in Ihrer eigenen App einen debug-overrides-Block hinzu:

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
</network-security-config>

Verweisen Sie im Manifest mit android:networkSecurityConfig="@xml/network_security_config" darauf. Android ignoriert den Block, wenn android:debuggable auf false steht, sodass ein Release-Build die normalen Vertrauensregeln behält.

iPhone. Aktivieren Sie nach der Installation des Profils das volle Vertrauen unter Einstellungen > Allgemein > Info > Zertifikatsvertrauenseinstellungen.

Pinning. Eine App mit Certificate Pinning lehnt das Zertifikat des Tools ab. In Ihrer eigenen App passen Sie das Pinning im Test-Build an. Bei der App eines anderen ist Pinning die Entscheidung des Entwicklers, und an dieser Stelle hört dieser Leitfaden auf.

Anfragen abfangen, bearbeiten und wiederholen#

Mit allen drei Tools können Sie eine Anfrage anhalten und einen Header ändern, bevor sie hinausgeht, eine Anfrage mit einer lokalen Datei beantworten, um einen Fehlerbildschirm zu testen, und eine gespeicherte Anfrage erneut senden. So lässt sich ein Fehler, der einmal am Tag auftritt, jederzeit wiederholen. In mitmproxy speichert -w flows.mitm die Flows, und -C flows.mitm spielt sie erneut ab. Wiederholen Sie Anfragen nur gegen Ihre eigene API oder einen Endpunkt, den Sie testen dürfen, und bleiben Sie innerhalb seiner Rate Limits.

Für eine Hintergrundanfrage einer Webseite reichen die DevTools (die XHR-Anfrage finden); das lokale Tool ist für Skripte und Apps da.

Einen Python-Scraper mit einem MITM-Proxy debuggen#

Zurück zum 403: Wir leiten das Skript durch mitmdump, protokollieren jede Antwort und geben bei jedem Fehler die Anfragedetails aus. Getestet mit Python 3.13, mitmproxy 12.2.3 und Requests 2.34.2 (pip install mitmproxy requests).

Das Addon debug_addon.py gibt pro Antwort eine Zeile aus. Bei 4xx und 5xx zeigt es zusätzlich die Header, die sich meist von denen eines Browsers unterscheiden, ob ein Cookie gesendet wurde, und den Anfang des Bodys:

"""mitmdump-Addon: eine Zeile pro Antwort, Anfragedetails bei jedem 4xx und 5xx."""
from mitmproxy import http

WATCH = ("User-Agent", "Accept", "Accept-Language", "Accept-Encoding")


def response(flow: http.HTTPFlow) -> None:
    req, resp = flow.request, flow.response
    print(f"{resp.status_code} {req.method} {req.pretty_url}")
    if resp.status_code < 400:
        return
    for name in WATCH:
        print(f"    {name}: {req.headers.get(name, '(not sent)')}")
    print(f"    Cookie: {'sent' if 'Cookie' in req.headers else 'not sent'}")
    body = resp.get_content(strict=False) or b""  # bei gzip oder br bereits entpackt
    print(f"    body: {body[:300].decode('utf-8', 'replace')!r}")

Das Skript scraper_debug.py nutzt den Proxy nur, wenn DEBUG_PROXY gesetzt ist, und vertraut der lokalen CA über verify. Die Requests-Dokumentation warnt, dass verify=False eine Anwendung anfällig für MitM-Angriffe macht; deshalb taucht es hier nirgends auf:

"""Seiten mit Requests abrufen; mit gesetztem DEBUG_PROXY laufen sie durch ein lokales mitmdump."""
import os
import sys
from pathlib import Path

import requests

DEBUG_PROXY = os.environ.get("DEBUG_PROXY")  # z. B. http://127.0.0.1:8080
MITM_CA = Path.home() / ".mitmproxy" / "mitmproxy-ca-cert.pem"

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                  "(KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36",
    "Accept-Language": "en-GB,en;q=0.9",
})


def request_options():
    options = {"timeout": (5, 30)}  # (Verbindungsaufbau, Lesen) in Sekunden
    if DEBUG_PROXY:
        if not MITM_CA.is_file():
            sys.exit(f"{MITM_CA} not found: start mitmdump once, it creates the CA there.")
        # Pro Anfrage übergeben: Ein Wert in Session.proxies kann von HTTPS_PROXY überschrieben werden.
        options["proxies"] = {"http": DEBUG_PROXY, "https": DEBUG_PROXY}
        options["verify"] = str(MITM_CA)  # der lokalen CA vertrauen, nie verify=False
    return options


def fetch(url):
    try:
        return session.get(url, **request_options())
    except requests.exceptions.SSLError as exc:
        sys.exit(f"TLS check failed for {url}: is {MITM_CA} the CA of the "
                 f"mitmdump that is running?\n{exc}")
    except requests.exceptions.ProxyError as exc:
        sys.exit(f"Debug proxy {DEBUG_PROXY} did not answer: is mitmdump running?\n{exc}")


if __name__ == "__main__":
    for url in sys.argv[1:] or ["https://httpbin.org/headers"]:
        resp = fetch(url)
        print(resp.status_code, url)
        for name, value in resp.request.headers.items():
            print(f"    {name}: {value}")

Starten Sie mitmdump nur auf der Loopback-Adresse:

mitmdump --listen-host 127.0.0.1 -p 8080 -s debug_addon.py -w flows.mitm

Führen Sie das Skript dann in einem zweiten Terminal aus (in PowerShell setzen Sie vorher $env:DEBUG_PROXY = "http://127.0.0.1:8080"):

DEBUG_PROXY=http://127.0.0.1:8080 python scraper_debug.py https://httpbin.org/headers https://httpbin.org/status/403

Das mitmdump-Fenster zeigte Folgendes (Verbindungszeilen entfernt):

200 GET https://httpbin.org/headers
403 GET https://httpbin.org/status/403
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
    Accept: */*
    Accept-Language: en-GB,en;q=0.9
    Accept-Encoding: gzip, deflate, br
    Cookie: not sent
    body: ''

Öffnen Sie die Seite jetzt in einem Browser, der auf denselben Proxy eingestellt ist. Accept: */* gegenüber dem text/html,... des Browsers oder ein fehlendes Cookie von einer vorherigen Seite sind typische Befunde; Letzteres heißt, dass das Skript einen Schritt ausgelassen hat (Sitzungen und Cookies in Python). Lehnt die Website Clients ohne Browser absichtlich ab, ist das ihre Antwort: Nutzen Sie ihre API oder bitten Sie um Erlaubnis.

Eine falsche CA-Datei stoppte das Skript mit CERTIFICATE_VERIFY_FAILED und unserem Hinweis. mitmdump --set server=false -C flows.mitm -s debug_addon.py spielte beide Anfragen erneut ab und beendete sich, ohne einen Listener zu öffnen.

Der Server sieht den TLS-Handshake des Tools, nicht den Ihres Skripts. Eine Website, die TLS-Fingerabdrücke prüft, antwortet deshalb bei eingeschaltetem Tool womöglich anders; vergleichen Sie mit einem Lauf ohne DEBUG_PROXY. Wiederholungen bei 429 behandelt HTTP-Statuscodes beim Web Scraping, Umgebungsvariablen Proxy-Nutzung mit wget, die Rotation Proxys in Python rotieren und die Wahl der Bibliothek HTTPX, Requests und AIOHTTP im Vergleich.

Aus einem anderen Land testen: das lokale Tool mit einem Proxy verketten#

Um die Preise zu sehen, die Ihre App einem Nutzer in Deutschland zeigt, schicken Sie den Verkehr des Geräts an das lokale MITM-Tool (dort findet die Entschlüsselung statt), von dort an einen Upstream-Proxy und weiter zum Ziel. Bei HTTPS-Zielen transportiert der Upstream-Proxy nur den neu verschlüsselten Tunnel; Proxynet entschlüsselt ihn nicht.

mitmproxy. Der Upstream-Modus leitet jede Anfrage weiter, und upstream_auth fügt Basic-Authentifizierung hinzu:

mitmdump --listen-host 127.0.0.1 --mode upstream:http://pr.proxynet.io:8000 --set upstream_auth=user:pass -s debug_addon.py

Wir haben das gegen einen lokalen Proxy getestet, der ein Passwort verlangt. Mit falschem Passwort bekam das Skript von mitmdump einen 502, und das Log von mitmdump nannte die Ursache: Der Upstream hatte das CONNECT mit 407 abgelehnt.

Charles. External Proxies nimmt getrennte Adressen für HTTP, HTTPS und SOCKS entgegen, mit Basic- oder NTLM-Authentifizierung und einer Bypass-Liste mit Platzhaltern.

Fiddler Everywhere. Unter Settings > Gateway tragen Sie einen manuellen Proxy-String ein, und die Dokumentation nennt für die Upstream-Authentifizierung Kerberos, Negotiate und NTLM, aber keinen Benutzernamen mit Passwort. Bei Proxynet autorisieren Sie stattdessen die IP-Adresse Ihres Computers (user:pass und IP-Whitelist).

Nutzen Sie einen Mobile-Proxy für eine IP eines Mobilfunkanbieters oder einen Residential-Proxy für einen Heimanschluss; das vollständige Szenario beschreibt unsere Seite zu App-Tests.

Wofür wird ein MITM-Proxy genutzt?#

• Scraper und Browser: Finden Sie den Header, der aus einem 200 einen 403 macht (HTTP-Statuscodes).
• Postman: Sehen Sie die endgültigen Header, die Postman sendet (Proxy-Einstellungen in Postman).
• Ihre eigene App: Verfolgen Sie API-Aufrufe und Fehler auf einem Testsmartphone (App-Tests).
• Proxy-Header: Erkennen Sie Via oder X-Forwarded-For bei unverschlüsseltem HTTP (Transparenter, anonymer und Elite-Proxy).
• Ein 407: Prüfen Sie, ob die Zugangsdaten beim Upstream-Proxy ankommen (Proxy-Authentifizierung).
• Proxy-Prüfungen: Kontrollieren Sie vor einem Job die Ausgangsadresse und die Antworten (So testen Sie einen Proxy).

Häufige Fehler#

• Die CA installiert lassen. Wer später an den Schlüssel gelangt, kann sich diesem Gerät gegenüber als jede beliebige Website ausgeben.
• verify=False ausliefern. Richten Sie verify stattdessen auf die CA-Datei.
• Erwarten, dass eine Android-App einer Nutzer-CA vertraut. Apps ab API-Level 24 ignorieren sie außerhalb eines Debug-Builds, der sie ausdrücklich erlaubt.
• SSL Proxying für den Host in Charles auslassen. Sie sehen verschlüsselte CONNECT-Einträge, aber keinen Inhalt.
• Auf allen Schnittstellen lauschen. Ohne --listen-host band sich mitmdump in unserem Test an 0.0.0.0 und ::. Binden Sie es an 127.0.0.1, außer ein Smartphone muss sich verbinden.
• Flow-Dateien sorglos weitergeben. Sie enthalten Cookies und Header.
• Fiddler Classic nach August 2026 beruflich nutzen. Seine Lizenz gilt nur für die nicht kommerzielle Nutzung.

Entscheidungshilfe#

Häufige Fragen#

Ist die Nutzung eines MITM-Proxys legal?#

Auf Ihrem eigenen Gerät und mit Ihrer eigenen App oder auf einem System, für dessen Test Sie eine schriftliche Erlaubnis haben, ist er ein Debugging-Werkzeug. Den Verkehr anderer heimlich mitzulesen ist eine ganz andere Handlung. Zum Scraping lesen Sie Ist Web Scraping legal?.

Ist mitmproxy sicher?#

Das Tool ist Open Source und läuft lokal. Das Risiko ist der private Schlüssel der CA in ~/.mitmproxy: Halten Sie ihn geheim, installieren Sie die CA nur auf Testgeräten und entfernen Sie sie danach.

Ist Fiddler Classic noch kostenlos, und wie unterscheidet es sich von Fiddler Everywhere?#

Seit dem 3. August 2026 ist Fiddler Classic nur noch für die nicht kommerzielle Nutzung kostenlos; es läuft unter Windows und wird nicht mehr weiterentwickelt. Fiddler Everywhere ist das kostenpflichtige, plattformübergreifende Produkt mit Unterstützung für HTTP/2 und TLS 1.3.

Gibt es eine kostenlose Alternative zu Charles Proxy?#

mitmproxy ist Open Source und läuft auf denselben Plattformen; mitmweb gibt ihm eine Browseransicht. Charles selbst bietet eine Testphase von 30 Tagen.

Warum fehlt der Verkehr meiner App, obwohl das Zertifikat auf Android installiert ist?#

Apps, die auf API-Level 24 oder neuer ausgerichtet sind, vertrauen standardmäßig nur System-CAs. Erlauben Sie Nutzer-CAs im Debug-Build Ihrer eigenen App mit debug-overrides, und passen Sie das Pinning im Test-Build an, falls die App Zertifikate pinnt.

Was ist der Unterschied zwischen einem MITM-Proxy, einem normalen Proxy und einem VPN?#

Ein normaler Proxy und ein VPN transportieren verschlüsselten Verkehr ungelesen und ändern Ihre Ausgangs-IP (Proxy und VPN im Vergleich). Ein MITM-Proxy öffnet ihn auf Ihrem Computer und behält Ihre IP bei, solange er nicht mit einem Upstream-Proxy verkettet ist.

Fazit#

Ein MITM-Proxy ist ein Werkzeug, um Ihren eigenen Datenverkehr zu lesen, mit einer CA, die lokal, vorübergehend und nur auf Testgeräten bleibt. Charles und Fiddler Everywhere eignen sich für die Arbeit in einem Fenster, mitmproxy für Skripte und CI. Muss ein Test aus einem anderen Land kommen, verketten Sie das lokale Tool mit einem Upstream-Proxy; der Einstieg dafür ist unsere Seite zu App-Tests.