Capture & Inspect Traffic

While capture is running, every request that goes through the proxy is recorded: the request and the response, their headers and bodies, the status, the timing, and the upstream TLS certificate.

Captured requests are grouped by host, by the application they came from, and by device, so traffic from one app or one phone can be looked at on its own. Hosts you care about can be pinned; hosts you do not want decrypted can be sent to the bypass list straight from a captured request.

Clearing the session discards everything recorded so far. Stopping capture does not clear it.

Narrowing it down

Two mechanisms work together:

  • a text search over the captured requests;
  • a filter built from rules, combined with AND (all must match) or OR (any one must match).

A filter rule matches on the URL, the path, the method, the scheme, or the status. For URL and path it can test equality, containment, a prefix, a suffix, or a regular expression; for the status it takes a class (2xx, 3xx, 4xx, 5xx), an exact code, a range, or a state for requests that have no code at all — still running, failed, or bypassed. A filter holds a limited number of rules, and individual rules can be switched off without being deleted.

What you see for one request

  • Headers of the request and of the response.
  • Body, rendered according to its content type: JSON as a collapsible tree, HTML rendered, images with their dimensions, multipart/form-data as fields with previews for file parts, anything binary as a hex dump. Text bodies can be searched.
  • Authentication detected in the request — the scheme, the header it came from, and the decoded token.
  • Raw HTTP message, as it went over the wire.
  • Summary — host, path, scheme, HTTP version, source application, status, duration, body sizes, timestamps, and the server's TLS certificate (subject, issuer, validity, serial, fingerprint, SANs).

Bodies too large to display are not loaded into the viewer; they can be saved to a file instead.

Streams

A response with Content-Type: text/event-stream is passed through to the client in real time and its events are recorded as they arrive. WebSocket connections are recorded frame by frame, with direction, opcode, size, and payload; binary payloads are shown as hex, text payloads are pretty-printed when they parse as JSON.

Both are capped: 1000 entries per request, and a single WebSocket payload is captured up to 64 KiB.

If an event is in the stream but never reaches the page, paste the raw response into the SSE parser: it shows what a browser reads from it and what it drops in silence.

Streams that behave oddly have their own guides: SSE arrives in one chunk, a stream that dies after 60 seconds, replacement characters in a stream, the six-connection limit, and WebSocket closed with code 1006.

Timing

Timing is measured per phase, so a slow request can be attributed: reading the request body, matching Map Local rules, a rule's own delay, time spent paused on a breakpoint, establishing the upstream connection, waiting for the server, reading the response body, and time paused before the response reached the client. Whether the upstream connection was new or reused is recorded too.

Failures

A request that never got a response is recorded with the reason: DNS resolution failed, the server rejected the proxy's TLS connection, the TLS handshake with the client failed, connection refused, reset, or timed out, the client closed the connection first, a WebSocket upgrade never completed. The underlying error is kept alongside the explanation.

A body shown as encrypted content means the certificate is not installed or not trusted on the client — see Certificate Installation.

Getting data out

A single request can be copied or saved: its headers, its body, or the raw HTTP message.

How to record a HAR file

A browser saves a HAR for one tab. Solpuga records one for everything that goes through the proxy: a mobile app, a desktop program, a script, or several browsers at once.

  1. Start capture and reproduce the problem. HTTPS bodies are readable once the certificate is installed. A phone is connected as described in Mobile Devices.
  2. Choose Tools → Export Session as HAR… (Cmd/Ctrl + Shift + E), or click the download button in the title bar, next to Clear.
  3. Save the file.

The file holds the whole session as HAR 1.2. It opens in Chrome DevTools, Charles, Fiddler, Insomnia, and Postman, and with nothing to install in the HAR viewer, right in your browser. Export is unavailable while nothing has been captured.

Need a HAR of a single browser tab instead? DevTools saves that one: how to save a HAR file in Chrome, Firefox and Safari.

What to expect in the file:

  • requests that have not finished are skipped; failed requests are exported with status 0;
  • bodies are stored decoded and decompressed, while response headers are exported as captured, so some importers try to decompress them a second time;
  • binary response bodies are base64-encoded, binary request bodies are omitted and carry a comment instead.

How to open a HAR file

A .har file from a browser or another proxy opens through Tools → Import Session from HAR… (Cmd/Ctrl + Shift + I), or by opening it with the app from your file manager.

It opens in a separate read-only window with its own list and inspector, so the live capture is untouched. Bodies and raw messages can be saved out of it. Files larger than 500 MB are rejected.