Repository navigation
Frequently Asked Questions
No: only the hosts in intercept.hosts, and a lone * is refused. Intercepting everything breaks every app that pins certificates, and mints certificates nobody asked for. Everything else is tunnelled untouched. See In-Depth Configuration.
No, by design: a MITM proxy that doesn't verify the far end silently downgrades the security of everything through it. For lab services with private certificates, add their CA with upstream.extra_ca_file.
Yes, on both sides, and the sides needn't match: an HTTP/2 client can reach an HTTP/1.1 origin and the other way round. Middleware sees the same Flow either way. HTTP/3 (QUIC) isn't supported.
Subclass Middleware, register it in middleware.available, and name it in middleware.chain. See Writing Middleware.
No. The upgrade is forwarded and, once it succeeds, the connection is relayed as raw bytes; no middleware runs for WebSocket flows.
No. There's no flow history or replay. The access log (proxy.access_log) writes one line per flow, and your own middleware can store whatever it likes.
Some apps pin their certificates, and Android apps ignore user-installed CAs unless they opt in. Leave those hosts off the allowlist and they work untouched.
mitm-proxy | Async Python MITM proxy with a self-signed CA — HTTP/1.1 & HTTP/2, pluggable middleware for inspecting and rewriting traffic in flight.
GitHub • Releases • Issues • Changelog • Contributing
This wiki is generated from docs/wiki/ on every push to main: edits made here are overwritten. Change it with a pull request.
- 🔍 Intercept only the hosts you list; tunnel the rest untouched
- 🔀 HTTP/1.1 and HTTP/2 on both sides, bridged
- 🧩 Python middleware: inspect, rewrite, answer or deny
- 🔐 Its own root CA; origins always verified
- 📈 Prometheus metrics and a read-only status API