Breakpoints & resend

Breakpoints let you pause a decrypted request or response mid-flight, edit it, and let it continue — and resend lets you replay a captured request. Both are driven from your dashboard; there's nothing to configure on the proxy beyond the match patterns.

Breakpoints

When you set breakpoint patterns, the proxy watches decrypted traffic for matches. On a match it pauses the exchange, shows you the raw HTTP in the dashboard, and waits for your decision before forwarding anything.

Setting patterns

Two pattern lists control where the proxy pauses, both edited in the dashboard:

• breakpointRequestPatterns — pause outgoing requests that match, before they reach the server.
• breakpointResponsePatterns — pause incoming responses that match, before they reach the client.

Patterns are URL wildcards — host, host/path*, *.host, /path* — matched against the request URL.

Note: Breakpoints only fire on hosts that are actually being decrypted. A host that's passing through as a raw tunnel can't be paused, because the proxy never sees its contents. Add the host to your SSL-proxy list first.

What happens on a pause

The proxy holds the exchange and surfaces the paused raw HTTP to every connected dashboard over Realtime. You then choose one of:

• Continue — forward the exchange unchanged.
• Edit, then continue — change the raw HTTP and forward your edited version. The proxy recomputes Content-Length for you; when you edit a response body, its Content-Encoding is dropped since you're editing the already-decoded body.
• Abort — drop the exchange. An aborted request returns 499; an aborted response tears down the connection.

If you don't respond within 60 seconds, the pause times out and the proxy forwards the original, unchanged — so a forgotten breakpoint never wedges traffic.

Drive all of this from the dashboard's Breakpoints view.

Resend

Resend re-issues a request the proxy already captured, without touching the original client. You trigger it from the dashboard on any captured entry.

The proxy fires the request again from the server side and captures the new response as a fresh entry, tagged as resent and attributed to the same device. The replayed request carries an internal resent marker that's recorded on the captured entry but stripped before the request leaves for the upstream — so the upstream sees a clean request.

This is handy for re-running a request after editing it, or re-checking an endpoint without involving the original device at all. The new exchange shows up in your feed like any other capture.

How it's wired

Both flows ride a single Realtime control channel between the dashboard and the proxy — the dashboard publishes your continue/abort decision or resend request, the proxy acts on it. There's no extra setup on the proxy beyond the pattern lists. The same channel also carries an operator restart signal.

Next

• External proxy — chain egress through an upstream proxy.