Proxy

VirtuProbe includes a built-in MITM proxy that sits between your client and the target server. A DevTools-style UI lets you inspect every request and response in real time — including raw bodies, decompressed payloads, and binary frames. It runs in one of two modes: a SOCKS5 tunnel that relays raw TCP, or an HTTP intercept mode that understands whole HTTP requests and can rewrite or mock them.

Note

The proxy requires the Engineering tier or above, as do the interception rules below (mock, rewrite, fault, and script actions).

Starting the proxy

Choose a mode — SOCKS5 Tunnel or HTTP Intercept — set the Port the proxy should listen on in the toolbar, then click Start. Point your client’s proxy settings at localhost on that port (SOCKS5 for tunnel mode, HTTP for intercept mode).

Setting	Default
Host	localhost
Port	1080

Inspecting exchanges

Each TCP exchange appears in the list as it flows through the proxy. Click an entry to inspect it.

The detail panel shows:

• Request — raw bytes sent by the client
• Response — raw bytes returned by the server
• Direction and timestamp for each chunk

Body decompression

Compressed response bodies (gzip, deflate, Brotli) can be decompressed server-side. Click Decompress on an exchange to see the readable payload. All three encodings are supported, including Brotli which browsers cannot decompress natively via the standard API.

SSL/TLS traffic

The proxy can handle SSL connections. For HTTPS interception, configure your client to trust the proxy’s certificate.

Caution

MITM interception of TLS traffic requires the target client to trust the proxy’s CA certificate. Use this only against systems you own or have explicit authorization to test.

HTTP interception mode

Started in HTTP Intercept mode, the proxy does more than relay bytes — it terminates and parses each HTTP/1.1 request (HTTPS via CONNECT and an on-the-fly leaf certificate signed by the proxy CA). Because it now understands whole requests and responses, it can act on them with interception rules.

With no rules defined, HTTP intercept mode forwards every request transparently to the real target and still feeds the capture view — so you can switch it on without changing what your client sees.

Interception rules (mocking & service virtualization)

Interception rules turn the proxy into a service virtualization layer: match live requests and mock, rewrite, delay, or script their responses. Manage them from the Interception Rules editor in the proxy view.

Note

Interception rules apply only in HTTP Intercept mode and require the Engineering tier or above.

Rules are organised into rule sets. Within a set, rules are evaluated top to bottom and the first match wins — order matters. Each rule has a match and an action.

Matching

Every match field is optional; a blank field matches anything. A rule fires when all of its filled-in conditions match:

Field	Matches on
Method	HTTP method (GET, POST, …)
Host pattern	Request host
Path pattern	Request path — supports {segment} placeholders and * wildcards
Header name / Header value contains	A request header and (optionally) a substring of its value
Body contains	A substring of the request body

Actions

Action	What it does
Mock	Return a synthetic response you define — status, reason, Content-Type, headers, and body — without the request ever reaching the real server. Stand in for a service that isn’t built yet.
Forward	Pass the request through to the real target unchanged (the default behaviour when no rule matches).
Rewrite	Forward to the target, but apply find/replace operations to the live request and/or response — headers or body, with optional regular expressions.
Fault	Forward to the target, then inject a fault into the genuine response — an error status or added latency — to exercise how your client handles failure.
Script	Run a Groovy script with the request bound (method, path, body, headers, host) and a mutable response (status, reason, headers, body). Mutate the response or return a map — for dynamic mocks that react to the request.

A Latency (ms) delay can be added to any action, applied before the response is written — useful for simulating a slow dependency.

Rule sets are saved alongside the rest of your workspace, so your mocks and virtual services persist between sessions.

Tip

A common pattern: put specific Mock rules at the top of a set and leave everything else to fall through to the real service. Because the first match wins, you virtualize just the endpoints you need and pass the rest straight through.