An intercepting proxy sits between your client and the internet so you can see and modify every request and response. Unlike a commercial proxy, whose job is to forward your traffic from another IP, an intercepting proxy's job is to show you what your own software sends. mitmproxy, Charles, Fiddler, Burp Suite and OWASP ZAP are the common ones.
How it reads HTTPS
Plain HTTP is easy to read; the proxy sees the whole request. HTTPS is encrypted, so an intercepting proxy decrypts it by being a deliberate man-in-the-middle: you install its root certificate on your machine, and it then issues a certificate for each site on the fly. Your client trusts the connection to the proxy, which opens a separate connection to the real site. That is why every one of these tools has a certificate step, and why they only work on devices and apps you control.
What it cannot do
- Pinned apps refuse it. An app that checks a server's certificate against a built-in copy rejects the proxy's issued certificate. See certificate pinning.
- The TLS handshake changes. The site sees the proxy's TLS fingerprint, not your client's, so a target that scores the handshake can react differently while the proxy is attached.
Intercepting versus forwarding
A forwarding proxy from a provider changes where your traffic exits. An intercepting proxy changes what you can see. The two combine: you can point an intercepting proxy at an upstream forwarding proxy, so you read the traffic locally while it leaves from the provider's IP. The debugging proxies comparison covers how each tool chains to an upstream, and the mitmproxy guide shows the setup end to end.
Common confusion
"Intercepting proxy" sounds hostile, but here it means a tool you run on purpose against your own traffic. The hostile version is a stranger decrypting traffic you did not consent to, which is only possible if you install their certificate or turn off verification.