NaiveProxy：用 Chromium 网络栈做代理

摘要：在所有的代理抗检测方案中，NaiveProxy 采用了最”暴力”也最彻底的思路——直接使用 Chromium 浏览器的网络栈来传输代理流量。这意味着代理产生的 TLS 指纹、HTTP/2 行为和连接特征与真实的 Chrome 浏览器完全一致。本文解析 NaiveProxy 的设计理念、工作原理、优劣势以及当前的实际地位。

设计哲学：不模拟，而是”就是”

大多数代理协议在面对 TLS 指纹检测时，采用的策略是模拟（simulate）。典型的做法是使用 uTLS 库来伪造 TLS Client Hello，让代理的 TLS 握手看起来像是来自 Chrome、Firefox 等真实浏览器。

uTLS 的做法已经相当有效，但它本质上仍然是”模仿”——它复制了 Chrome 的 Client Hello 参数，但底层的网络栈仍然是 Go 语言的 crypto/tls。这意味着在 TLS 握手之外的行为（比如 HTTP/2 的帧处理、TCP 参数、连接管理等方面）仍然可能暴露非浏览器的特征。

NaiveProxy 的创造者 klzgrad 提出了一个更激进的思路：与其模拟浏览器，不如直接使用浏览器本身的网络代码。

NaiveProxy 的客户端直接基于 Chromium 的网络栈（net 模块）构建。它不是在另一个 TLS 库上伪造 Chrome 的指纹，而是直接调用 Chrome 使用的那套网络代码。这样一来，NaiveProxy 产生的流量在以下所有层面都与真实的 Chrome 浏览器一致：

• TLS 指纹（JA3/JA4）：完全一致，因为使用的是同一套 TLS 代码（BoringSSL）
• HTTP/2 行为：帧大小、流优先级、HPACK 压缩等行为完全一致
• TCP 参数：初始窗口大小、拥塞控制行为等由同一套代码控制
• ALPN 协商：协议协商过程与 Chrome 相同

用一个类比来说明：uTLS 是”化妆”——戴上面具让外表看起来像另一个人；NaiveProxy 是”克隆”——直接使用那个人的身体。从理论上来说，后者当然更加完美，因为没有什么比”就是它本身”更能通过身份验证了。

工作原理

NaiveProxy 的架构分为客户端和服务端两部分。

服务端：Caddy + forwardproxy

NaiveProxy 的服务端基于 Caddy Web 服务器，配合一个特殊的 forwardproxy 插件。Caddy 本身是一个功能完善的 Web 服务器，可以正常托管网站内容。forwardproxy 插件在 Caddy 的基础上添加了正向代理的功能——经过身份验证的客户端可以通过 Caddy 转发流量。

服务端的配置通过 Caddyfile 完成：

1
2
3
4
5
6
7
8
9
10
11
12
13

:443, your-domain.com
tls [email protected]
route {
  forward_proxy {
    basic_auth user password
    hide_ip
    hide_via
    probe_resistance
  }
  reverse_proxy https://your-camouflage-site.com {
    header_up Host {upstream_hostport}
  }
}

这个配置做了以下事情：

1. Caddy 监听 443 端口，使用 Let’s Encrypt 自动获取 TLS 证书
2. forward_proxy 插件提供正向代理功能，需要用户名密码认证
3. probe_resistance：当没有正确认证时，返回看起来像普通网站的内容，抵抗主动探测
4. reverse_proxy：对未认证的访问者，将请求反向代理到伪装站点

从审查者的角度来看，这台服务器就是一个普通的 HTTPS 网站。只有持有正确凭证的 NaiveProxy 客户端才能激活代理功能。

客户端：Chromium 网络栈

NaiveProxy 的客户端是一个经过修改的 Chromium 网络栈。客户端启动后，会在本地开放一个 SOCKS5 或 HTTP 代理端口，上层应用通过这个端口发送流量。客户端收到流量后，使用 Chromium 的网络代码与服务端建立 HTTPS 连接，通过 HTTP/2 CONNECT 方法转发流量。

客户端配置极为简洁：

1
2
3
4

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "https://user:[email protected]"
}

流量路径

