g3proxy: ByteDance's Rust proxy toolkit, now in maintenance mode

The project tells you to use a different one

The first paragraph of the README settles most adoption questions. G3 is the project ByteDance used to build enterprise-oriented generic proxy solutions, including a proxy, a reverse proxy that is work in progress, a load balancer that is to be determined and NAT traversal that is also work in progress. Then it says the project is now in maintenance mode and that active development has moved to the VEY project, with a link to it. That is an unusual thing to find in a repository that is not archived and whose latest g3proxy release, v1.12.4, is from July 2026. The practical reading is that the code is still there, still builds, and still has released binaries, but that new features, new protocols and new platform work are happening somewhere else. Anyone starting a proxy project today should read that sentence first, and anyone who inherited a G3 deployment should read it second.

g3proxy does far more than forward traffic

The g3proxy application is described as a generic forward proxy, with basic support built in for using it as a tcp streaming proxy, a transparent proxy or a reverse proxy. The feature list underneath is where the design shows. On the protocol side it speaks Http1 and Socks5 forward proxy protocols, supports SNI proxy and TCP TPROXY, and handles easy-proxy and masque/http Well-Known URI. It does proxy chaining with dynamic selection of upstream proxies, and it offers a range of egress route selection methods with support for a custom egress selection agent, which is the mechanism for picking which outbound path a given request takes. On the TLS side it can run over OpenSSL, BoringSSL, AWS-LC, AWS-LC-FIPS, Tongsuo or rustls. It also does graceful reload, customisable load balancing and failover strategies, user authentication with a rich set of config options, differential site config per user, ACL and limit rules at ingress, egress and user level, and monitoring metrics at ingress, egress, user and user-site level.

Interception and ICAP are the enterprise reasons to use it

Two capabilities separate g3proxy from an ordinary forward proxy. The first is TLS MITM interception, with a decrypted traffic dump and interception of HTTP1, HTTP2, IMAP and SMTP. The second is ICAP adaptation for those same protocols, which the README says lets it integrate with third-party security products, so a corporate scanner can sit in the path without changing how the proxy works. This is a security operations tool, and it is worth being explicit about that, because the same capability that lets a security team inspect encrypted traffic is the capability a misconfigured deployment leaks through. That is why the project ships supporting tools. g3mkcert makes root, intermediate, TLS server, TLS client, TLCP server and TLCP client certificates, so the trust chain for interception is generated with a proper tool rather than by hand. g3fcgen is a fake certificate generator for g3proxy. g3iploc is an IP location lookup service backing the GeoIP support, and g3keymess is a simple implementation of a Cloudflare keyless server, which pairs with the g3bench target of the same name.

The rest of the workspace is separate binaries

G3 is a workspace of applications, each in its own subdirectory with its own code and documentation, and the smaller ones are worth knowing about because they are usable on their own. g3statsd is a StatsD compatible stats aggregator, which is the piece that would sit behind the monitoring metrics g3proxy exposes. g3bench is a benchmark tool and its protocol coverage is the quickest way to understand the scope of the stack: HTTP/1.1, HTTP/2 and HTTP/3, WebSocket, TLS handshake, DNS over UDP, TCP, TLS, HTTP and QUIC as well as DNS over HTTP/3, Thrift RPC, and Cloudflare keyless. g3tiles is described as a work in progress reverse proxy, which is the honest status of the reverse proxy direction. Alongside them sit the public directories, with doc for project level documentation, sphinx for generating the HTML reference for each application, and scripts for auxiliary work such as coverage testing and packaging.

A Cargo workspace with a justfile gate

The build is a large Cargo workspace, and the shape of the tree says a lot about how the project is engineered. Every application is a member, and so is a long list of shared library crates under lib/, named for their function, g3-clap, g3-dpi, g3-http, g3-openssl, g3-resolver, g3-socks, g3-tls-cert, g3-xcrypt, g3-yaml, g3-udpdump and dozens more, plus a utils/ctl control binary for several applications and a capnp generate script crate. The default-members list selects the applications, which means a plain cargo build in the root produces the binaries rather than every internal crate. The quality gate is a justfile with four targets, and the aggregate one runs all three:

check:
    cargo check --workspace

test:
    cargo test --workspace --lib --examples

clippy:
    cargo clippy --tests -- --deny warnings

qa: check test clippy

The clippy invocation denies warnings outright, which is a stricter setting than most projects adopt. The repository also carries a .clippy.toml for lint configuration, deny.toml for dependency advisory checks, an ansible directory, a justfile, a scripts directory and CI configuration in both CircleCI and Cirrus, and the README badge states a minimum rustc of 1.90.

Linux is the supported target, the rest compiles

The platform story is stated precisely and is worth quoting rather than paraphrasing. Linux is fully supported. The code also compiles on macOS, on Windows 10 and later, on FreeBSD 14.3 and later, on NetBSD 10.1 and later and on OpenBSD 7.8 and later. The distinction between supported and compiles is the whole point, and a reader running a proxy in production should not treat a successful build on one of the secondary platforms as support. Packaging is documented too. Pre-built packages are published on a cloudsmith repository, but the README says it is still recommended to build packages yourself, with the details in the build and package document, and there is a separate long-term support page for the LTS version, which is the document to read if you need to pin a release and understand its support window. A dev-environment setup guide and a standards document cover the conventions the project expects from contributors.

Licence, disclosure and the shape of maintenance

The licence is Apache 2.0, and the tree carries a LICENSE file, a NOTICE file and a LICENSE-FOREIGN file, which together cover the third party components the build pulls in. Security issues have a stated route, through the ByteDance security center or a vulnerability reporting email, and the README asks explicitly that no public GitHub issue be created, which is the correct handling for a proxy product that many companies would be running on their networks. On versions, the release tags are per application rather than repository wide, with g3proxy-v1.12.4 on 2026-07-26, g3proxy-v1.12.3 on 2026-03-10 and g3proxy-v1.12.2 on 2025-08-20, so the cadence of the component people actually deploy is roughly a few releases a year. g3proxy has also joined the 404Starlink project, which is a distribution and community arrangement for security tooling, and the reference documentation for each application is published through readthedocs at g3-project.readthedocs.io.

Editorial conclusion

G3 earns an adoption if you already run it and need to keep a legacy deployment running, or if you want to read a serious Rust implementation of TLS interception, ICAP integration and egress routing, since the source is Apache 2.0 and the build is well organised. It does not earn adoption for a new project, because the README states the project is in maintenance mode and that active development has moved to VEY, and it is a poor fit for Windows, macOS or BSD operators who need those platforms fully supported, since only Linux is described as fully supported. Before you deploy it, read the long-term support page for the version you plan to pin, and decide between the pre-built packages on cloudsmith and building the packages yourself as the documentation recommends.

Frequently asked questions

Official sources

1. bytedance/g3 on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases