proxify: a traffic shim in front of another proxy, with a DNS server on port 53

The tool is a shim that sits in front of the proxy you already use

The positioning sentence calls it a proxy for rapid deployments with a grab bag of capabilities, and the sentence that explains it best is the one about replay. The page says a replay utility can import dumped traffic, requests and responses with the correct domain name, into another proxy simply by setting that proxy as the upstream. So the intended arrangement is the reverse of the usual one: other traffic is pointed at this tool, and this tool forwards everything onward to the tool you actually want to read. Two documented examples make that concrete:

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

forwards to a local port in the eighties, and the same idea with a SOCKS proxy forwards to a local port for the Tor network. Read that way, the feature list makes sense as a set of ways to capture what an application emits before it reaches a proper analysis proxy: interception of encrypted and non-encrypted traffic, support for clients that do not announce themselves plainly, TLS termination with client and server certificates, and an option to skip termination entirely for hosts you name with a pattern.

Three dump formats, and the flag that writes two of them at once

Dumping is the core function and the page is precise about the formats. The default is one JSON object per line, so a request and its response fit on a single line and the file can be processed as a stream. The alternative is a multi-document YAML file where each request and response pair is its own document, separated by a marker for the same streaming reason, and the example is a real capture with the host, the method, the path and the raw bytes escaped. The third writes each request and its response into separate files, with names built from the host and a random string, and two flags let you save only the request half or only the response half. One note is easy to miss because it is a single line after the format: the flag that switches on per-file output also produces the line-based file. So a session captured that way writes the same traffic twice, in two different shapes, and nothing on the page warns you that the extra copy is coming.

The embedded resolver binds the system DNS port and the page says what it is for

One feature deserves to be named plainly rather than skimmed past. You can point the tool's own resolver at a specific address, map one hostname to a chosen IP, and forward every other name to a resolver you nominate, with a wildcard available to match all queries. Binding that resolver to the system DNS port is not something an unprivileged process can do, so this needs root or a delegated capability. The page then states the purpose itself: the replay utility uses it to hijack connections and simulate responses, and it suggests the feature is useful during internal assessments where private resolvers are in play. That is a dual-use capability and the documentation is unusually clear about which half of it is being described. It is also the reason the container image installs the DNS utilities alongside a certificate bundle, since nothing else in the feature set needs them.

The rewrite language can change what a client believes the server said

Two related capabilities share one little language, and they sit on opposite sides of a line. The first tags a dump as matching when a request or response satisfies an expression, which is how you find the interesting entries after the fact rather than during it; the expressions can look at the request, the response, or a digest of them, and the matching dumps get a different file suffix. The second rewrites traffic in flight, by literal substitution or by regular expression, on the request side, the response side, or both. The examples are short: substituting one user-agent string for another, and rewriting a response body from an authentication failure to an authentication success. The second one is worth sitting with, because after it runs the response no longer reflects what the server said, and anything downstream that trusts the proxy believes your edit instead. That is a legitimate simulation technique on a lab bench and a misrepresentation anywhere else, which is why the boundary is the tool, not the intention.

The container and the build file produce different binaries from the same source

Two build paths exist and they are not equivalent. The container builds the command package and installs only two things into a minimal base: the DNS utilities, which the embedded resolver needs, and a certificate bundle. The build file, by contrast, compiles a single named source file rather than the package directory, so a second file added to that directory would be ignored. Its flag handling also has a small trap that is worth knowing about: the flags that strip symbols and the debug tables are assigned first, and then reassigned wholesale on any platform that is not a Mac, so the stripping quietly disappears exactly where it was requested and the static linking flag is what survives. Neither path pins the base image or the package versions, and the container explicitly upgrades its package set while building, so two images built a month apart are not the same image.

Two YAML libraries, a search client on an old major, and seven sibling modules

The dependency list is where the shape of the project shows. There are two YAML libraries, the fast C-backed parser and the canonical one, which is a sensible pairing and also two things to track. The search-engine client is pinned to the seventh major line of a product whose current line is higher. An expression-evaluation library, together with the organisation's own DSL library, provides the filter language, so the language you write your filters in is one this project maintains rather than one it consumed. Around those sit seven modules from the same organisation, covering command-line flags, logging, connection dialling, load balancing, a very small DNS server, shared utilities, and a proxy library pinned to a 2024 commit. Add a Kafka client and a core proxy library pinned to a 2022 commit, and the shape of what is load-bearing in this tool is legible from the manifest alone.

Every release is a zero-point-zero and the newest tag is a year behind the branch

The version numbering tells you where this sits. Every tag in the recent list is a zero-point-zero series, and the newest was cut in August 2025 while the default branch was last pushed in September 2026. The sequence also skips a number, moving from a zero-point-zero-thirteen straight to a zero-point-zero-fifteen, so at least one release in that gap was either never tagged or was retagged under a different name. Put that together with a page that describes the tool as being for rapid deployment, and with a licence file whose name carries an unusual capitalisation for its extension, and you have a young tool that is already being used seriously. That is the profile to know about before you build a repeatable capture workflow on it: pin a release, expect the interface to move, and read the page's own framing that this is for rapid deployment rather than for a long-lived installation.

Editorial conclusion

Use Proxify when an application or device will not cooperate with your analysis proxy and you need to sit in front of it, or when you want traffic captured to disk with the option to filter or rewrite it on the way through. Three things to know before you rely on it. That it terminates TLS by default, which means generating or supplying certificates, and that it will skip termination for hosts you match when you want it to. That the read boundary is the machine itself unless you restrict the file inputs, and the documentation does not walk you through doing that. And that the version line is all zeroes with a year between the newest tag and the last commit, so pin a release if you are putting this in a repeatable workflow. Treat the rewrite and DNS features as lab equipment: the page is candid that they exist to simulate responses, and anything you rewrite is something downstream will believe.

Frequently asked questions

Official sources

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