完整的流量路径如下：

1

应用程序 → 本地 SOCKS5 → NaiveProxy 客户端 → HTTPS (Chromium 网络栈) → Caddy 服务器 → forward_proxy → 目标网站

从网络审查者的视角来看，客户端与服务器之间的通信就是一个普通的 HTTPS 连接——TLS 指纹是真正的 Chrome，HTTP/2 行为是真正的 Chrome，连接模式也符合正常的浏览器访问。

优势分析

完美的 TLS 指纹

这是 NaiveProxy 最核心的优势。由于直接使用 Chromium 的 BoringSSL，NaiveProxy 产生的 JA3/JA4 指纹与真实的 Chrome 浏览器完全相同——不是”几乎相同”或”非常接近”，而是完全相同。

对于使用 JA3/JA4 指纹进行流量分类的审查系统来说，NaiveProxy 的流量与正常的 Chrome HTTPS 流量无法区分。

超越指纹的一致性

NaiveProxy 的优势不仅限于 TLS 指纹。由于使用了完整的 Chromium 网络栈，以下方面也与 Chrome 一致：

• HTTP/2 帧行为：SETTINGS 帧参数、流量控制、HPACK 动态表大小等
• TCP 行为：初始拥塞窗口、重传策略等
• 证书验证：使用 Chromium 自带的证书验证逻辑
• OCSP 处理：在线证书状态协议的处理方式

即使审查者开发了比 JA3 更高级的指纹技术（比如分析 HTTP/2 帧序列或 TCP 行为模式），NaiveProxy 也能自然地通过检测。

内置的抗主动探测

服务端的 probe_resistance 功能提供了对主动探测的防御。当审查者尝试直接连接服务器时，看到的是一个正常的 HTTPS 网站（通过 reverse_proxy 伪装）。只有携带正确认证信息的请求才会被 forward_proxy 处理。

劣势与局限

尽管 NaiveProxy 在理论上有着最强的抗检测能力，但它在实际部署中存在多个显著的短板。

编译复杂度

这是 NaiveProxy 最大的实际障碍。由于客户端基于 Chromium 网络栈，构建客户端需要编译 Chromium 的部分代码。这不是一个简单的 go build 或 cargo build 能解决的问题：

• Chromium 代码库庞大：即使只编译网络栈部分，源码下载量也在 10GB 以上
• 构建依赖复杂：需要特定版本的编译器、Python 脚本和系统库
• 编译时间长：在普通硬件上编译可能需要数小时
• 平台限制：交叉编译支持有限

虽然 NaiveProxy 项目提供了预编译的二进制文件和 GitHub Actions 构建脚本，但如果 Chromium 更新导致构建失败，修复问题需要对 Chromium 构建系统有深入了解。

服务端同样需要编译一个特殊版本的 Caddy（包含 forwardproxy 插件），不过这比客户端的编译简单得多，可以使用 xcaddy 工具完成：

1

xcaddy build --with github.com/caddyserver/forwardproxy=github.com/klzgrad/forwardproxy@naive

Chromium 更新的跟进压力

Chrome 大约每四周发布一个新的主要版本。每次更新都可能改变网络栈的行为，包括 TLS 参数、HTTP/2 设置等。NaiveProxy 需要跟进这些更新，否则其 TLS 指纹会逐渐落后于真实的 Chrome 版本，反而可能成为特征。

这给项目维护者带来了持续的压力。如果 NaiveProxy 的 Chromium 版本落后太多，审查者甚至可以通过”这个 TLS 指纹来自一个过时版本的 Chrome”来识别它。

资源占用较高

由于嵌入了 Chromium 的网络栈，NaiveProxy 的二进制文件体积和内存占用都明显高于其他代理：

虽然在现代设备上这些数字并不算大，但在路由器或低配 VPS 等资源受限的环境中，这可能是一个考虑因素。

客户端支持有限

NaiveProxy 的客户端生态远不如 VLESS 或 Trojan 丰富：

• 独立客户端：只有官方的 naive 命令行工具
• GUI 客户端：几乎没有专门的图形化客户端
• 移动端：Android 上有一些第三方集成，iOS 上支持非常有限
• 代理平台集成：sing-box 支持 NaiveProxy 协议，但 Clash/mihomo 不支持

