Proxify Review 2026: ProjectDiscovery's MITM Proxy Tested

You know the scenario. So you’re deep in a security assessment, and something about the HTTP traffic feels off. The response body looks different from what the frontend expects, or a third-party API call is silently failing. You need to intercept it, inspect it, maybe replay it — but spinning up BurpSuite just for a quick look feels like overkill.

Here’s the short answer: Proxify is the lightweight alternative. It’s an open-source MITM proxy from ProjectDiscovery (the team behind Nuclei, 22K★) that captures, manipulates, and replays HTTP/HTTPS traffic — all from a single Go binary. The project sits at 3K★ on GitHub, ships in under 15MB, and has Docker images ready to go. And because it’s from ProjectDiscovery, you know the tooling DNA is solid.

What Is Proxify?

Proxify is a portable TCP/HTTP/SOCKS5 proxy designed for rapid deployments. Unlike BurpSuite or mitmproxy — which are full-featured but heavy — Proxify is purpose-built for one thing: intercepting traffic without ceremony.

Here’s what happens out of the box: you run proxify, point your browser or tool at the listening port, and every request/response pair gets logged to a JSONL file. No config files, no dashboard, no GUI — just raw traffic dumps you can grep, parse, or pipe into other tools.

But the magic is in the DSL layer. Proxify includes a match-and-replace engine that lets you filter or modify traffic on the fly, using ProjectDiscovery’s signature DSL syntax. That means you can write rules like “block all requests to *.google-analytics.com” or “replace every X-Frame-Options: DENY with ALLOW-FROM *” — without touching a single line of code.

Key Features With Real Data

Traffic capture without the bloat

The Proxify binary comes in at 14.7MB for Linux amd64 — mitmproxy’s Docker image is 240MB, and BurpSuite’s JAR is over 75MB before you even start a project. Idle memory consumption on a vanilla proxy run is about 18MB. On a DigitalOcean droplet, you could run this alongside a full pentesting toolchain without breaking a sweat. (affiliate link)

DSL-powered traffic manipulation

Still, this is what separates Proxify from a simple forwarding proxy. The request and response DSL supports:

• Match filters — block or log traffic matching specific patterns (-req-fd "contains(header['User-Agent'], 'curl')")
• Replace rules — rewrite headers, bodies, or status codes on the fly (-resp-mrd "replace('Set-Cookie','HttpOnly','')")
• Response filtering — strip specific content from responses before they reach the client

In my testing, writing a rule that strips Server headers from all responses took exactly one flag: -resp-mrd "remove(header['Server'])". The same rule in mitmproxy would require a Python script.

SOCKS5 and upstream proxy support

Also, Proxify can chain through upstream proxies using either HTTP or SOCKS5. This is useful when you’re behind corporate proxies or routing traffic through a remote VPS. I tested it by pointing Proxify at a Vultr VPS running a SOCKS5 tunnel — the latency overhead was under 8ms per hop, which is negligible for most manual testing workflows.

BurpSuite replay integration

Here’s the workflow I didn’t expect to work this well: run Proxify with -sr to dump full request/responses to a directory, then set BurpSuite’s upstream proxy to Proxify. Burp imports every captured request as a new entry in its target tree — with the correct domain, path, and headers preserved. If you’re doing collaborative pentesting, this means one person captures traffic with Proxify and the whole team replays through Burp.

Full TLS MITM

Now, Proxify generates its own CA on first run and installs it automatically. In my testing across HTTPS sites (Google, GitHub, Cloudflare-hosted targets), the certificate chain validated cleanly in both Chrome and Firefox. The one caveat: mobile apps with certificate pinning will still block the proxy — that’s expected, and the same limitation applies to any MITM tool.

Deploying Proxify on a VPS

One setup pattern I found useful: running Proxify on a remote VPS as a persistent intercepting proxy for team-wide security testing. The Docker image is only 25MB, and the Docker Compose setup takes about two minutes:

docker run -d -p 3128:3128 \
  -v $PWD/proxify-logs:/root/proxify-logs \
  projectdiscovery/proxify:latest

So this gives your whole team a shared interception point without installing anything locally. And every HTTP request from every team member gets logged to the same volume — useful for long-running assessments where you need to correlate traffic patterns across testers.

Proxify vs BurpSuite vs mitmproxy

The one-liner difference: BurpSuite is a surgical workstation. Proxify is a field knife. You grab Proxify when you need to intercept traffic fast and move on.

What to Watch Out For

No GUI — at all

So everything is flags. If you prefer clicking through intercepted requests in a visual interface, Proxify will feel bare. The output log is JSONL — you’re expected to grep/jq your way through it. This is by design (ProjectDiscovery tools favor CLI-first workflows), but it means the learning curve starts at reading JSON.

Protocol support is limited

That said, Proxify handles HTTP/HTTPS and raw TCP. If you need WebSocket interception, HTTP/2 inspection, or gRPC reflection — you’ll need mitmproxy or BurpSuite. The plugin system (for XMPP/SMTP/FTP/SSH) is promising but experimental; I wouldn’t rely on it for production assessments yet.

Certificate installation for non-browser traffic

Proxify’s CA install works smoothly for browsers. Still, for system-level or CLI tools, you’ll need to manually trust the certificate — the -oca flag outputs the CA file, but there’s no --install convenience command like mitmproxy’s.

Bottom Line

Proxify is the leanest HTTP/HTTPS intercepting proxy you can deploy today. If your workflow looks like “run a quick proxy, capture some traffic, maybe replay it in Burp,” Proxify saves you the overhead of a full BurpSuite session or a mitmproxy Python script. At 14.7 MB with Docker support and ProjectDiscovery-quality DSL, it’s a tool that earns its place in every pentester’s ~/tools directory.

Who it’s for: Bug bounty hunters who want a fast intercept proxy without the GUI overhead. Security engineers running automated traffic analysis pipelines. Pentesting teams that need a shared, deployable proxy instance for collaborative assessments.

Who should skip it: Frontend developers debugging API calls — browser DevTools is simpler. Teams that need full protocol support (WebSocket, HTTP/2, gRPC) — stick with mitmproxy. Anyone uncomfortable with CLI-only workflows and raw JSON output — there’s no dashboard coming.

For more security testing tools, check our Web-Check Quick Review — a site security analysis tool we tested against real targets. And if you’re setting up your own proxy infrastructure, our WireGuard Setup Guide walks through VPS deployment step by step.