NaiveProxy: Hiding Proxy Traffic Inside Chrome's Own HTTPS Stack
Of 543 consumer VPNs in our data, 75 say they do not offer it. Below: the services that rank highest for it.
NaiveProxy is a free, open-source proxy whose client is built from Chromium's own networking code, so a censor sees ordinary Chrome HTTPS traffic heading to a real website. The server side is a Caddy web server with the forwardproxy plugin that quietly forwards authorised connections. It covers only apps pointed at it, so it is a proxy, not a full VPN.
Why reusing Chrome's code beats imitating it
Go-based stealth proxies such as Xray lean on uTLS to copy a browser's ClientHello, the first packet of the TLS handshake. The greeting passes, but packet lengths, timing and HTTP/2 framing of a Go binary still differ from a real browser. NaiveProxy instead ships a trimmed copy of Chromium's network stack, about 0.3% of the original source, so the handshake and every later frame belong to Chrome itself.
The path of one connection
The naive client reads a small config.json and opens a local SOCKS5 port, 127.0.0.1:1080 by default, which apps or the system proxy settings send traffic to. Traffic travels in a CONNECT tunnel to your domain, carrying a username and password. On the VPS, Caddy built with the naive fork of the forwardproxy plugin routes requests by the authorization header: valid credentials go out to the internet, anything else gets an ordinary website. The server needs a real domain with a trusted TLS certificate, which Caddy obtains automatically. Transport is HTTP/2 CONNECT over TCP by default, with HTTP/3 over QUIC as an option (switch the proxy scheme from https to quic).
What it defends against
| Detection method | Defence | What still leaks |
|---|---|---|
| TLS fingerprinting | genuine Chromium network code | outdated builds drift from current Chrome |
| Active probing | unauthorised visitors see a normal site | a blocked IP or domain kills the disguise |
| Traffic classification | HTTP/2 multiplexing, Chrome's preambles | many parallel tunnels make patterns easier to spot |
| Length-based analysis | padding and fragmentation | bulk traffic later in a stream is unpadded |
Padding and the habits that give a proxy away
Padding spends randomness only where it matters. The first eight reads and writes of every stream get 0 to 255 bytes of random filler; the CONNECT request and response carry a padded header of random length; RST_STREAM frames are preceded by a padded data frame so they look like ordinary headers. Later traffic stays unpadded to keep overhead down.
The rest depends on the operator. Run the latest stable release, since builds follow Chrome releases and a stale client's signature drifts from the browser it imitates. Skip self-signed certificates: the sing-box docs say they change traffic behaviour. Keep the concurrency setting (insecure_concurrency in sing-box) at a single tunnel connection, because more parallel connections make analysis easier.
Proxy, not VPN: what NaiveProxy leaves uncovered
NaiveProxy has no virtual network adapter of its own and documents no kill switch or leak protection; apps that are not set to use the proxy simply go around it. For whole-device routing, run it through a wrapper client with TUN mode, such as sing-box, which since version 1.13.0 has a naive outbound built on Chromium's Cronet library and can carry UDP inside the tunnel with UDP-over-TCP. Your exit IP is the server's, so sites see that address and the operator sees your traffic.
Where people run it and where it runs out
NaiveProxy was built against China's Great Firewall; the Arch Linux wiki notes it survived large-scale blocking of TLS-based circumvention tools there, and users in Russia discuss it as a fallback when VLESS with Reality connections get cut. Official builds exist for Windows, Linux, macOS and OpenWrt; on Android, Exclave, husi or NekoBox with the naive plugin work.
The limits are real: you need a VPS, a domain and a certificate, and client setup is more manual than any VPN app. If the censor blocks your server's IP or domain, no Chrome disguise helps. The default TCP mode works where UDP is blocked; QUIC mode needs UDP.
NaiveProxy among VPN services
In the VPNRadarLab main ranking of 377 services not a single one lists NaiveProxy support: 65 state they lack it and 312 publish nothing about it, which means undisclosed, not missing. Our ranking of free software that runs NaiveProxy is a different picture: seven open-source entries, from client apps and cores to one self-hosted server panel and the NaiveProxy project itself, none of them in the main ranking. If buying a domain sounds unappealing, see how VLESS Reality works as the closest alternative.
NaiveProxy FAQ
Is NaiveProxy a VPN?
No. It forwards traffic only for apps configured to use it; whole-device coverage requires a TUN-mode wrapper client.
Do I need my own domain for NaiveProxy?
Yes. The whole disguise rests on a real website with a trusted TLS certificate.
Does NaiveProxy work over QUIC?
As an option: switch the proxy scheme from https to quic. The default is HTTP/2 over TCP.
Can I use NaiveProxy without running a server?
Only if someone shares access to their setup; the project itself ships no service.
NaiveProxy at a glance
An open-source proxy built on Chromium's networking code, fronted by an ordinary website and padding its early traffic. Strong against fingerprinting and probing, defenceless against an IP block, and as reliable as your update discipline. Design notes and downloads live in the official repository.
Top services: NaiveProxy
- LĂ—Box4.38
- Exclave3.69
- sing-box3.50
- NekoBox3.39
- NekoBox for Android3.39