proxify: the ProjectDiscovery proxy for dumping and replaying HTTP traffic

What proxify solves, and who it is for

Burp Suite and mitmproxy are interactive tools. They are excellent when a human is sitting in front of them, and awkward when the job is to sit between a command-line client and a target for an hour and record everything that crosses the wire. proxify fills that gap. It is a proxy process you start, point a client at, and leave running while it writes each request/response pair to disk.

The README describes it as a "Swiss Army Knife Proxy for rapid deployments" supporting "request/response dump, filtering and manipulation via DSL language, upstream HTTP/Socks5 proxy". The intended audience is clear from the feature list: people running security assessments against HTTP/HTTPS and non-HTTP protocols, including traffic from thick clients that do not respect a browser proxy setting, and people who want the captured traffic to land in Burp later rather than live.

Two design choices define the tool. First, proxify is a CLI binary with flags, not a GUI, so it composes with shell pipelines and CI jobs. Second, it deliberately keeps a replay path: dumped traffic can be imported into BurpSuite or any other proxy by setting that proxy as the upstream. Capture and analysis are separate phases.

How proxify terminates TLS and where the bytes go

The mechanism is a man-in-the-middle proxy. proxify listens on an HTTP address (127.0.0.1:8888 by default) and optionally on a SOCKS address (127.0.0.1:10080). When a client sends a CONNECT request for an HTTPS host, proxify answers it, then presents a certificate it generated for that hostname and opens its own TLS connection to the real server. The JSONL example in the README shows exactly this handshake being logged: a CONNECT record for scanme.sh:443 with an empty response body, followed by a second record for the actual https://scanme.sh/ request.

That certificate generation is why the -cert-cache-size flag exists (default 256): certificates are minted per hostname and cached so repeat connections do not pay the generation cost again. The -oca / -out-ca flag writes the CA file to a filename you choose, which is the certificate a client must trust for interception to work.

Not every connection should be intercepted. The -pt / -passthrough flag takes a list of domains whose encrypted traffic is forwarded without termination, and the README gives the example proxify -pt '(.*\.)?google\.co\.in.*'. The -a / -allow and -d / -deny flags restrict proxying to IP or CIDR ranges. DNS is handled internally by an embedded server, with -da to set the listening DNS address, -dm for domain-to-IP mapping and -r for custom resolvers.

On the egress side, -hp / -http-proxy and -sp / -socks5-proxy accept upstream proxies, and -c controls how many requests are sent before switching to the next upstream in the list (default 1). The dependencies in go.mod confirm the shape of the implementation: projectdiscovery/martian for the MITM proxy layer, haxii/fastproxy, things-go/go-socks5 for the SOCKS5 listener, projectdiscovery/tinydns for the embedded DNS server, and projectdiscovery/dsl for the filter expressions.

Installing proxify and capturing your first request

The README offers two routes: download a ready-to-run binary from the releases page, or build from source with Go. The Go module targets go 1.21. The install command is:

go install -v github.com/projectdiscovery/proxify/cmd/proxify@latest

There is also a Dockerfile in the repository root that builds the binary in a golang:1.21.4-alpine stage and copies it into alpine:3.18.2, with ENTRYPOINT ["proxify"], so the image runs the proxy directly. The README does not document a docker run invocation, so read the Dockerfile before assuming port mappings.

Running proxify with no flags starts an HTTP proxy on port 8888:

proxify

To move it to another port, pass the address flag. The README's example uses port 1111:

proxify -http-addr ":1111"

Now point a client at it. The README's own JSONL sample shows curl traffic being captured, with a User-Agent of curl/8.1.2 and a CONNECT to scanme.sh:443 followed by a request to https://scanme.sh/. The proxify -h output is the reference for the rest of the flags:

proxify -h

By default proxify writes proxify_logs.jsonl, one JSON object per line, each holding a timestamp, the URL, and the request and response as header maps plus raw bytes. If you would rather have one file per transaction, -sr / -store-response writes raw request and response files into a directory that defaults to proxify_logs, and -of / -output-format switches between jsonl and yaml.

To forward everything to Burp instead of capturing locally, run Burp on port 8080 and start proxify with it as the upstream:

proxify -http-proxy http://127.0.0.1:8080

The README also gives the Tor variant:

proxify -socks5-proxy 127.0.0.1:9050

The DSL filters are where proxify gets opinionated

Dumping every byte is rarely what you want. proxify exposes four DSL flags: -req-fd / -request-dsl and -resp-fd / -response-dsl for filtering, and -req-mrd / -request-match-replace-dsl and -resp-mrd / -response-match-replace-dsl for rewriting. The README lists them but does not document the expression grammar; that lives in the projectdiscovery/dsl dependency, and the proxify repository does not repeat it.

That is a real friction point. You can see the flags in proxify -h and you can see the module in go.mod, but to write a working expression you have to leave the proxify README. For a tool whose selling point is "filtering and manipulation via DSL language", the absence of an expression reference on the main page is the weakest part of the documentation.

