How to Debug HTTPS Traffic on macOS: A Complete Guide

Every modern API uses HTTPS. That's good for security. It's bad for debugging. TLS encryption means you can't just point Wireshark at your network interface and read request bodies. The traffic is encrypted end-to-end, and your debugging tools are on the outside looking in.

To inspect HTTPS traffic, you need a man-in-the-middle proxy with a trusted root certificate authority. This guide explains exactly how that works, how to set it up on macOS, and what to watch out for.

Why HTTPS debugging is harder than HTTP

With plain HTTP, traffic flows as readable text. Any proxy or packet sniffer can read headers and bodies directly. HTTPS wraps that same HTTP traffic in a TLS tunnel. The proxy can see that a connection exists and where it goes (via the SNI extension in the TLS handshake), but the actual request and response content is encrypted.

To decrypt and inspect that traffic, you need to terminate the TLS connection at your proxy. This means the proxy needs to present a certificate that your applications trust. Otherwise, every HTTPS request will fail with a certificate error.

How TLS interception works

Here's the full chain of what happens when a debugging proxy intercepts an HTTPS connection:

1. Root CA generation. The proxy generates a root Certificate Authority -- a self-signed certificate with CA permissions. Modern proxies (including Rockxy) use P-256 ECDSA keys rather than RSA. ECDSA is faster for TLS handshakes and produces smaller certificates.
2. Trust installation. You install this root CA into the macOS system keychain and mark it as trusted. This is a one-time step. After this, any certificate signed by this CA will be accepted by applications that use the system trust store.
3. Connection interception. When an app makes an HTTPS request, the system proxy routes it through the debugging proxy. The proxy sees a CONNECT request to the target host (e.g., CONNECT api.example.com:443).
4. Per-host certificate generation. The proxy generates a new TLS certificate on the fly, with the Subject Alternative Name (SAN) set to the target hostname, signed by the root CA. This certificate is cached -- Rockxy caches up to 1,000 host certificates in an LRU cache, so subsequent connections to the same host are fast.
5. Double TLS tunnel. The proxy establishes two TLS connections: one to the client (using the generated per-host certificate) and one to the real server (using the server's actual certificate). Traffic flows through in cleartext inside the proxy, where it can be inspected, modified, or breakpointed.
6. Re-encryption and forwarding. After inspection, the proxy encrypts the traffic again and forwards it to its destination. The client app sees valid certificates and has no indication that the traffic was intercepted.

Setting up HTTPS debugging with Rockxy

The setup takes about 60 seconds:

Step 1: Install Rockxy. Download the .dmg from the website and drag Rockxy to your Applications folder. Open it.

Step 2: Trust the root certificate. Go to Settings (Cmd+,) and open the Certificate tab. Click "Install and Trust." macOS will prompt for your administrator password -- this is the system asking for permission to add a trusted root certificate to your keychain. This happens once.

Step 3: Enable the proxy. Click the toggle in the toolbar or press Cmd+Shift+R. Rockxy registers itself as the system HTTP and HTTPS proxy. All traffic from applications that respect the system proxy setting will now flow through Rockxy.

Step 4: Open any app. Make an API call, load a website, or launch the app you're debugging. HTTPS requests appear in Rockxy's request list in real time, fully decrypted.

Handling certificate pinning

Some applications implement certificate pinning -- they hardcode the expected server certificate (or its public key hash) and reject any other certificate, including one signed by your proxy's root CA.

This is common in banking apps, some SDKs, and security-sensitive services. When a pinned connection hits the proxy, the TLS handshake will fail on the client side.

Rockxy handles this automatically. Pinned connections that fail TLS negotiation fall back to raw passthrough -- the encrypted traffic is forwarded without interception, so the app continues to work. You'll see the connection in the request list marked as "TLS Passthrough" rather than showing decrypted content.

You can also configure per-domain SSL proxying. If you know a domain uses pinning and you don't need to inspect it, add it to the bypass list. This avoids the failed-handshake-then-fallback cycle entirely.

What you can inspect

Once HTTPS traffic is decrypted, you have full visibility into every layer of the HTTP transaction:

• Headers -- request and response headers, including cookies, authorization tokens, content types, and cache directives
• Bodies -- JSON rendered as a collapsible tree view with syntax highlighting. XML, HTML, and plain text with formatting. Binary content in hex view. Images rendered inline.
• Cookies -- parsed and displayed with name, value, domain, path, expiration, and flags (Secure, HttpOnly, SameSite)
• Timing waterfall -- broken down into DNS resolution, TCP connect, TLS handshake, time to first byte (TTFB), and content transfer. Each phase is color-coded in a waterfall bar.
• TLS details -- protocol version, cipher suite, certificate chain, and certificate validity dates
• WebSocket frames -- if the connection upgrades to WebSocket, individual frames are captured with direction, opcode, payload, and timestamps
• GraphQL -- for GraphQL-over-HTTP requests, Rockxy detects the operation name, type (query/mutation/subscription), and parses the query body

Security considerations

Running a MITM proxy on your machine has security implications you should understand:

Your root CA key must stay secure. Rockxy stores the root CA's private key in the macOS Keychain, not as a file on disk. The Keychain encrypts it at rest and requires authentication to access. If someone obtained your root CA key, they could generate certificates that your machine would trust -- which is the same risk as any trusted root CA.

Only run the proxy when you need it. When the proxy is active, all HTTP/HTTPS traffic flows through it. Disable it when you're done debugging (Cmd+Shift+R to toggle).

The privileged helper is locked down. Rockxy's system proxy helper runs via XPC with code-signing validation. Only the Rockxy binary, signed with the correct certificate chain, can communicate with it. The helper validates every connection by extracting and comparing the caller's full certificate chain.

Nothing leaves your machine. Rockxy has no telemetry, no analytics, no cloud sync. Traffic is stored locally in SQLite and on-disk body files. Session files are local. The source code is open for verification.

Beyond browser DevTools

If you only debug web apps, browser DevTools are often enough. But macOS development involves much more than browsers:

• Native apps -- iOS simulators, macOS apps, Electron apps, and anything using URLSession or CFNetwork
• CLI tools -- curl, wget, httpie, and custom scripts
• Background services -- daemons, launch agents, and processes making API calls without a visible window
• SDKs -- analytics SDKs, crash reporters, feature flag services, and authentication libraries making requests you didn't write

A system proxy captures all of this. If it uses HTTP or HTTPS and respects the macOS system proxy settings, Rockxy sees it. That's the difference between debugging one app and understanding your entire machine's network behavior.