SSL Proxying

Choose which hosts WireLens decrypts. Everything else is tunnelled untouched, so pinned apps and system services keep working.

Mac iPhone and iPad

HTTPS is encrypted between the app and the server, so a proxy only sees it if the proxy is allowed to decrypt it. SSL Proxying is where you say which hosts that applies to. Hosts you have not listed still show up in Capture, as tunnels, with their host, port, timing and byte counts, but no headers or bodies.

How decryption works#

When an app connects to a host on your Include list, WireLens answers the TLS handshake itself with a certificate for that host, signed by your WireLens root certificate. It then opens its own TLS connection to the real server and relays the exchange, recording both sides as it goes.

That only works if the device trusts your WireLens root. If you have not trusted it yet, start with The WireLens root certificate.

The Include list#

Open Tools ▸ SSL Proxying on the Mac, or Tools ▸ SSL Proxying on iPhone, and add a pattern:

PatternDecrypts
api.example.comThat host only
*.example.comEvery subdomain of example.com
*Every host except the Exclude list (Decrypt All, Pro)

The quickest way to add a host is from the traffic itself. Right-click a flow or a domain in the sidebar and choose Enable SSL Proxying for This Host on the Mac, or long-press it on iPhone. The next connection to that host is decrypted; there is nothing to restart. On iPhone, WireLens closes the existing tunnel for that host so the app's next request opens a fresh, decrypted connection.

The Exclude list#

A host on the Exclude list is never decrypted. Use it for anything that should pass through untouched, such as a service that pins its certificate or a host whose traffic you do not want recorded in detail.

WireLens keeps its own list of system hosts out of decryption: Apple services and well-known apps that pin their certificates. Those entries are maintained for you and do not count toward the free plan's Exclude limit.

Certificate pinning#

Some apps only trust their own certificate. When WireLens decrypts one of their hosts, the app refuses the connection and stops loading. That is the app protecting itself, and every debugging proxy meets it.

  • WireLens measures pinning instead of guessing at it. A host that refuses the WireLens certificate twice is put on passthrough for the rest of the session, so the app keeps working and the host is still captured as a tunnel.
  • To make that permanent, leave those hosts off the Include list, or add them to Exclude.
  • Decrypt the apps you build. Debug builds usually do not pin, or can be configured not to.
  • If a host starts failing right after you decrypt it, pinning is the likely reason.

Origins with self-signed certificates#

A development server with a self-signed or expired certificate fails WireLens's own check of the origin. Add that host to the invalid-origin exceptions and WireLens accepts its certificate when it connects upstream. A bare * is refused, because accepting any certificate from any origin would hide real problems. These exceptions share the free plan's SSL Proxying allowance.

Free and Pro#

FreePro
Include patterns2Unlimited
Exclude patterns2Unlimited
Decrypt All (*)NoYes

From the command line#

bash
wirelens rules ssl add api.example.com
wirelens rules ssl rm api.example.com
wirelens rules bypass add pinned.example.com
wirelens rules insecure add dev.local.test

The MCP server exposes the same lists as set_ssl_include, toggle_ssl_host and set_invalid_origin_exceptions. See Command line and MCP for AI agents.

Something here is unclear, or wrong for your setup? Contact support or write to support@wirelens.app.