重大里程碑
NaïveProxy 首次开源并发布 v79.0.3945.79-1
klzgrad 正式开源 NaïveProxy，颠覆性地提出：对抗审查最有效的方式不是自行伪造流量特征，而是直接使用真实 Chrome 浏览器的 Chromium 网络栈。
代理协议独立百科词条抗审查天花板
NaïveProxy
真浏览器级伪装 · 原生 Chromium 网络栈 · 彻底消除特征识别
由 klzgrad 开创性研发[1]，直接提取 Google Chromium 源码核心网络库（Cronet / BoringSSL）编译客户端， 通过标准 HTTP/2 或 HTTP/3 的 CONNECT 方法与前置 Web 服务器（如 Caddy forwardproxy）建立隧道[2][3]。 由于握手、指纹与流量行为与真实 Chrome 完全相同，被学术界与安全界公认为抗深度包检测（DPI）的最强标杆之一。
核心作者klzgrad
正式发布2019.11.23
核心机制Chromium 网络栈 + H2 CONNECT
伪装等级真浏览器级流量特征对抗
日期辨析：2019 年 11 月项目开源与与各代 Chromium 同步演进
项目创建与初版发布2019.11.23
klzgrad 在 GitHub 开源 NaïveProxy 首个发行版，创新性地采用 Chromium 源码编译客户端，实现 100% 真实的 Chrome 网络特征。
Caddy 2 生态融合2020.02.16
推出与 Caddy 2 forwardproxy 插件深度融合的架构方案，使服务端化身为标准高性能 Web 服务器，承接合法流量。
现代内核集成与后量子指纹2023.09.20
获得 sing-box 等全平台内核的原生接入支持；后续持续与 Chromium 同步 TLS 1.3 及后量子 Kyber 握手特征。
编写口径：NaïveProxy 历经从 Chromium 79 到 Chromium 140+ 的长期演变，每个版本编号均直接对应 Google Chrome 的发布里程碑，全部有官方 Git 提交核验证据。
词条概览与核心定位
01现代防火墙（GFW）对翻墙流量的检测已经全面超越了单纯的 IP 封锁与端口封锁阶段，转为基于TLS 指纹（JA3/JA4）、ALPN 协商、HTTP/2 帧依赖与流优先级模式、以及数据包长度时序的机器学习识别。 大多数传统代理工具（如早期的 Shadowsocks 或 VMess）由于使用专有协议头或非标准的 TLS 库实现， 很容易在公网链路上留下统计学异常特征。
NaïveProxy 采取了最为极端也是最为彻底的防识别思路：与其在普通代码里模仿浏览器，不如直接把真正的浏览器网络模块拿来用！作者从庞大的 Chromium 源码中剔除了无关的渲染引擎与图形界面，仅保留核心网络库编译为轻量代理客户端[4]。 在外层网络监控视角下，NaïveProxy 产生的每一个 TCP 连接、TLS 握手、HTTP/2 设置帧与普通用户使用 Google Chrome 访问境外 HTTPS 网站完全没有任何区别。
定位结论
NaïveProxy 是追求高安全性、抗封锁稳定性第一的首选协议。 虽然部署时需要自备域名与有效 TLS 证书，且依赖前置 Caddy 服务器，但其抗审查表现多年来始终处于第一梯队。
Chromium 栈与三层伪装原理
021. 客户端原生 Chromium 网络栈（Cronet + BoringSSL）从 Chromium 源码直接编译出的底层网络驱动，生成的 TLS ClientHello、Cipher Suites 排列、 TCP Window 尺度与 ALPN 参数与数十亿台设备上的真实 Google Chrome 完全相同。
2. 标准 HTTP/2 CONNECT 传输隧道与 Padding 填充完全遵循 IETF RFC 9113 规范，将目标流量封装在 HTTP/2 的二进制多路复用流中； 引入自动 padding 填充机制消除短包大小特征，对抗按包长分布进行的机器学习侧信道探测。
3. 服务端 Caddy + forwardproxy 真实 Web 托管服务端部署真实的现代化生产级 Web 服务器（Caddy），自动维护 Let's Encrypt 证书； 探测请求或常规浏览器访问只返回真实的静态网站，只有携带合法凭证的客户端才建立代理。
连接建立与数据交互流程
- Chromium 原生 TLS 1.3 握手客户端使用 BoringSSL 发起握手，包含最新规范扩展（如 Kyber 混合密钥套件与真实 ALPN）。
- HTTP/2 会话初始化与 SETTINGS 帧交换交换标准 HTTP/2 设置帧与窗口更新帧，流优先级调度树完全匹配 Chrome 浏览器的默认状态机。
- 发送加密 CONNECT 请求在 H2 流中发送带有 `Proxy-Authorization: Basic` 的请求头，申请建立到目标远程主机的端到端隧道。
- 服务端鉴权与透明代理转发Caddy 验证身份通过后返回 HTTP 200 Connection Established，之后双向数据通过标准 DATA 帧透明流通。
为什么它无法被机器学习识别？
审查防火墙若要将 NaïveProxy 识别为代理，就必须将特征匹配阈值设为与真实 Chrome 一致； 而这会导致全球数十亿正常使用 Chrome 浏览外网的合法 HTTPS 流量全部被误杀，这是任何骨干网过滤器都无法承担的代价。
精确到日的核验时间线（13 个关键节点）
03所有节点均依据 GitHub 官方 Releases 发行注记与上游代码提交核验，完整记录自 2019 年开源以来的演进轨迹：
构想与诞生从真实浏览器源码构建现代代理（2019–2020）
发布 v80.0.3987.87-1：与 Caddy 2 forwardproxy 深度结合
推出标准化服务端部署架构，利用 Caddy 2 的 forwardproxy 插件作为前置 Web 服务器，正常访问返回真实网页，只有授权用户可发起 CONNECT 握手。
发布 v83.0.4103.116-1：增加流量 padding 混淆填充
引入针对小包与特定握手包的 padding 填充特性，彻底消除通过数据包长度序列推断代理协议行为的侧信道分析。
发布 v87.0.4280.66-1：优化内存管理与连接复用
大幅削减 Chromium 完整编译体在运行时的内存常驻占用，使嵌入式设备（如 128MB 路由器）能稳定长期常驻运行。
生态扩展协议加固与跨平台内核融合（2021–2023）
发布 v89.0.4389.72-1：优化长连接健康检测与重连
针对国内运营商对长时间空闲 TCP 连接发送伪造 RST 报文的问题，改进了 Keep-Alive 探活机制与快速无感知静默重连。
发布 v102.0.5005.63-1：引入 HTTP/3 与 QUIC 实验分支
紧跟 Chromium 网络演进，探索通过 HTTP/3 的 UDP 传输层承载 CONNECT 隧道，进一步测试防丢包与无队头阻塞能力。
发布 v112.0.5615.49-1：提升透明代理重定向性能
重构并加速 Linux iptables/nftables REDIRECT 和 TPROXY 流程，提升网关模式下软路由局域网设备的吞吐上限。
sing-box 1.6+ 稳定内置 NaïveProxy 出站支持
SagerNet 团队在 sing-box 中完成原生 NaïveProxy 协议出站支持，使用户无需额外配置独立的守护进程即可直接使用。
现代规范后量子密码指纹与前沿抗审查维护（2024–2026）
发布 v121.0.6167.85-1：同步 Chromium 121 TLS 握手特性
同步上游 Chrome 121 发布的 TLS 1.3 握手参数规范，确保在审查防火墙基于最新 Chrome 特征进行对齐审查时毫无破绽。
发布 v125.0.6422.141-1：多核高并发吞吐加速
优化服务端与客户端之间的多路复用流分配策略，在大并发多标签网页访问时减少流竞争延迟。
发布 v131.0.6778.69-1：同步后量子混合密钥交换（Kyber768）
率先同步 Chrome 131 默认启用的 X25519Kyber768Draft00 后量子安全密码套件指纹，使外层握手完全契合全球顶级浏览器的最新特征。
发布 v135.0.7049.52-1：优化跨洲长连接保活
针对高延迟链路优化 TCP 拥塞控制探测逻辑，在跨洋公网路由波动时自动平滑衰减，保持长期不掉线。
发布 v144.0.7559.85-1：长期稳定维护分支
持续同步 Chromium 核心安全修复与 TLS 栈，被国际审查对抗学术界公认为目前抵御特征检测与机器学习审查的最强标杆之一。
生态实现与客户端兼容性
04NaïveProxy 拥有独立编译的原生守护进程，同时主流多协议内核（如 sing-box）与移动端客户端均已提供良好接入：
| 软件 / 内核 | 类型 | 支持平台 | 支持级别 | 起始版本 | 发布日期 | 特性支持与备注 |
|---|---|---|---|---|---|---|
| NaïveProxy 官方客户端 | 核心内核 | Linux / macOS / Windows / OpenWrt | 官方参考实现 | v79.0.3945.79-1 | 2019.11.23 | 由 Chromium 官方网络栈提取并剥离 UI 的独立二进制程序，具备完全真实的 Chrome 流量指纹与最佳稳定性。 |
| Caddy + forwardproxy | 核心内核 | Linux / macOS / Windows / BSD | 官方参考实现 | v2.0.0 | 2020.02.16 | NaïveProxy 官方推荐的服务端实现，既是真实的生产级反向代理网站，又无缝提供经认证的 CONNECT 代理服务。 |
| sing-box | 核心内核 | 全平台 (Linux / Android / iOS / macOS / Windows) | 完整原生支持 | v1.6.0 | 2023.09.20 | SagerNet 团队原生接入 NaïveProxy 出站协议，提供标准路由分流、DNS 防污染和图形界面集成。 |
| Shadowrocket | 客户端 | iOS / iPadOS | 出站客户端支持 | v2.1.80 | 2021.05.10 | iOS 知名代理工具支持直接导入 NaïveProxy 节点，提供移动端后台低功耗常驻运行。 |
| v2rayN | 客户端 | Windows | 出站客户端支持 | v5.30 | 2022.06.18 | 通过外置 naiveproxy 官方二进制或内置 sing-box 核心，提供便捷的 GUI 配置与系统代理自动接管。 |
| NekoBox for Android | 客户端 | Android | 出站客户端支持 | v1.1.8 | 2023.04.15 | 基于 sing-box 核心构建，支持通过 VPNService 接管 Android 手机系统全局或分应用网络请求。 |
适用场景与网络边界限制
05最推荐使用场景：
- 敏感时期或重点审查网络：在大型会议、重大敏感节点或企业严格 DPI 监控网络下，NaïveProxy 具备最高的生存率。
- 纯 TCP / 禁用 UDP 的局域网：在高校校园网、公司局域网封锁 UDP 的环境下，NaïveProxy 基于标准 HTTPS 443 端口通行无阻。
- 重视连接长期稳定性与隐匿性：一个部署良好的 NaïveProxy 节点往往可以持续稳定运行数年而无需更换 IP。
不适用或受限场景：
- 极高丢包率且无国内优化的恶劣线路：在 20% 以上丢包的普通公网线路上，TCP 的拥塞控制会受到明显影响，此时 Hysteria 2 体验更好。
- 零门槛新手部署：必须自备合法域名并解析到 VPS，配置 Caddy 及相关模块有一定技术门槛。
- 极低内存设备：早期未经裁剪的 Chromium 二进制体积较大，在 64MB 内存的老旧路由器上运行较为吃力。
安全假设、证书依赖与局限性
061. 必须使用权威机构签发的有效证书：NaïveProxy 客户端内部严格遵循 Chromium 的安全策略， 默认开启完整的证书信任链校验与 OCSP 验证，绝对不允许使用自签证书或不受信任的证书，必须由 Let's Encrypt 或 ZeroSSL 签名。
2. 服务端必须具备真实伪装页面：Caddy 应当配置一个真实存在的正常站点（如静态博客或展示页），当审查系统直接向服务器发起 HTTP GET 探测时， 应当能返回标准 HTTP 200 的网页内容，不可返回空页面或异常错误。
3. 客户端实现完整性：若使用第三方客户端（如某些仅实现了 HTTP/2 CONNECT 却使用了 Go 语言标准 net/http 库的工具）， 其 TLS 指纹与 H2 帧序列将不再是 Chromium 真实特征，抗审查效果会大打折扣；建议务必确认客户端底层使用了真实的 Cronet 或通过验证的指纹库。
文献引注与第一手资料出处
07百科词条中所有架构数据、算法定义及发布时间均以官方公开发行物为基准：
包含 klzgrad 发布的各版本源码、二进制构建产物与详细的抗审查安全声明。
https://github.com/klzgrad/naiveproxyNaïveProxy 隧道传输所依赖的 HTTP/2 标准规范，重点包括第 8.5 节的 CONNECT 方法与多路复用流机制。
https://datatracker.ietf.org/doc/html/rfc9113NaïveProxy 官方推荐部署的现代 Web 服务器，支持自动申请管理权威 TLS 证书与承载未授权流量。
https://caddyserver.comNaïveProxy 客户端底层提取的核心网络库，提供绝对真实的 JA3/JA4 指纹及 H2 帧特征。
https://chromium.googlesource.com/chromium/src/+/main/net/开源跨平台通用代理核心中 NaïveProxy 协议的具体配置参数与使用说明。
https://sing-box.sagernet.org/configuration/outbound/naive/