这意味着使用 NaiveProxy 通常需要搭配其他代理工具——比如在 sing-box 中配置 NaiveProxy 出站（outbound），或者在系统中设置 SOCKS5 代理指向 NaiveProxy 的本地端口。

协议单一

NaiveProxy 本质上就是 HTTPS 代理（HTTP/2 CONNECT）。它不支持 WebSocket、gRPC、QUIC 等多种传输方式。虽然 HTTPS 本身已经足够隐蔽，但在某些需要特殊传输方式的场景（比如 CDN 中转）下，NaiveProxy 的灵活性不如 VLESS+WebSocket 等方案。

NaiveProxy vs VLESS+Reality

这是一个很有意义的对比——两者都以抗检测为核心目标，但采取了完全不同的技术路线。

关键结论：在理论的抗检测能力上，NaiveProxy 确实是最强的——没有什么比”就是 Chrome”更完美的伪装。但在实际使用中，VLESS+Reality 的 uTLS 方案已经足够强大，两者被检测到的概率都极低。考虑到 Reality 在部署、维护和客户端支持方面的巨大优势，对于绝大多数用户来说，Reality 是更实际的选择。

NaiveProxy 更像是一个”理论最优解”——它证明了”直接使用浏览器网络栈”这条路线是可行的，并且在安全性上确实达到了最高水平。但工程上的代价使得它难以在实际中广泛推广。

当前状态与展望

截至 2026 年，NaiveProxy 仍然在活跃开发中，但更新频率和社区活跃度都不如 Xray 和 sing-box。它更多地被定位为一个小众但可靠的选择——适合那些对安全性有极致要求、且有能力处理部署复杂度的用户。

NaiveProxy 最大的贡献可能不是作为一个被广泛使用的代理工具，而是它提出的思路——“用真实的浏览器网络栈做代理”——影响了整个代理社区对抗检测技术的思考方式。uTLS 等模拟方案在不断进步，部分原因就是 NaiveProxy 展示了”完美伪装”应该是什么样子。

常见问题（FAQ）

Q1：NaiveProxy 适合普通用户吗？

不太适合。部署和维护的复杂度远高于 VLESS+Reality 或 Trojan 等方案。除非你有特殊的安全需求且具备技术能力，否则建议使用 Reality。

Q2：sing-box 支持 NaiveProxy 吗？

支持。sing-box 可以配置 NaiveProxy 类型的出站（outbound），这样你可以在 sing-box 的框架内使用 NaiveProxy 协议，同时享受 sing-box 的规则系统和 GUI 客户端。

Q3：NaiveProxy 会被检测到吗？

理论上极难检测。但要注意，任何代理都可能通过流量模式分析（而非指纹）被识别——比如长时间的大流量单一连接在统计上并不像正常的浏览行为。NaiveProxy 解决的是指纹问题，不能解决流量模式问题。

Q4：为什么不直接用 Chrome 浏览器做代理？

因为 Chrome 浏览器本身不提供正向代理功能。NaiveProxy 提取了 Chromium 的网络栈，剥离了渲染引擎、JavaScript 引擎等不需要的部分，只保留了网络通信的核心代码。

Q5：NaiveProxy 的服务端可以和其他服务共存吗？

可以。由于服务端基于 Caddy，你可以在同一台服务器上同时托管网站和运行 NaiveProxy。Caddy 本身就是一个高性能的 Web 服务器，代理功能只是一个插件。

Q6：forwardproxy 插件和标准 Caddy 的 forwardproxy 一样吗？

不一样。NaiveProxy 使用的是 klzgrad 维护的一个特殊分支，增加了 probe_resistance、hide_ip、hide_via 等安全特性。标准 Caddy 的 forwardproxy 没有这些功能。

外部链接

• NaiveProxy GitHub 仓库
• Caddy 官方网站
• uTLS 项目
• sing-box NaiveProxy 出站配置

NaiveProxy 代表了代理抗检测技术的理论上限。对于大多数用户来说，它更多的意义在于验证了一种思路，而不是作为日常使用的工具。