Mock Server

The Mock Server is a standalone HTTP server built into Probe. Unlike the proxy, it isn't something your traffic passes through — it's a real server your app hits directly, at http://127.0.0.1:9100 by default. Point a client straight at it and it answers from a list of Mock rules you define, without ever touching a real backend.

This makes Mock Server the counterpart to Map Local: both serve canned responses instead of hitting a real origin, but they work at different layers.

| | Map Local | Mock Server | |---|---|---| | How traffic reaches it | Intercepted while proxied through Probe | Client connects directly to the server port | | Needs the system proxy / CA cert? | Yes | No | | Good for | Stubbing calls your app already makes through the proxy | Standing up a fake backend a client can target with no proxy setup at all |

If your client already runs through Probe's proxy, Map Local is usually simpler. Reach for Mock Server when you want a fake endpoint that works with zero proxy configuration — for example, pointing a mobile simulator, a CI job, or a teammate's laptop at a stable local URL.

Starting and stopping

Mock Server is manual start/stop — it does not launch automatically with the proxy. Open the Mock Server manager (toolbar or the right-side toolbar cluster) and:

1. Set the port (default 9100).
2. Click Start. If the port is already in use or the server is already running, Probe reports the conflict instead of silently failing.
3. Click Stop when you're done — the listener shuts down and the port is released.

There's also a master enable toggle, separate from start/stop: when it's off, every request gets the 404 fallback even while the server is running. Use it to temporarily disable all mocking without tearing down the listener.

Rule fields

Each Mock rule is checked in order; the first enabled rule that matches wins.

| Field | Type | Notes | |---|---|---| | name | string | Display name in the manager. | | enabled | bool | Per-rule toggle. | | method | string | HTTP method to match. Empty matches any method. | | url_pattern | string | A path, not a full URL (e.g. /api/users/*) — * is a wildcard. | | status_code | int | Response status. Default 200. | | status_text | string? | Optional custom reason phrase (e.g. Teapot instead of the default for 418). | | headers | list of name/value pairs | Response headers. | | body | string | Response body. | | body_is_base64 | bool | When true, body is decoded from base64 to raw bytes — use this for binary responses (images, protobuf, etc). | | latency_ms | int? | Optional artificial delay before responding. |

Wildcard path matching

url_pattern matches against the request path only — the scheme and host aren't part of it, since the client is hitting the mock server directly rather than a real origin.

• * is a wildcard that consumes any substring, so /api/users/* matches /api/users/42 and /api/users/42/orders.
• A pattern without a ? ignores the request's query string entirely — /api/users matches /api/users?active=true just as it matches the bare path.
• Include a literal ? in the pattern if you need to match (or distinguish by) query string content.

Unmatched requests

If master enable is on but no enabled rule matches — or master enable is off — the server responds with a 404 and a small JSON hint body describing why nothing matched. Nothing is ever forwarded anywhere; the Mock Server never contacts a real origin.

Create Mock from Response

The fastest way to build a Mock rule is to start from real traffic:

1. Capture the request normally (through the proxy, like any other traffic).
2. Right-click the row in the log table and choose Create Mock from Response.
3. The Mock Server manager opens with a new rule pre-filled from that response — method, path, status, headers, and body already populated.
4. Adjust anything you want (add a latency_ms, change the status, tweak the body), tick Enable, and save.

Automate it

Mock Server is the third rule-list feature (after Map Local and Map Remote) with full REST and MCP coverage, so you can manage rules and the listener from scripts, CI, or an AI assistant:

• Internal REST API — GET/PUT /api/v1/mock*, POST /api/v1/mock/start and /stop to control the listener.
• MCP Tool Reference — probe_list_mock_rules, probe_create_mock_rule, probe_start_mock_server, and more.

As with Map Local and Map Remote, rule writes made via REST or MCP are in-memory only — Probe's UI owns persistence, so a UI edit or app restart can clobber API-added rules.

Related

• Map Local — the proxied-traffic equivalent: intercept and stub a response instead of running a separate server.
• Map Remote — rewrite the destination instead of faking the response.
• Internal REST API — full endpoint reference.
• MCP Tool Reference — every Mock Server tool.