Portmirror is a small, open-source HTTP capture agent for Windows and IIS. It watches requests arrive without inserting itself into the request path — so capture starts and stops underneath a running application, and you never recycle an application pool to see what happened.
v0.1.8 · the capture agent, self-contained · no install, run it elevated and open :9099. All releases →
the mirror plane — observed, never intercepted
The idea
For two decades the answer to "what is this server actually sending?" was Fiddler Classic — free, local, drop it on the box, read the traffic. That answer is changing, and the change has a date on it.
On 3 August 2026 Progress Telerik announced that Fiddler Classic is licensed for non-commercial use only. Personal projects, learning and education are still fine. Commercial, business, organisational or revenue-generating use is not — that requires Fiddler Everywhere, a per-user subscription starting around $9 per user per month billed annually, tied to a vendor account.
Fiddler Classic itself, in Telerik's own documentation, "is not in active development and offers no commitments for releases, patches, or technical support."
That is a legitimate way to run a business, and Fiddler Everywhere is a capable product built by people who know this problem well. But it leaves a specific hole. The thing that disappeared was not a feature set — it was a small free local tool you could put on a test machine without asking anyone. Portmirror is not trying to replace Fiddler Everywhere. It is trying to be the small thing that got taken away.
A purchase conversation before you can read an HTTP response. A vendor account signed in on a server that has no business having a user session. Per-seat maths for a tool that gets opened twice a month. And a capture tool whose future is set by a roadmap you have no say in.
One executable, MIT licensed. It runs where the traffic is, keeps what it captures in memory on that machine, and answers questions over a local HTTP endpoint. No account, no seats, no telemetry, no hosted service in the middle. When you stop it, it is gone.
Sources, checked August 2026 — Fiddler Classic commercial use · Fiddler Classic documentation · Fiddler Everywhere pricing. Licensing and prices change; check the originals before relying on any of this.
There is a second, more stubborn problem, and it has nothing to do with licensing. A proxy only captures traffic from a process that routes through it — and a worker process resolves its proxy settings once, when it starts. Point a proxy at a server whose application is already running and it sees nothing, which is why the usual advice ends in recycle the pool and try again — throwing away the state you were trying to observe.
No proxy can fix that; it is inherent to being one. So Portmirror is not a proxy. It reads the kernel HTTP stack that every request already passes through, which means capture is something you switch on and off under a live application, as many times as you like.
Scope
Most people reaching for a capture tool want to answer three questions: did the call arrive, what did it return, and what was in the payload. The long tail of features around that gets used by almost nobody. Portmirror aims to be excellent at the short list and to stay small enough to read in an afternoon.
Two parts
The project splits cleanly in two. The first part is the whole product for one server, and it is what exists today. The second is what makes it bearable across twenty.
Drop it on the server, or install it as a Windows service. It reads the kernel HTTP stack for request metadata and, when you enable it, captures request and response bodies from the wire. It keeps a bounded ring of recent exchanges in memory and serves a live-tail page plus a JSON API on a port you choose. Redaction runs before anything is stored. It holds no database and writes no log of its own.
Watching one server means knowing which server to watch. The console aggregates agents so you can open a browser, pick a machine and read its traffic without connecting to it directly. This is the one place a relay genuinely helps — and it is a service you host yourself, on your own network. There is no version of this that requires somebody else's cloud.
How it captures
There is no single way to observe HTTP on Windows that is complete, payload-bearing and free of installation cost. Rather than pretend otherwise, Portmirror picks the mechanism that matches what you need — and documents the trade-off.
| Mechanism | Bodies | Same-machine traffic | What it costs you |
|---|---|---|---|
| Kernel HTTP events shipping today |
no | yes | Nothing. No install into the application, no restart, no proxy. |
| Packet capture shipping today |
yes | no | Nothing to install — but it reads plaintext only, and captures the wire best-effort: a zero-touch spot capture, not a guaranteed-complete record. |
| Server-level module shipping today |
yes | yes | One restart when you install it — and only then. After that, capture toggles at runtime like everything else. The only place a response can be altered. |
That middle row is why the third exists. Packet capture is wonderfully zero-touch, but it is blind to same-machine calls and only best-effort on the wire. The module is the tier that captures everything — loopback included — and the only one that can alter a response.
Roadmap
Roughly in build order. The capture work is largely done; the multi-machine console and the open questions are where help is most useful — if a piece interests you, it is yours to take.
Capture inbound requests with no proxy and no recycle, and make them readable.
Show what was actually in the message — request and response bodies, two ways.
Stop needing to know which machine to log into before you can look.
Error handling is hard to test when errors will not happen on demand. This lives in the server module — the one tier that can alter a response.
Ideas that need a real use case before they earn any code. Opinions welcome in the issues.
Contribute
The architecture is small and still soft enough that a good argument can change it. If you have ever debugged a Windows server and wished for something simpler, you already have the context that matters most here.
The kernel emits different event names and fields depending on the build. There is a diagnostics endpoint that prints exactly what yours reports — paste its output into an issue and you have made the tool work for a machine it has never seen.
It masks card numbers, credential headers and obvious secret fields. It certainly misses formats nobody has thought of yet. Finding one is a test case and a one-line fix.
The feed reassembles whatever the OS hands it and recovers across capture windows, but the OS still drops packets under load — small outbound ones especially, on virtualised NICs. Measuring where that happens on real hardware, and whether a different capture mode helps, is open and self-contained.
Packet capture is the only tier that sees a server's own outbound calls with bodies, and it is best-effort — it drops packets under load, so a large, infrequent call can be missed entirely. Capturing outbound requests from inside the worker process — the way the module already captures inbound — without becoming a proxy would make server-to-server bodies reliable. It is the hardest open piece, and the most valuable.
A live tail across many machines is a real interface design problem. The current page is deliberately plain and would benefit from someone who cares about this.
Getting it running should take one command. Every rough edge you hit while trying is worth writing down, whether or not you fix it.
# Windows, .NET 8 SDK
dotnet test tests/Portmirror.Tests/Portmirror.Tests.csproj
dotnet publish src/Portmirror.Agent/Portmirror.Agent.csproj -c Release -r win-x64 \
--self-contained true -p:PublishSingleFile=true -o publish
Capture needs Windows and an elevated prompt, but the correlation, buffering and redaction logic is deliberately separated from it — so the tests run anywhere and cover the parts most likely to break.