NaiveProxy 是什么？握手和 Chrome 一模一样，代价是什么
不翻车编辑部 · 更新于
先说结论：NaiveProxy 没有自己设计加密协议，而是把 Chrome 浏览器的网络代码直接拿来当客户端，走浏览器本来就有的 HTTPS 代理隧道（HTTP/2，也可以换 HTTP/3）。2026 年 10 月 18 日我们在测试服务器上做了实验：NaiveProxy v154 发出的第一个握手包，和正式版 Chrome 155 的加密套件（15 个）、扩展（16 个）、签名算法逐项相同；服务端开了防探测以后，不带密码去敲门，看到的是一个普通网页，没开的直接回 407 自报“我是代理”。代价是要自己的域名和证书、要一直跟着 Chrome 更新，Clash 系（mihomo）和 3x-ui 都用不了。
下面的原理部分来自 klzgrad/naiveproxy 仓库的 README 和发布页、sing-box 的 NaiveProxy 出站文档，以及一篇 2024 年的论文，核对日期 2026 年 10 月 18 日。实验的完整记录（版本、参数、原始数字）在文末。
NaiveProxy 是什么
NaiveProxy 2018 年 1 月在 GitHub 上开源，到 2026 年 10 月有约 9500 颗星，最新版是 10 月 7 日发布的 v154.0.8037.49-4。版本号开头的 154 就是它所用的 Chrome 版本。
它和别的协议最大的不同在客户端。别的协议是自己写一套网络代码，再想办法让握手看起来像浏览器；NaiveProxy 直接用 Chromium（Chrome 的开源底子）的网络栈，只保留需要的部分，官方写的是裁剪到原来源码和体积的 0.3%。README 第一句就是：用 Chromium 的网络栈来伪装流量。
数据走的是 HTTPS 代理的 CONNECT 隧道，这是浏览器设置代理时本来就有的功能。从外面看，就是一个 Chrome 在访问一个 HTTPS 网站。
想不被认出来，要过两关
第一关是长相。 你的设备连服务器，发出的第一个包叫客户端问候（Client Hello），里面列着它会用的加密方式、支持的扩展。不同程序列法不同，像指纹一样，这叫 TLS 指纹。很多协议是照着浏览器的样子去模仿这份清单，模仿得再像，也可能有细节对不上；NaiveProxy 发出去的本来就是 Chrome 的清单。
第二关是敲门。 防火墙觉得一台服务器可疑，会自己连过去试探，看它是不是代理，这叫主动探测。README 里给的参考是 2015 年就有人实测过的研究。NaiveProxy 的办法是让服务器门口站着一个真网站，官方叫“应用前置”（application fronting）。
实测一：握手和 Chrome 155 一样
服务端用的是官方推荐的 Caddy（v2.11.7）加 forwardproxy 插件的 naive 分支。我们让三种程序各连三次，在服务器上抓下每一个客户端问候，用 tshark 读出字段：
- NaiveProxy v154.0.8037.49-4 客户端
- 正式版 Chrome 155.0.8059.84（打开三次，每次启动发了两个客户端问候）
- curl 7.68.0（OpenSSL 1.1.1f）
| NaiveProxy v154 | Chrome 155 | curl 7.68 | |
|---|---|---|---|
| 加密套件 | 15 个 | 15 个 | 31 个 |
| 扩展 | 16 个 | 16 个 | 12 个 |
| 签名算法（不算 GREASE） | 11 个，与 Chrome 相同 | 11 个 | 20 个 |
| 后量子密钥交换 X25519MLKEM768 | 有 | 有 | 没有 |
| 客户端问候长度 | 1894–1958 字节 | 1894–1990 字节 | 每次 512 字节 |
两边唯一不同的是 GREASE：Chrome 故意往清单里塞的随机值，Chrome 自己每次连也不一样。长度在 1894 到 1990 字节之间跳，也是 Chrome 本身的行为。curl 的清单完全是另一套，放在一起一眼就能分出来。
这也带来一个要求。README 写得很直白：用户应该一直用最新版，这样签名才能和 Chrome 保持一致。
Chrome 大约每 4 周升一次大版本，握手可能跟着变。这次我们测的 NaiveProxy 是 154、Chrome 是 155，这两个版本握手没有变化；但客户端要是半年不更新，大家的 Chrome 都换了样子，你反而显眼。
实测二：敲门
同一台服务器开两个端口：20641 是 Caddy 自带的代理，没写防探测；20640 在配置里加了 probe_resistance，后面放了一个诱饵网页“小明的相册”。
结果：
- 20641（没开防探测）：像浏览器一样打开首页，回
407；不带密码当代理用，也回407 Proxy Authentication Required，还附上realm="Caddy Secure Web Proxy"。等于直接告诉对方：我是代理。 - 20640（开了防探测）：浏览器打开，是一个普通网页；不带密码或密码填错当代理用，回
308跳回首页，和普通网站没有两样。用户名和密码都对，它才转发。
自己搭的时候，probe_resistance 这一行千万别漏。
实测三：开头几个包的长度会变
翻墙时你打开的网站本身也是 HTTPS，代理的加密里面又装着一层你和网站之间的握手，这叫 TLS 套 TLS（AnyTLS 那篇专门讲过）。里面那层握手的包长很有规律，外面的人光看长度就可能猜出来。
NaiveProxy 的对策写在 README 的填充协议里：每条流开头的 8 次读写，各加 0 到 255 字节的随机填充，后面不加，免得拖慢速度。另外它把多条连接合进同一条 HTTP/2 连接里跑（多路复用）。
我们经 NaiveProxy 把同一个网址 https://example.com/ 请求了 6 次。里面装的是同一个 curl 请求，curl 自己的客户端问候固定 512 字节；可服务器看到的外层前几个包，长度每次都不一样：
这组实验说明填充在起作用，没有做不加填充的对照，不单独量化效果。
论文怎么说：难认，不等于认不出
2024 年 USENIX Security 会议上，Xue 等研究者发表了一篇专门识别“TLS 套 TLS”的论文，在美国一家运营商的网络里测了多种代理配置。表 3 里：
- 没做填充的 VLESS + TLS：74.8%
- 加了 Vision 填充：51.3%
- NaiveProxy：32.8%，在同一张表里算低的
论文的解释是多路复用比单纯的随机填充更管用，而 NaiveProxy 默认开着多路复用。但 32.8% 意味着三条里还能认出一条；而且这是在美国做的研究，不代表防火墙的实际做法，防火墙用什么方法没有公开数据。VLESS + REALITY 那篇引用的也是这张表。
自己搭需要什么
- 一台海外服务器；
- 一个自己的域名；
- 443 端口（所有 HTTPS 网站都用它）。
服务端用 Caddy 加作者维护的 forwardproxy naive 分支，官方已经编译好，下载就能用。官方示例配置的关键几行：basic_auth（用户名密码）、hide_ip（转发时不加你的 IP）、hide_via（不加代理标记）、probe_resistance（防探测），最后用 file_server 放一个真网站当门面。有了域名，证书 Caddy 会自己申请。
sing-box 文档专门提醒：不要用自签名证书，它会显著改变流量行为，违背 NaiveProxy 抵抗流量分析的初衷。我们的实验用的是临时自签证书，因为只比较客户端问候，它在服务器发证书之前就发出去了，不受影响；正式使用请用域名和正规证书。
哪些客户端支持
- 官方：Windows、macOS、Linux 命令行版，OpenWrt。
- 安卓：Exclave、husi、NekoBox（README 列出的）。
- Windows：v2rayN（README 列为第三方图形客户端）。
- sing-box：1.13.0 起有 NaiveProxy 出站，只能在苹果平台、安卓、Windows 和特定 Linux 构建上用。iPhone 要找基于 sing-box 1.13 以上版本的客户端。
不支持的：Clash 系的 mihomo 内核（官方文档的出站列表里没有，2026-10-18 核对），Xray 内核也没有。所以 3x-ui 面板里建不了 NaiveProxy 节点，和3x-ui 完整搭建教程里的方法不是一套。
缺点
- 门槛高：要域名、证书、443 端口，比在 3x-ui 里点几下建 VLESS 麻烦。
- 要一直追着 Chrome 更新：客户端旧了，指纹就对不上了。
- 默认走 TCP：HTTP/2 底下是 TCP，线路丢包多时会主动降速，这点和 VLESS 一样（Hysteria2 和 VLESS 丢包实测）。要转发 UDP，sing-box 里有
udp_over_tcp选项；也可以试 QUIC 模式。 - 客户端少：mihomo 和 Xray 都不支持，iPhone 上的选择尤其少。
和讲过的协议比
- VLESS + REALITY：借别人网站的证书，不用买域名，3x-ui 里点几下就有。NaiveProxy 要自己的域名和网站，好处是握手本身就是 Chrome，不用模仿。
- AnyTLS：同样在对付 TLS 套 TLS，靠一张能随时更换的填充表。NaiveProxy 靠 Chrome 本身，加开头的填充和多路复用。
没有一个是隐身衣。同一台服务器两个都开，晚上各连几次，在你那边连得稳、速度好的那个，就是你该用的。
常见问题
NaiveProxy 能让网速变快吗？ 不能。它管的是不容易被认出来，快不快看服务器和线路。
机场节点写着 NaiveProxy，是不是更安全？ 协议伪装得好，但节点那头能看到什么，和协议没有关系，见VPN 厂商能看到什么。
用它还会被封吗？ 有可能。官方说的是抗审查能力强、难被发现，没有说不会被封；服务器的 IP 被封了，换什么协议都没用。
iPhone 能用吗？ 要找基于 sing-box 1.13 以上的客户端；常见的 Clash 系客户端用不了。
实验记录
- 时间：2026 年 10 月 18 日（UTC 19:43–19:46）
- 服务器：测试服务器（香港，1 核 1 GB，Ubuntu 20.04），临时进程，实验后已删除
- 服务端：Caddy v2.11.7 + forwardproxy naive 分支（官方编译版 v2.11.7-naive）；20640 端口开
probe_resistance，20641 端口不开 - 客户端：NaiveProxy v154.0.8037.49-4（linux-x64）、Chrome 155.0.8059.84、curl 7.68.0（OpenSSL 1.1.1f）
- 抓包：tcpdump 只抓发往 20640 的 TLS 握手；tshark 4.6.8 读 ja4、ja4_r、扩展、长度
- 局限：单台服务器、单个时段；不测速度；识别率只引用论文，没有在真实审查网络里测