Debugging Proxied Traffic

When MockServer runs as a proxy it records every request it forwards and the response it received. That recording is the single best way to understand how a system actually behaves — which calls a client really makes, in what order, with which headers and bodies, and how the upstream responds. This page covers the two ways to inspect that traffic: interactively in the dashboard UI, or by downloading/exporting it in a range of formats.

This is complementary to Record & Replay: there you turn recorded traffic into reusable mock expectations; here you inspect it to debug and understand a system.

Inspecting in the Dashboard UI

The MockServer dashboard (served at http://localhost:1080/mockserver/dashboard) updates in real time as traffic flows through the proxy, so you can watch a system as it runs:

Received & proxied requests — every forwarded request and its response appear live. Expand any entry to see the full request line, headers, and body alongside the response status, headers, and body.
Log messages — the structured log shows each forwarding decision (which request was proxied where, and the response returned), so you can follow the exact sequence of calls a system makes.
Sessions — related requests are grouped so you can trace a multi-step interaction (and, for AI traffic, view the correlated call graph) rather than reading a flat list.
Export — the Library → Export tab downloads the recorded traffic without leaving the browser: choose the Recorded requests scope and pick a format (JSON, log entries, HAR, or cURL) from the dropdown.

The dashboard is read-only over the same port as the proxy — no extra configuration or container is required.

Downloading & Exporting Recorded Traffic

The same traffic can be pulled out of MockServer programmatically with the retrieve API (PUT /mockserver/retrieve), which is ideal for scripting, sharing with teammates, or feeding into other tools. Two type values cover proxied traffic — REQUESTS (the requests only) and REQUEST_RESPONSES (each request paired with its response) — and the format parameter selects the representation:

Format	Applies to	Use it to…
JSON (default)	REQUESTS, REQUEST_RESPONSES	Inspect the raw recorded requests/response pairs, or process them in a script.
LOG_ENTRIES	REQUESTS, REQUEST_RESPONSES	Read the traffic in MockServer's human-readable log format.
HAR	REQUEST_RESPONSES	Open the recording in browser DevTools or any HTTP-analysis tool that reads HAR 1.2 — a great way to share a capture.
CURL	REQUESTS, REQUEST_RESPONSES	Get one `curl` command per recorded request so you can replay an individual call by hand.
JAVA	REQUESTS, REQUEST_RESPONSES	Render the requests as Java client code (handy for pasting into a test).

Retrieve request/response pairs as JSON:

curl -v -X PUT "http://localhost:1080/mockserver/retrieve?type=REQUEST_RESPONSES&format=JSON"

Export a HAR file to open in DevTools or share:

curl -v -X PUT "http://localhost:1080/mockserver/retrieve?type=REQUEST_RESPONSES&format=HAR" -o recording.har

Get one curl command per recorded request to replay a call:

curl -v -X PUT "http://localhost:1080/mockserver/retrieve?type=REQUESTS&format=CURL"

Any retrieval can be narrowed to the traffic you care about by sending a request matcher in the body — for example, only the calls to a particular path or host:

curl -v -X PUT "http://localhost:1080/mockserver/retrieve?type=REQUEST_RESPONSES&format=HAR" -d '{
    "path": "/api/.*"
}'

Using This to Debug & Understand a System

Recorded proxy traffic answers the questions that are hardest to reason about from source code alone:

What does my client actually send? See the real method, path, query parameters, headers, and body — including values added by frameworks, SDKs, or interceptors you did not write.
What does the upstream really return? Capture the exact status codes, headers, and bodies a dependency produces, including error and edge-case responses that are hard to reproduce on demand.
In what order do calls happen? Follow the sequence of requests to spot redundant calls, missing retries, or unexpected fan-out.
Why is a request not matching? Compare a recorded request against your expectations to see exactly which field differs (see also AI-assisted debugging).
Share a reproduction. A HAR file or the JSON recording is a precise, self-contained capture you can attach to a bug report or hand to a teammate.
Turn it into a test. Once you understand the traffic, replay it as deterministic mocks — see Record & Replay.
Where is the time going? Use the per-request timing breakdown (connect, TTFB, total) and HAR timing export to identify whether latency is in the network, the upstream's processing, or the response transfer — see Network Latency Debugging.

For the complete list of type and format values and the full REST specification, see the configuration docs and the retrieve REST API.