NaiveProxy

NaiveProxy 是一款思路独特的代理工具,由开发者 klzgrad 发起。它的核心理念是:直接复用 Chromium(Chrome 浏览器)的网络栈来收发流量,从而让代理连接在 TLS 指纹、HTTP/2 行为、报文模式等层面与真实 Chrome 访问网站几乎完全一致。许多代理之所以被识别,正是因为其 TLS ClientHello 指纹、HTTP/2 帧时序与真实浏览器存在细微差异;NaiveProxy 借用浏览器自身久经检验的实现来彻底消除这类差异,把对抗流量分析与主动探测的问题,交给浏览器与标准 HTTPS 正向代理这套成熟机制来解决,而不是自己去模仿。

背景与由来

研究与实践表明,审查系统可以通过 TLS 指纹分析、HTTP/2 帧时序、流量统计模式等高级手段识别代理,即便流量已被 TLS 包裹。原因在于:自造的 TLS 客户端很难在密码套件顺序、扩展列表、GREASE、ALPN、HTTP/2 SETTINGS等所有细节上与浏览器逐一对齐,任何偏差都可能成为指纹。klzgrad 的关键洞见是:与其费力模仿,不如直接用 Chromium 的网络组件。NaiveProxy 以 Chromium 的网络栈为基础,把流量伪装成一次普通的、由 Chrome 发起的 HTTPS 请求,并采用标准的 HTTP CONNECT 正向代理(带 Basic 认证) 语义,使其与企业里常见的正规 HTTPS 正向代理在协议层面无异。

设计目标

• 极致真实的指纹:TLS ClientHello、密码套件、扩展、GREASE、ALPN、HTTP/2 设置等均与真实 Chrome 完全一致,且随 Chromium 更新自动跟进。
• 对抗主动探测:服务端基于真实 Web 服务器(如 Caddy),对未授权或非代理请求表现为一个正常网站,使主动探测无法区分。
• 消除应用层指纹:不仅伪装 TLS,还覆盖 HTTP/2 多路复用、帧调度、头部压缩等应用层行为,避免在 TLS 之上的层面露馅。
• 复用成熟基础设施:尽量站在浏览器与主流 Web 服务器的肩膀上,把可被特异化的自造部分降到最低。

工作原理

NaiveProxy 的典型架构是 客户端 + 服务端,服务端常基于 Caddy 的 forwardproxy 插件(或 NaiveProxy 自带的服务端模式):

• 服务端是一台真实的 HTTPS 网站:Caddy 提供合法证书与正常网页内容,同时集成 HTTP/2 CONNECT 正向代理能力,并要求用户名密码认证。
• 客户端(基于 Chromium 网络栈)向该站发起标准的 HTTPS 连接,在其中用 HTTP CONNECT 请求把目标主机隧道化,并附带 Basic 认证凭据。
• 认证通过则建立到目标的代理隧道,后续应用流量在该 HTTPS 连接内转发;认证失败或为普通请求则被当作正常网站访问,由 Caddy 返回真实网页。整个交互过程,与一次浏览器访问受保护网站并发起 CONNECT 完全一致。

为进一步消除可被分析的特征,NaiveProxy 还引入了 padding(长度填充) 等措施,扰乱 CONNECT 响应与数据的长度模式,使其更难通过包长统计被识别。其机密性与完整性完全由标准 TLS 提供,NaiveProxy 自身不做额外加密。

这一架构的精妙之处在于,它把代理的存在性隐藏在一个完全合法的协议行为之下:HTTP CONNECT 本就是 HTTP/1.1 与 HTTP/2 标准中用于隧道的正式方法,企业 HTTPS 正向代理日常就在使用它。因此审查方即便能看到 CONNECT 请求,也无法据此判定这是翻墙——它和公司里员工通过受认证的正向代理上网在协议层面别无二致;而没有正确凭据的探测者,连 CONNECT 都发不出(会被当作普通访客看到网站首页)。这种把代理伪装成一项本就存在的合法功能的思路,是 NaiveProxy 区别于多数自造协议的根本所在。

传输特性

• 基于 TCP + TLS + HTTP/2,利用 HTTP/2 的多路复用在单连接内承载多条隧道,行为与浏览器并发请求一致。
• 因复用浏览器栈,其 TLS 与 HTTP/2 指纹随 Chromium 版本演进,天然跟随主流浏览器变化,无需手动维护指纹库,这是其相对 uTLS 方案的独特优势。
• 主要面向 TCP 流量(网页、API 等),对 UDP 应用的支持不是其设计重点;需要 UDP 时通常另行配合其他方案。
• 支持通过 sing-box 等以 TUN 方式接管系统流量。

演进关系与对比

• 相对 Trojan / VLESS+TLS:它们用真 TLS,但其 TLS/HTTP 指纹仍可能与浏览器有差异而露馅;NaiveProxy 直接借浏览器栈,指纹真实性更高,几乎不可区分。
• 相对 uTLS 方案(如 Reality 配 uTLS):uTLS 是手动模拟浏览器指纹的库,需持续更新以跟上浏览器;NaiveProxy 则直接使用浏览器本体实现,理念上更彻底、维护更省心,但也更重。
• 相对 Shadowsocks/VMess:NaiveProxy 不追求最轻量,而追求与真实浏览器流量不可区分,定位与权衡完全不同。
• 相对 Reality:两者目标相近(消除暴露面),路径不同——Reality 借证书 + uTLS,NaiveProxy 借整套浏览器栈 + 真实 Web 服务。

实现与客户端生态

NaiveProxy 提供基于 Chromium 的客户端二进制(各平台),服务端推荐搭配 Caddy + forwardproxy 插件,也有自带服务端模式。它还被 sing-box 等集成为可选协议,便于与 TUN、路由规则结合。部署需要一个真实域名与证书(Caddy 可自动 ACME 签发续期)并设置认证凭据;相对其他协议,其运维更贴近搭建并维护一个正常网站,而代理能力是其上的附加层。作者也维护了对 Chromium 网络栈的补丁集,使客户端二进制能跟随上游 Chromium 的发布周期更新,从而持续保持与最新浏览器一致的指纹。

从研究脉络看,NaiveProxy 的诞生与学界对流量分析与主动探测如何识别代理的持续研究密切相关。它的设计文档明确列举了代理可能被识别的若干向量(如 TLS 指纹差异、可被探测的回落行为、HTTP/2 行为差异、长度模式等),并逐一用复用浏览器与真实 Web 服务器的方式加以消解。这种以威胁模型为出发点、逐项封堵识别向量的工程态度,使 NaiveProxy 在抗高级检测方向上具有方法论上的代表性,也常被作为评估其他方案隐蔽性的参照。

适用与局限

NaiveProxy 适合对抗高级流量分析与主动探测要求极高、并愿意以一个真实网站为载体部署的用户。其局限在于:基于完整浏览器栈使其相对偏重,资源占用与极致轻量协议有差距;对 UDP 类应用支持有限;部署依赖域名、证书与正确的 Web 服务配置,门槛高于即开即用的轻量代理。此外其抗封锁强度也部分取决于所选回落网站与服务器 IP 的整体可信度。总体而言,它代表了一条用真实浏览器行为彻底抹除指纹的独特而严谨的技术路线,在抗指纹方向上具有标杆意义。即便其用户基数不如 Shadowsocks、VLESS 等庞大,NaiveProxy 所确立的以真实软件栈消除一切人造痕迹的思想,以及它对各类识别向量的系统化梳理,都对后续抗封锁工具的设计产生了深远影响,常被视为隐蔽性研究的重要参照实现。