HTTPS Interception

Probe inspects HTTPS by acting as a man-in-the-middle. It terminates the TLS handshake using a per-host leaf certificate signed by Probe's own CA, then opens a separate TLS connection upstream to the real origin. With the CA installed and trusted on your device, the leaf is accepted and the encrypted stream becomes readable in the Detail panel.

This page explains the mechanics — what's happening on the wire, how the system proxy is configured, and how to chain Probe behind a corporate upstream proxy.

How interception works

A typical HTTPS request through Probe goes through these steps:

The client sends CONNECT api.example.com:443 HTTP/1.1 to Probe (port 9099 by default).
Probe replies 200 OK and starts a TLS handshake as the server.
On the fly, Probe asks its GuideAuthority to mint a leaf certificate for api.example.com, signed by the Probe Root CA. The leaf is generated once and cached for the session.
The client validates the leaf — it chains to the Probe Root CA, which you've already trusted on this device, so the handshake succeeds.
Probe opens its own TLS connection to api.example.com:443 upstream.
Bytes flow client → Probe → origin and origin → Probe → client. Probe holds the plaintext in the middle and writes it to the log.

The leaf certificate marks itself with IsCa::ExplicitNoCa (BasicConstraints CA:FALSE plus a Subject Key Identifier). Without that extension iOS rejects the leaf even if the CA is trusted, so it's not optional — it's a requirement of Apple's stricter validation.

If the CA isn't installed yet, see Set up the CA certificate. For phones, see Mobile debugging.

System proxy

When you click Start, Probe flips your operating system's HTTP and HTTPS proxy to point at itself, 127.0.0.1 on its proxy port (9099 by default), unless you turned off Auto-enable system proxy. When you click Stop — or quit the app — Probe turns that proxy off again if it was Probe that turned it on. It doesn't bring back a different proxy you had configured before.

macOS uses networksetup to update every network service that isn't disabled (Wi-Fi, Ethernet, Thunderbolt, VPNs), connected or not. Bypass entries cover loopback, link-local, and private LAN ranges so local services don't get tunneled through Probe.
Windows writes to the WinINET registry keys, then sends WinINET INTERNET_OPTION_SETTINGS_CHANGED and INTERNET_OPTION_REFRESH so apps that read WinINET (Chromium, Edge, most desktop apps) pick up the change immediately.

A handful of apps ignore the system proxy — Firefox can be set to use its own, some Electron apps respect HTTP_PROXY only on launch, and Java apps need -Dhttp.proxyHost. For those, set the proxy explicitly to 127.0.0.1 and Probe's port (9099 by default).

Which origins Probe trusts

When Probe connects to the real server, it checks that server's certificate against the public Mozilla root list and the roots your operating system trusts (the macOS Keychain, the Windows certificate store). A company's internal CA, a private PKI or an mkcert root you've trusted on the computer therefore works through Probe the same way it works in your browser. Probe reads the OS roots once when it starts: after trusting a new root, quit and reopen Probe. Replaying a request (REST/MCP) uses the same trust and doesn't accept invalid certificates.

Upstream proxies

If your network forces traffic through a corporate proxy, Probe can chain through it. Open Tools → Upstream Proxy…, turn on Enable upstream proxy and enter the proxy's host and port; tick TLS for an HTTPS proxy, and pick Basic authentication if it needs a username and password. Probe forwards the traffic it intercepts through that proxy, after decrypting it locally, as long as you keep Proxy traffic ticked under Scope. Hosts you list in the bypass field connect directly.

Intercepted traffic doesn't follow the HTTPS_PROXY, HTTP_PROXY or NO_PROXY environment variables: the upstream proxy is the one set in Probe.

Why bodies are readable

Probe strips the Accept-Encoding header from every request it forwards upstream, except HTTPS it tunnels without decrypting (an ignored host, for one). Most origins then send uncompressed bodies, so what you see in the log is the actual JSON, HTML, or text. If an origin compresses a JSON, HTML or text body anyway, Probe decodes gzip and deflate before it shows and forwards it; a body in any other encoding, such as br, is forwarded as it arrived and shows in the log as binary data.

The trade-off: the response size in the Summary tab is measured on the uncompressed body Probe captured, so it won't match what the client would have received over the network if compression was negotiated. For most debugging this is what you want. Probe always does this, and no setting turns it off yet.

Connection headers stay on the client's hop

Like any HTTP proxy, Probe drops a request's hop-by-hop headers before it forwards it: Connection, the headers it names, Keep-Alive and Proxy-Connection (RFC 7230 §6.1). Any other hop-by-hop header, such as TE, Trailer or Upgrade, is dropped only when Connection names it. These headers describe the client's connection to Probe, not Probe's connection to the origin, so a client's Connection: close still closes the client's connection after the response while Probe manages its own connection upstream. This also holds for plain-HTTP requests to ignored hosts. HTTPS that Probe tunnels without decrypting (an ignored host, for one) reaches the origin untouched.

There are two exceptions: Host, Content-Length and Transfer-Encoding are kept even when Connection names them, and an upgrade request, such as a WebSocket handshake, keeps all its hop-by-hop headers. The Request tab still shows the hop-by-hop headers the client sent.

Proxy credentials stay with Probe

Probe never asks a client for proxy credentials, so it drops Proxy-Authorization from every request it forwards, an upgrade request included: credentials a client sends for its proxy (curl -x user:pass@… sends them) never reach the origin. It also drops Proxy-Authenticate and Proxy-Authentication-Info from every response it forwards from an origin: Probe never sends either, and passed on, they could make your client ask you for a proxy password. HTTPS that Probe tunnels without decrypting is left untouched, and the Request and Response tabs still show these headers as they arrived.

Other devices can't reach this computer's loopback services through Probe

Probe's proxy listens on every network interface, so a phone on your Wi-Fi can use it. A request that comes from another device may not use the proxy to reach services that listen only inside this computer: Probe answers 403 Forbidden when the request goes to localhost (or a *.localhost name), a loopback address (127.0.0.0/8, ::1), a link-local address (169.254.0.0/16, fe80::/10), or 0.0.0.0 / ::. The log shows the refused request, with the reason in its response. A host name is refused when every address it resolves to is one of these; a name that also has a network address, such as this computer's .local name, connects to that address only. Requests from apps on this computer are not affected. A phone can still open this computer's own network address through the proxy, such as a development server at http://<this computer's IP>:3000 or the certificate page on port 9098, and other machines on your network. To open a development server from a phone, make it listen on the network address instead of only 127.0.0.1. If a phone app calls a name that resolves only to this computer, such as an lvh.me-style development domain, add a Map Remote rule for that host: Probe then lets the request through and sends it where the rule says. This protects only the services inside this computer: other devices can still reach anything else this computer can reach through Probe, such as hosts on a VPN it is connected to.

Set up the CA certificate
Detail panel — what you see once interception is working
Mobile debugging — how to point a phone at Probe
Sessions — save the captured traffic for later