[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-514":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":9,"totalLinesOfCode":9,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":9,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":9,"createdAt":9,"pushedAt":9,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":16,"starSnapshotCount":16,"syncStatus":27,"lastSyncTime":28,"discoverSource":29},514,"naiveproxy","klzgrad\u002Fnaiveproxy","klzgrad","Make a fortune quietly",null,"https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy","C++",9132,1013,123,4,0,67,106,464,201,40.02,false,"main","2026-06-12 02:00:14","# NaïveProxy ![build workflow](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Factions\u002Fworkflows\u002Fbuild.yml\u002Fbadge.svg)\n\nNaïveProxy uses Chromium's network stack to camouflage traffic with strong censorship resistence and low detectablility. Reusing Chrome's stack also ensures best practices in performance and security.\n\nThe following traffic attacks are mitigated by using Chromium's network stack:\n\n* Website fingerprinting \u002F traffic classification: mitigated by [traffic multiplexing in HTTP\u002F2](https:\u002F\u002Farxiv.org\u002Fabs\u002F1707.00641) and parroting preambles.\n* [TLS parameter fingerprinting](https:\u002F\u002Farxiv.org\u002Fabs\u002F1607.01639): defeated by reusing [Chrome's network stack](https:\u002F\u002Fwww.chromium.org\u002Fdevelopers\u002Fdesign-documents\u002Fnetwork-stack).\n* [Active probing](https:\u002F\u002Fensa.fi\u002Factive-probing\u002F): defeated by *application fronting*, i.e. hiding proxy servers behind a commonly used frontend server with application-layer routing.\n* Length-based traffic analysis: mitigated by padding and fragmentation.\n\n## Architecture\n\n[Browser → Naïve client] ⟶ Censor ⟶ [Frontend → Naïve server] ⟶ Internet\n\nNaïveProxy uses Chromium's network stack to parrot traffic between regular Chrome browsers and standard frontend servers.\n\nThe frontend server can be any well-known reverse proxy that is able to route HTTP\u002F2 traffic based on HTTP authorization headers, preventing active probing of proxy existence. Known ones include Caddy with its forwardproxy plugin and HAProxy.\n\nThe Naïve server here works as a forward proxy and a packet length padding layer. Caddy forwardproxy is also a forward proxy but it lacks a padding layer. A [fork](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fforwardproxy) adds the NaïveProxy padding layer to forwardproxy, combining both in one.\n\n## Download NaïveProxy\n\nDownload [here](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Freleases\u002Flatest). Supported platforms include: Windows, Android (with [Exclave](https:\u002F\u002Fgithub.com\u002Fdyhkwong\u002FExclave), [husi](https:\u002F\u002Fgithub.com\u002Fxchacha20-poly1305\u002Fhusi), [NekoBox](https:\u002F\u002Fgithub.com\u002FMatsuriDayo\u002FNekoBoxForAndroid)), Linux, Mac OS, and OpenWrt ([support status](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Fwiki\u002FOpenWrt-Support)).\n\nUsers should always use the latest version to keep signatures identical to Chrome.\n\nBuild from source: Please see [.github\u002Fworkflows\u002Fbuild.yml](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Fblob\u002Fmaster\u002F.github\u002Fworkflows\u002Fbuild.yml).\n\n## Server setup\n\nThe following describes the naïve fork of Caddy forwardproxy setup.\n\nDownload [here](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fforwardproxy\u002Freleases\u002Flatest) or build from source:\n```sh\ngo install github.com\u002Fcaddyserver\u002Fxcaddy\u002Fcmd\u002Fxcaddy@latest\n~\u002Fgo\u002Fbin\u002Fxcaddy build --with github.com\u002Fcaddyserver\u002Fforwardproxy=github.com\u002Fklzgrad\u002Fforwardproxy@naive\n```\n\nExample Caddyfile (replace `user` and `pass` accordingly):\n```\n{\n  order forward_proxy before file_server\n  log {\n    exclude http.log.error # Avoid logging user activity\n  }\n}\n:443, example.com {\n  tls me@example.com\n  encode\n  forward_proxy {\n    basic_auth user pass\n    hide_ip\n    hide_via\n    probe_resistance\n  }\n  file_server {\n    root \u002Fvar\u002Fwww\u002Fhtml\n  }\n}\n```\n`:443` must appear first for this Caddyfile to work. See Caddyfile [docs](https:\u002F\u002Fcaddyserver.com\u002Fdocs\u002Fcaddyfile\u002Fdirectives\u002Ftls) for customizing TLS certificates. For more advanced usage consider using [JSON for Caddy 2's config](https:\u002F\u002Fcaddyserver.com\u002Fdocs\u002Fjson\u002F).\n\nRun with the Caddyfile:\n```\nsudo setcap cap_net_bind_service=+ep .\u002Fcaddy\n.\u002Fcaddy start\n```\n\nSee also [Systemd unit example](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Fwiki\u002FRun-Caddy-as-a-daemon) and [HAProxy setup](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Fwiki\u002FHAProxy-Setup).\n\n## Client setup\n\nRun `.\u002Fnaive` with the following `config.json` to get a SOCKS5 proxy at local port 1080.\n```json\n{\n  \"listen\": \"socks:\u002F\u002F127.0.0.1:1080\",\n  \"proxy\": \"https:\u002F\u002Fuser:pass@example.com\"\n}\n```\n\nOr `quic:\u002F\u002Fuser:pass@example.com`, if it works better. See also [parameter usage](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Fblob\u002Fmaster\u002FUSAGE.txt) and [performance tuning](https:\u002F\u002Fgithub.com\u002Fklzgrad\u002Fnaiveproxy\u002Fwiki\u002FPerformance-Tuning).\n\n## Third-party integration\n\n* [v2rayN](https:\u002F\u002Fgithub.com\u002F2dust\u002Fv2rayN), GUI client\n\n## Notes for downstream\n\nDo not use the master branch to track updates, as it rebases from a new root commit for every new Chrome release. Use stable releases and the associated tags to track new versions, where short release notes are also provided.\n\n## Padding protocol, an informal specification\n\nThe design of this padding protocol opts for low overhead and easier implementation, in the belief that proliferation of expendable, improvised circumvention protocol designs is a better logistical impediment to censorship research than sophisicated designs.\n\n### Proxy payload padding\n\nNaïveProxy proxies bidirectional streams through HTTP\u002F2 (or HTTP\u002F3) CONNECT tunnels. The bidirectional streams operate in a sequence of reads and writes of data. The first `kFirstPaddings` (8) reads and writes in a bidirectional stream after the stream is established are padded in this format:\n```c\nstruct PaddedData {\n  uint8_t original_data_size_high;  \u002F\u002F original_data_size \u002F 256\n  uint8_t original_data_size_low;  \u002F\u002F original_data_size % 256\n  uint8_t padding_size;\n  uint8_t original_data[original_data_size];\n  uint8_t zeros[padding_size];\n};\n```\n`padding_size` is a random integer uniformally distributed in [0, `kMaxPaddingSize`] (`kMaxPaddingSize`: 255). `original_data_size` cannot be greater than 65535, or it has to be split into several reads or writes.\n\n`kFirstPaddings` is chosen to be 8 to flatten the packet length distribution spikes formed from common initial handshakes:\n- Common client initial sequence: 1. TLS ClientHello; 2. TLS ChangeCipherSpec, Finished; 3. H2 Magic, SETTINGS, WINDOW_UPDATE; 4. H2 HEADERS GET; 5. H2 SETTINGS ACK.\n- Common server initial sequence: 1. TLS ServerHello, ChangeCipherSpec, ...; 2. TLS Certificate, ...; 3. H2 SETTINGS; 4. H2 WINDOW_UPDATE; 5. H2 SETTINGS ACK; 6. H2 HEADERS 200 OK.\n\nFurther reads and writes after `kFirstPaddings` are unpadded to avoid performance overhead. Also later packet lengths are usually considered less informative.\n\n### H2 RST_STREAM frame padding\n\nIn experiments, NaïveProxy tends to send too many RST_STREAM frames per session, an uncommon behavior from regular browsers. To solve this, an END_STREAM DATA frame padded with total length distributed in [48, 72] is prepended to the RST_STREAM frame so it looks like a HEADERS frame. The server often replies to this with a WINDOW_UPDATE because padding is accounted in flow control. Whether this results in a new uncommon behavior is still unclear.\n\n### H2 HEADERS frame padding\n\nThe CONNECT request and response frames are too short and too uncommon. To make its length similar to realistic HEADERS frames, a `padding` header is filled with a sequence of symbols that are not Huffman coded and are pseudo-random enough to avoid being indexed. The length of the padding sequence is randomly distributed in [16, 32] (request) or [30, 62] (response).\n\n### Opt-in of padding protocol\n\nNaïveProxy clients should interoperate with any regular HTTP\u002F2 proxies unaware of this padding protocol. NaïveProxy servers (i.e. any proxy server capable of the this padding protocol) should interoperate with any regular HTTP\u002F2 clients (e.g. regular browsers) unaware of this padding protocol.\n\nNaïveProxy servers and clients determines whether the counterpart is capable of this padding protocol by the presence of the `padding` header in the CONNECT request and response respectively. The padding procotol is enabled only if the `padding` header exists.\n\nThe first CONNECT request to a server cannot use \"Fast Open\" to send payload before response, because the server's padding capability has not been determined from the first response and it's unknown whether to send padded or unpadded payload for Fast Open.\n\n## Changes from Chromium upstream\n\n- Minimize source code and build size (0.3% of the original)\n- Disable exceptions and RTTI, except on Mac and Android.\n- Support OpenWrt builds\n- (Android, Linux) Use the builtin verifier instead of the system verifier (drop dependency of NSS on Linux) and read the system trust store from (following Go's behavior in crypto\u002Fx509\u002Froot_unix.go and crypto\u002Fx509\u002Froot_linux.go):\n  - The file in environment variable SSL_CERT_FILE\n  - The first available file of\n    -  \u002Fetc\u002Fssl\u002Fcerts\u002Fca-certificates.crt (Debian\u002FUbuntu\u002FGentoo etc.)\n    -  \u002Fetc\u002Fpki\u002Ftls\u002Fcerts\u002Fca-bundle.crt (Fedora\u002FRHEL 6)\n    -  \u002Fetc\u002Fssl\u002Fca-bundle.pem (OpenSUSE)\n    -  \u002Fetc\u002Fpki\u002Ftls\u002Fcacert.pem (OpenELEC)\n    -  \u002Fetc\u002Fpki\u002Fca-trust\u002Fextracted\u002Fpem\u002Ftls-ca-bundle.pem (CentOS\u002FRHEL 7)\n    -  \u002Fetc\u002Fssl\u002Fcert.pem (Alpine Linux)\n  - Files in the directory of environment variable SSL_CERT_DIR\n  - Files in the first available directory of\n    -  \u002Fetc\u002Fssl\u002Fcerts (SLES10\u002FSLES11, https:\u002F\u002Fgolang.org\u002Fissue\u002F12139)\n    -  \u002Fetc\u002Fpki\u002Ftls\u002Fcerts (Fedora\u002FRHEL)\n    -  \u002Fsystem\u002Fetc\u002Fsecurity\u002Fcacerts (Android)\n- Handle AIA response in PKCS#7 format\n- Allow higher socket limits for proxies\n- Force tunneling for all sockets\n- Support HTTP\u002F2 and HTTP\u002F3 CONNECT tunnel Fast Open using the `fastopen` header\n- Pad RST_STREAM frames\n","NaïveProxy 是一个利用 Chromium 网络栈来伪装流量的代理工具，具有强大的审查抵抗能力和低可检测性。其核心功能包括通过 HTTP\u002F2 的流量复用和模仿前导包来缓解网站指纹识别与流量分类攻击，重用 Chrome 的网络栈以对抗 TLS 参数指纹识别，并通过应用前端技术隐藏代理服务器以防止主动探测。此外，它还通过填充和分段来减轻基于长度的流量分析。适用于需要绕过严格网络审查的场景，如访问被封锁的网站或服务。支持多种平台，包括 Windows、Android、Linux、Mac OS 和 OpenWrt。",2,"2026-06-11 02:37:01","trending"]