NaïveProxy ties its version numbers directly to the Chromium release it is built from, so every release represents both a proxy update and a synchronization with the latest Chrome TLS behaviour. Understanding this versioning model is essential for operators who need to keep their deployments undetectable as Chrome evolves over time.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/klzgrad/naiveproxy/llms.txt
Use this file to discover all available pages before exploring further.
Versioning policy
NaïveProxy version numbers correspond to the Chromium version they are based on. The current base is Chromium 150.0.7871.63. Each NaïveProxy release:- Updates the Chromium network stack to the latest stable Chrome version.
- Re-applies all NaïveProxy patches to Chromium on top of the new base.
- Publishes release notes on the corresponding GitHub tag.
Tracking updates
The correct way to track NaïveProxy updates:- Watch GitHub releases — each stable release is published at github.com/klzgrad/naiveproxy/releases with short release notes on the tag.
- Pin to a specific release tag in any automation or package build system.
- Monitor the Chrome release schedule to anticipate when a new NaïveProxy release will be needed.
You can view the upcoming Chrome stable release schedule at chromiumdash.appspot.com/schedule. Chrome typically follows a four-week release cadence for major stable versions, and NaïveProxy updates track these milestones.
Why frequent updates matter
Staying on the latest NaïveProxy release is a security requirement, not just a best practice.TLS fingerprinting and version drift
TLS fingerprinting and version drift
Deep-packet inspection systems and censorship infrastructure can fingerprint TLS clients by analysing the exact byte sequence of the TLS ClientHello message — including the list of cipher suites, TLS extensions, elliptic curves, and their order. This fingerprint is specific enough to identify a particular version of Chrome with high confidence.If you run an older NaïveProxy release, your client will advertise a TLS fingerprint that matches a Chrome version no longer deployed in the wild. This mismatch can be used as a detection signal:
- Outdated cipher suites — Chrome continuously rotates and deprecates cipher suites. An old fingerprint includes suites that real Chrome no longer offers.
- Missing extensions — new TLS extensions (such as post-quantum key exchange) are added in newer Chrome versions. Their absence in an otherwise “Chrome-like” handshake is anomalous.
- Version-stamped fields — some TLS fields encode version information that must remain consistent with the claimed User-Agent.
Platform support
NaïveProxy’s supported platform list has grown over time:Notable capability milestones
The following features have been added to NaïveProxy over its history. Specific version numbers and dates are published on each release tag rather than duplicated here.Post-quantum key agreement
Post-quantum key agreement
X25519Kyber768 post-quantum key agreement is enabled by default. This matches Chrome’s own behaviour and ensures that NaïveProxy traffic is not distinguishable from Chrome by the absence of post-quantum key exchange.To disable post-quantum key agreement (not recommended), pass the
--no-post-quantum flag:HTTP/3 (QUIC) transport
HTTP/3 (QUIC) transport
In addition to the original HTTP/2 transport, NaïveProxy supports HTTP/3 (QUIC) as an alternative tunnel protocol. To use QUIC instead of HTTPS, change the proxy scheme in your configuration:HTTP/3 may perform better on high-latency or lossy network paths because QUIC eliminates head-of-line blocking at the transport layer.
Padding protocol
Padding protocol
NaïveProxy’s padding protocol pads the first 8 reads and writes of each bidirectional stream to flatten packet-length distribution spikes caused by common TLS and HTTP/2 handshake sequences. RST_STREAM frames are also padded to avoid frequency-based fingerprinting. See Chromium Changes for the full technical description of these patches.