Skip to main content

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.

NaïveProxy is a proxy tool that defeats censorship by routing your traffic through Chromium’s own network stack, making it indistinguishable from regular Chrome browser activity. Rather than inventing a new protocol that censors can learn to recognize, NaïveProxy reuses the exact same code Chrome ships — producing TLS handshakes, HTTP/2 multiplexing patterns, and connection preambles that are byte-for-byte identical to a real browser visiting a website.

How It Defeats Traffic Analysis

Modern censorship systems attack proxy traffic on four distinct fronts. NaïveProxy addresses each one by design.

Website Fingerprinting & Traffic Classification

HTTP/2 multiplexing matches Chrome’s connection patterns and parrots its preambles, making proxy streams statistically indistinguishable from normal browser sessions. Research shows multiplexed HTTP/2 traffic defeats most traffic classification attacks.

TLS Parameter Fingerprinting

NaïveProxy reuses Chrome’s BoringSSL directly, so the TLS ClientHello — cipher suite order, extensions, elliptic curves — is identical to whatever Chrome version the binary was built from. There is no synthetic fingerprint for a censor to profile. See research background.

Active Probing

The frontend server applies application fronting: unauthenticated requests are served ordinary web content, while proxy requests are only routed to the backend when a valid HTTP Authorization header is present. A censor probing the server sees a normal website — there is no detectable proxy surface.

Length-Based Traffic Analysis

The first 8 reads and writes of every CONNECT tunnel are padded with random-length payloads. HEADERS frames carry pseudo-random padding (16–32 bytes request, 30–62 bytes response) and RST_STREAM frames are padded to look like HEADERS frames, flattening the distinctive length spikes produced by initial handshakes.

Architecture

NaïveProxy is a two-component system. The Naïve client runs locally and speaks Chrome’s network protocols. The frontend server runs on a remote host and acts as both a legitimate web server and a proxy backend — routing authenticated requests to the Naïve server while serving ordinary content to everything else.
[Browser → Naïve client] ⟶ Censor ⟶ [Frontend → Naïve server] ⟶ Internet
Traffic crossing the censor boundary is standard HTTPS from a Chrome-like client to a real web server. The Naïve server (implemented as Caddy with the forwardproxy naive fork) sits behind that frontend and handles the padding protocol and forward proxy duties in a single process.

Supported Platforms

NaïveProxy binaries are available for: Download the latest release from the GitHub releases page.
Always use the latest version of NaïveProxy. Signatures are derived directly from the Chromium version the binary embeds — running an old build means your TLS fingerprint no longer matches current Chrome, which can make your traffic distinguishable. The current build is based on Chromium 150.0.7871.63.

Third-Party Integration

NaïveProxy is supported natively in v2rayN, a popular GUI client for Windows. The naive protocol is also available in several Android clients listed above.

Next Steps

  • Follow the Quickstart to deploy a server and start proxying in under 5 minutes.
  • Read How It Works for a deeper look at the padding protocol, TLS fingerprint strategy, and active-probing defenses.

Build docs developers (and LLMs) love