A proxy tool that uses Chromium's network stack to camouflage traffic and resist censorship with low detectability.
NaïveProxy is an open-source proxy tool that uses Chromium's network stack to camouflage proxy traffic as regular Chrome browser traffic. It is designed to resist internet censorship by defeating traffic analysis, TLS fingerprinting, and active probing techniques used by censors. The tool ensures low detectability while maintaining the performance and security best practices of Chrome's networking stack.
Users in regions with internet censorship who need a reliable and low-detectability tool to bypass restrictions, as well as developers and sysadmins looking to deploy self-hosted proxy solutions with strong anti-censorship features.
Developers choose NaïveProxy because it leverages Chromium's battle-tested network stack to provide unmatched traffic camouflage, making it extremely difficult for censors to distinguish proxy traffic from legitimate browser traffic. Its padding protocol and application fronting offer robust resistance against advanced detection methods while remaining lightweight and easy to deploy.
Make a fortune quietly
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Leverages Chromium's network stack to mimic Chrome traffic, defeating TLS fingerprinting and traffic classification as per the README's mitigation of attacks like website fingerprinting and active probing.
Implements a padding protocol that obfuscates packet lengths in initial handshakes, specifically targeting common sequences to flatten detectable patterns and avoid censorship detection.
Hides proxy servers behind standard frontend servers like Caddy or HAProxy using application-layer routing, preventing active probing by making the proxy appear as a regular web server.
Available for Windows, Android, Linux, macOS, and OpenWrt, with GUI client integrations such as v2rayN, ensuring broad accessibility across devices.
TLS over TLS adds handshake round trips and packet length enlargement, increasing latency and bandwidth usage, as admitted in the known weaknesses section of the README.
Requires building from source or customizing Caddy with specific Caddyfiles and build steps, which is more involved than using pre-configured proxy solutions.
Only the first 8 reads and writes are padded, leaving later traffic potentially detectable, and multiplexing relies on long-lived connections without clear organic rotation methods.