The match-replace pair is the more interesting half. Filtering decides what gets recorded; match-replace changes what the target receives or what the client sees. Combined with an upstream proxy, that gives you a pipeline where proxify rewrites a header or a body on the way through and Burp observes the result. The -max-size flag (default 9223372036854775807, effectively unlimited) truncates exported request and response data, which is the knob to reach for when a single large download would otherwise bloat the log.

One more constraint sits in the dependency list: the export path pulls in Shopify/sarama and elastic/go-elasticsearch/v7, and there is an -ec / -export-config flag pointing at an export-config.yaml. The README's flag table mentions the config file but does not walk through its schema, so Kafka or Elasticsearch export is visible in the code and in the flags without being explained in the main documentation.

Where proxify is the wrong tool

proxify is not a VPN and not a privacy product. It is an interception proxy: by design it decrypts TLS, which means the operator sees plaintext. The README's own framing is assessment-oriented, and the replay workflow assumes you are feeding captured traffic into Burp. Treating it as a way to hide traffic is a category error.

The second limitation is that it is headless by design. There is no interactive request editor, no repeater, no scanner. If your workflow is "pause this request, tweak a parameter, resend it", proxify is the wrong layer; use it as the capture and rewrite layer in front of the tool that has those features.

Third, TLS interception only works for clients that trust the proxify CA. Invisible and thick clients are listed as supported, but a client with certificate pinning will reject the generated certificate, and the passthrough flag is the escape hatch rather than a fix. The README does not describe a pinning bypass.

Finally, the release cadence is uneven. v0.0.16 was tagged on 2025-08-29, after v0.0.15 on 2024-03-12 and v0.0.13 on 2024-02-08. The default branch saw a push on 2026-09-14, so work continues between releases, but anyone pinning to a tagged version should expect long gaps. The README does not document a rollback procedure for an upgrade, and the -up / -update flag plus the automatic update check (-duc disables it) mean the binary can move under you.

How proxify differs from mitmproxy and Burp

mitmproxy is the closest comparison and the honest one. It is also a TLS-intercepting proxy, but its centre of gravity is a Python scripting API and an interactive console UI, with addons that can inspect and mutate flows in-process. proxify's centre of gravity is flags and a dump file. If you want to write a Python addon that reacts to a flow as it happens, mitmproxy is the better fit. If you want a single Go binary that writes JSONL and can be dropped into a shell script, proxify is the better fit.

Burp Suite differs in the other direction. Burp is a full assessment platform with a GUI, a scanner and a repeater, and proxify's README explicitly positions proxify as a feeder for it: the replay utility lets you "import the dumped traffic (request/responses with correct domain name) into BurpSuite or any other proxy by simply setting the upstream proxy to proxify". The two are complementary rather than competing. proxify captures and rewrites in the background; Burp is where a human looks at the result.

Against a plain SOCKS5 proxy, the difference is that proxify understands HTTP semantics. It can filter on request and response content, replace matched values, and record structured headers rather than opaque bytes. That is the whole reason to accept the MITM certificate step.

Licence, upgrade cost and what to check before adopting

proxify is MIT licensed, and the repository carries a LICENSE.MD at the root. MIT is permissive: it allows commercial and closed-source use, modification and redistribution, with the requirement that the licence text and copyright notice travel with the code. That is a summary of the licence identifier, not legal advice; if you are redistributing proxify inside a product, read the actual file in the repository.

The upgrade cost is low in the ordinary case. The binary is a single Go executable, the Makefile has build, test and tidy targets, and go install pins to @latest. The -up flag updates in place and the automatic update check runs unless you pass -duc, so a deployment that must stay on a fixed version needs that flag set or the binary pulled from a release tag. Because tagged releases are sparse, the practical choice is between tracking main and pinning to v0.0.16.

The configuration surface also deserves a look before you commit. There is a -config flag for a proxify configuration file, a -config-directory flag defaulting to $CONFIG/proxify, and the separate -ec / -export-config flag defaulting to $CONFIG/export-config.yaml. The README lists these without describing their contents, so anyone planning Kafka or Elasticsearch output is reading the source rather than the docs. Verify the DSL grammar against projectdiscovery/dsl before building filters you depend on.

Editorial conclusion

Adopt proxify when you need a headless, scriptable capture layer in front of Burp, a browser or a thick client, and you are comfortable with the DSL flags and the MITM certificate step. Do not adopt it as a privacy VPN or as a replacement for an interactive interception UI. Before rolling it out, verify how the -req-fd and -resp-fd DSL expressions behave against your own traffic, and confirm where the generated CA file lands when you pass -oca.

Frequently asked questions

Official sources

1. License: MIT
2. projectdiscovery/proxify on GitHub
3. Project website
4. README
5. Releases