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 an iOS simulator, a local test run, or a dev server on the same machine at a stable local URL.

The Mock Server listens on 127.0.0.1 only, so it's reachable from the Mac or PC running Probe and nowhere else: a phone, another computer or a teammate's laptop can't connect to it. For traffic from those devices, proxy them through Probe and use Map Local.

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.

In the rule editor the status code must be 100–999 and the latency 0 ms or more; the editor says which field is wrong instead of saving.

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 and start/stop made via REST or MCP are handed to the app while it's open: the app saves the rules and the Mock Server window shows them, just like rules you add yourself. (port must be 1–65535; 0 is rejected.)

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.