The system proxy is configured and the DevPeek CA is trusted.

Most HTTPS traffic is readable, but one site refuses to load or one app keeps reporting a network error.

Then you run a simple comparison:

System proxy on, SSL proxying on: it fails
System proxy on, SSL proxying off: it works
Only this Host excluded from SSL proxying: it works too

That points to HTTPS interception, not necessarily the proxy connection itself.

You do not have to disable all HTTPS capture. Add the incompatible Host to Skip SSL Proxy (Exclude). Its TLS bytes still pass through a DevPeek CONNECT tunnel without decryption, while other Hosts remain readable.

First confirm this is the right case

Exclude is a good fit when:

The system proxy and DevPeek CA are configured correctly.
Most HTTPS traffic decrypts normally.
Only a few sites or apps fail with SSL proxying enabled.
Turning decryption off—or excluding the affected Host—immediately restores them.

The last check matters most.

If the request still fails with SSL proxying off, the problem may be the system proxy, network, DNS, client proxy support, or origin service. Exclude alone may not help.

If you have not captured your first HTTPS request yet, start with Quick Start and Proxy & SSL certificates.

“Skip SSL Proxy” is not a full proxy bypass

Two paths are easy to confuse.

CONNECT tunnel

Browser / App
      │
      │ Original TLS bytes
      ▼
   DevPeek
      │
      │ TCP forwarding
      ▼
    Origin

Traffic still passes through DevPeek, but DevPeek does not decrypt HTTPS. TLS is negotiated directly between the client and origin. DevPeek can record connection-level information such as CONNECT, Host, and byte counts, but not HTTP headers, bodies, or plaintext responses.

This is what Exclude selects.

Full proxy bypass

The client connects directly to the origin without contacting DevPeek. That requires an operating-system bypass rule or PAC configuration; it is not the same as Exclude.

So “skip” means skip HTTPS interception—not discard the request or bypass DevPeek entirely.

Why can interception break a few requests?

SSL proxying splits one TLS session into two:

Browser / App
      │
      │ TLS: DevPeek debug certificate
      ▼
   DevPeek
      │
      │ TLS: origin certificate
      ▼
    Origin

Most browsers and apps work after trusting the DevPeek CA. Some clients and services depend on more specific TLS behavior.

1. The client pins a certificate

Certificate Pinning checks a bundled certificate, public key, or fingerprint in addition to the system trust store.

Even if the operating system trusts the DevPeek CA, a dynamically generated debug certificate does not match the value embedded in the app, so the client rejects it.

This is common in native apps, payment SDKs, login SDKs, and security components. Excluding the Host restores direct client-to-origin TLS, but its HTTPS plaintext is no longer available.

2. The service uses mutual TLS

With mTLS, the server also asks the client for a certificate.

Interception changes the original TLS session boundary, so the client-certificate exchange may not work as expected. If this traffic does not need to be decrypted, tunnel the relevant Host.

3. The client or server expects specific TLS behavior

Some implementations depend on particular TLS extensions, handshake fingerprints, connection reuse, or protocol details. A MITM changes those properties, and either side may close the connection.

There is no single error code for every case. The best test is still: interception fails, tunneling works.

4. You never needed this plaintext

Analytics, ads, update checks, and static CDNs can add noise even when they decrypt successfully.

Excluding them reduces clutter and avoids unnecessary TLS compatibility issues.

Exclude the problem Host

Open SSL proxy configuration.

The left side is SSL proxy these hosts (Include). The right side is Skip SSL Proxy (Exclude).

If Include contains:

and only secure-api.example.com fails under interception, add this to Exclude:

secure-api.example.com

To skip a set of subdomains:

*.example.com

After saving, DevPeek drops relevant old connections. Refresh the page or repeat the app action so the client establishes a new CONNECT.

Done when:

The broken site or feature works again
The request is marked as skipped by SSL proxying
HTTPS plaintext is unavailable for that Host
Other, non-excluded Hosts still decrypt normally

Include and Exclude order

The rule is:

SSL proxy
= SSL enabled
  && Include matches
  && Exclude does not match

Exclude wins when both lists match.

For Include * and Exclude secure-api.example.com:

secure-api.example.com: CONNECT tunnel
api.example.com: SSL proxy, plaintext available
static.other.com: SSL proxy, plaintext available

Putting * in Exclude tunnels every HTTPS Host. DevPeek asks for confirmation to prevent accidentally making all HTTPS plaintext disappear.

Rules match Hosts, not URL paths

These are valid:

api.example.com
*.example.com
*api*
*

These are not:

https://api.example.com/login
api.example.com/v1/*

DevPeek must choose interception or tunneling at HTTPS CONNECT time. URL paths such as /login are still inside TLS at that point, so the decision can only use connection-level data such as Host.

Do not mix up different failures

The DevPeek CA is not trusted

If most HTTPS requests fail with NET::ERR_CERT_AUTHORITY_INVALID, check CA installation and trust. Do not add every Host to Exclude one by one.

The origin certificate is invalid, but the site and plaintext still work

If request details report an origin hostname mismatch, expired certificate, or untrusted certificate while the page and plaintext remain available, that is certificate-debugging information DevPeek deliberately preserves. It is not the interception failure covered here.

See Origin Certificate Mismatch: Why DevPeek Still Captures the Site.

The request still fails with SSL proxying off

The failure is not limited to HTTPS interception. Check the system proxy, DNS, network reachability, client HTTP-proxy support, and the origin service.

HTTPS is open, but the JSON is still encrypted

That is application-layer encryption. Use Param Transform instead of Exclude.

Why not automatically tunnel after a failure?

DevPeek must choose interception or CONNECT tunneling before establishing the connection.

Once the client has started TLS with DevPeek, its original ClientHello cannot simply be rewound and handed to the origin. A connection failure also does not prove that the user wants to give up plaintext—it may be a temporary network or origin failure that is itself under investigation.

DevPeek therefore does not silently downgrade every failed request. The user explicitly selects Hosts to tunnel through Exclude.

One rule to remember

If a Host behaves like this:

SSL proxy enabled → fails
SSL proxy skipped → works

add it to Exclude. Tunnel that traffic instead of disabling HTTPS decryption for everything.

Origin Certificate Mismatch: Why DevPeek Still Captures the Site—an invalid certificate does not have to erase the debugging evidence; DevPeek keeps plaintext available while clearly reporting that peer identity could not be verified.

If a few sites or apps fail only under SSL proxying, try DevPeek and add the affected Hosts to Exclude. You can also share unusual proxy compatibility cases on GitHub Discussions.

HTTPS Capture Breaks a Few Sites? Add Them to Skip SSL Proxy