NaiveProxy
NaiveProxy 是一种于 2019 年发布的代理工具与协议,由开发者 @klzgrad 创建。其核心设计思路极为独特:直接复用 Chromium 浏览器的网络栈来处理代理流量,使得代理流量的 TLS 指纹、HTTP 行为和连接特征与真实的 Chrome 浏览器访问完全一致,从根本上解决了流量特征识别问题。
设计理念
大多数代理协议在实现 TLS 时,使用的是各自独立的 TLS 库(如 OpenSSL、BoringSSL、Go 的 crypto/tls 等)。尽管这些实现都遵循 TLS 标准,但它们的 TLS Client Hello 指纹(包括密码套件顺序、扩展列表、椭圆曲线偏好等)与真实浏览器存在可测量的差异。
流量检测系统可以通过采集大量 TLS 握手样本,建立"正常浏览器"与"代理工具"的特征库,然后对入站流量进行分类。即使流量本身被加密,握手阶段的元数据也足以暴露代理行为。
NaiveProxy 的解决方案是:不去模拟浏览器的 TLS 行为,而是直接使用浏览器的代码。
传统代理工具:
自定义 TLS 实现 → TLS 指纹与浏览器不同 → 可被识别
NaiveProxy:
直接使用 Chromium 网络栈 → TLS 指纹与 Chrome 完全一致 → 无法通过指纹区分
这一设计的本质是:只要检测系统无法在不影响真实 Chrome 用户的前提下封锁 NaiveProxy,NaiveProxy 就是安全的。
核心技术
Chromium 网络栈复用
NaiveProxy 的客户端内嵌了 Chromium 的 net/ 模块,这是 Chrome 浏览器中负责所有网络请求的底层组件。通过直接调用这个模块发出连接请求,NaiveProxy 客户端产生的 TLS 流量在以下所有维度上与 Chrome 完全相同:
- TLS Client Hello 中的密码套件列表及顺序
- TLS 扩展的类型和顺序
- 椭圆曲线组的偏好设置
- ALPN(应用层协议协商)声明
- TLS 版本偏好
- 签名算法列表
这些细节的组合构成了 TLS 指纹,而 NaiveProxy 在这个维度上与 Chrome 完全无法区分。
HTTP/2 或 HTTP/3 代理协议
NaiveProxy 在 Chromium 网络栈的基础上,使用标准的 HTTP CONNECT 方法建立代理隧道,并通过 HTTP/2 或 HTTP/3 传输:
客户端(Chromium 网络栈)
|
| HTTPS CONNECT 请求(通过 HTTP/2 或 HTTP/3)
| Host: your.domain.com
| Proxy-Authorization: Basic [认证信息]
v
代理服务端(通常是 Caddy + forward_proxy 模块)
|
| 验证认证信息
| 建立到目标的连接
v
目标服务器
对外界观察者而言,这个连接看起来就是一个普通的 Chrome 浏览器通过 HTTPS 访问你的服务器——无论是 TLS 握手、HTTP 行为还是连接生命周期,都与正常浏览器流量一致。
服务端使用 Caddy + forwardproxy
NaiveProxy 的服务端通常基于 Caddy Web 服务器,配合 forwardproxy 插件(需要使用 klzgrad 维护的特定分支)实现。Caddy 本身是一个功能完善的 Web 服务器,因此 NaiveProxy 服务端天然地同时提供真实的 Web 服务,这与 Trojan 的回落机制有异曲同工之处:
- 连接携带正确凭证 → 作为正向代理处理
- 连接不携带凭证或凭证错误 → 作为普通 HTTPS 网站响应
防止主动探测
由于服务端对外表现为标准的 HTTPS + Caddy 组合,主动探测者只会得到一个正常的 HTTPS 网站响应,无法确认代理服务的存在。
与其他协议的对比
| 对比维度 | NaiveProxy | Trojan | VLESS + Reality | AnyTLS |
|---|---|---|---|---|
| TLS 指纹 | 与 Chrome 完全一致 | 依赖实现(可定制) | 可通过 uTLS 定制 | 可通过 uTLS 定制 |
| 是否复用真实浏览器代码 | 是(Chromium) | 否 | 否 | 否 |
| 需要域名 | 是 | 是 | 否 | 是 |
| 需要 TLS 证书 | 是 | 是 | 否 | 是 |
| 服务端软件 | Caddy(特定构建) | Xray / sing-box | Xray / sing-box | sing-box |
| HTTP/2 / HTTP/3 代理 | 是 | 否 | 否 | 否 |
| 客户端体积 | 较大(含 Chromium 网络栈) | 较小 | 较小 | 较小 |
| 客户端支持广度 | 有限(主要是 NaiveProxy 原版) | 广泛 | 广泛 | 新兴 |
| 部署复杂度 | 中(需要特殊构建的 Caddy) | 中 | 中 | 中 |
优缺点
| 优点 | 缺点 |
|---|---|
| TLS 指纹与真实 Chrome 完全一致,无法通过指纹区分 | 客户端体积较大(包含 Chromium 网络栈) |
| 流量行为模式符合真实浏览器特征 | 服务端需要特殊构建的 Caddy,部署略繁琐 |
| 天然提供真实 Web 服务,对抗主动探测 | 客户端支持范围较窄,仅部分代理软件支持 |
| 使用标准 HTTP CONNECT 协议,协议设计简洁 | 需要域名和有效 TLS 证书 |
| 对抗 TLS 指纹检测的能力是目前最强之一 | 依赖 Chromium 代码库,客户端更新需要跟随 Chrome 版本 |
| 支持 HTTP/2 多路复用,连接效率高 | 社区规模和文档资源不如主流协议丰富 |
适用场景
推荐使用 NaiveProxy 的场景:
- 对 TLS 指纹检测有高度顾虑的用户
- 需要在指纹级别与真实浏览器流量无法区分的场景
- 已有域名和证书,且愿意维护特殊构建的 Caddy
- 作为多协议方案中针对 TLS 指纹检测的专用选项
- 对代理工具的技术深度有探索兴趣
不推荐单独依赖 NaiveProxy 的场景:
- 需要广泛的多端客户端支持(不同设备使用同一节点)
- 使用 iOS 主流客户端(Shadowrocket、QX 等大多不支持)
- 对部署复杂度敏感,希望使用简单的一键脚本
- 没有域名或不想管理 TLS 证书(考虑 VLESS + Reality)
- 需要在高丢包线路上稳定使用(考虑 Hysteria 2 或 TUIC)
服务端部署参考
NaiveProxy 的服务端基于一个包含 forwardproxy 插件的特殊 Caddy 构建,由 @klzgrad 在 GitHub 维护。
前置条件
- 一台公网 VPS,已开放 TCP 443 端口
- 一个指向服务器 IP 的域名,已完成 DNS 解析
- 服务器 80 端口可访问(用于 TLS 证书申请的 HTTP 验证)
下载带 forwardproxy 插件的 Caddy
NaiveProxy 的服务端需要使用 klzgrad 维护的特殊 Caddy 分支,该分支包含了经过修改的 forwardproxy 插件:
# 从 GitHub Releases 下载预编译的 naive Caddy 服务端
# 访问 https://github.com/klzgrad/naiveproxy/releases 获取最新版本
wget https://github.com/klzgrad/naiveproxy/releases/latest/download/naiveproxy-plugin-linux-amd64.tar.xz
tar -xJf naiveproxy-plugin-linux-amd64.tar.xz
解压后会得到两个文件:
caddy:修改后的 Caddy 服务端(包含 forwardproxy 插件)naive:NaiveProxy 客户端(用于本地测试)
chmod +x caddy
mv caddy /usr/local/bin/caddy-naive
创建 Caddy 配置文件(Caddyfile)
your.domain.com {
route {
forward_proxy {
basic_auth your_username your_password
hide_ip
hide_via
probe_resistance secret_token
}
reverse_proxy https://www.example.com {
header_up Host {upstream_hostport}
}
}
}
配置字段说明:
| 字段 | 说明 |
|---|---|
basic_auth | 代理的用户名和密码,客户端连接时需提供 |
hide_ip | 隐藏客户端真实 IP,不在转发请求中添加 X-Forwarded-For |
hide_via | 隐藏 Via 头部,防止暴露代理的存在 |
probe_resistance | 探测防护令牌,不知道此令牌的请求将被当作普通 Web 访问处理 |
reverse_proxy | 回落目标,非代理请求将被代理到此 URL(设置为一个真实的网站) |
关于 probe_resistance
probe_resistance 后面跟的是一个你自定义的秘密令牌。只有在请求中携带这个令牌的情况下,服务端才会表现为代理;否则一律作为普通 HTTPS 网站响应。这个令牌不需要在普通使用中手动携带——它只是服务端的一个内部校验机制,防止无凭证的主动探测发现代理服务的存在。
Caddy 配置(JSON 格式,适合程序化管理)
如果你更倾向于 JSON 格式的配置:
{
"apps": {
"http": {
"servers": {
"naive": {
"listen": [":443"],
"routes": [
{
"handle": [
{
"handler": "forward_proxy",
"auth_user_deprecated": "your_username",
"auth_pass_deprecated": "your_password",
"hide_ip": true,
"hide_via": true,
"probe_resistance": {
"domain": "secret.your.domain.com"
}
}
]
},
{
"handle": [
{
"handler": "reverse_proxy",
"upstreams": [
{
"dial": "www.example.com:443"
}
]
}
]
}
],
"tls_connection_policies": [
{
"certificate_selection": {
"any_tag": ["cert0"]
}
}
]
}
}
},
"tls": {
"automation": {
"policies": [
{
"subjects": ["your.domain.com"],
"issuers": [
{
"module": "acme"
}
]
}
]
}
}
}
}
Systemd 服务单元
[Unit]
Description=NaiveProxy Caddy Server
After=network.target
[Service]
Type=simple
User=caddy
Group=caddy
ExecStart=/usr/local/bin/caddy-naive run --config /etc/caddy/Caddyfile
ExecReload=/usr/local/bin/caddy-naive reload --config /etc/caddy/Caddyfile
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
启动服务
# 创建 Caddy 运行用户(可选,提升安全性)
useradd -r -s /bin/false caddy
# 创建配置目录
mkdir -p /etc/caddy
# 将 Caddyfile 放入配置目录
cp Caddyfile /etc/caddy/
# 启动服务
systemctl daemon-reload
systemctl enable caddy-naive
systemctl start caddy-naive
systemctl status caddy-naive
# 查看日志
journalctl -u caddy-naive -f
Caddy 会自动通过 ACME 协议向 Let's Encrypt 申请并续期 TLS 证书,无需手动操作。
开放防火墙规则
ufw allow 80/tcp # HTTP,用于 ACME 证书申请验证
ufw allow 443/tcp # HTTPS
客户端使用
下载 NaiveProxy 客户端
从 GitHub Releases 下载对应系统的 NaiveProxy 客户端:
# https://github.com/klzgrad/naiveproxy/releases
# 选择对应系统架构的版本,如 naiveproxy-v*-linux-amd64.tar.xz
wget https://github.com/klzgrad/naiveproxy/releases/latest/download/naiveproxy-v127.x-linux-amd64.tar.xz
tar -xJf naiveproxy-*.tar.xz
chmod +x naive
mv naive /usr/local/bin/naive
客户端配置文件(config.json)
{
"listen": "socks://127.0.0.1:1080",
"proxy": "https://your_username:your_password@your.domain.com"
}
或者使用 HTTP 代理监听:
{
"listen": "http://127.0.0.1:8080",
"proxy": "https://your_username:your_password@your.domain.com"
}
配置字段说明:
| 字段 | 说明 |
|---|---|
listen | 本地代理监听地址,支持 socks:// 和 http:// |
proxy | 远端代理服务器地址,格式为 https://用户名:密码@域名 |
如果服务端启用了 quic(HTTP/3),可以将协议改为 quic://:
{
"listen": "socks://127.0.0.1:1080",
"proxy": "quic://your_username:your_password@your.domain.com"
}
启动客户端
naive --config=/path/to/config.json
在第三方客户端中配置
部分代理软件(如 sing-box)支持通过 HTTP/HTTPS 代理方式连接 NaiveProxy,配置如下:
sing-box 配置(以 HTTP 代理形式连接):
{
"type": "http",
"tag": "naive-node",
"server": "your.domain.com",
"server_port": 443,
"username": "your_username",
"password": "your_password",
"tls": {
"enabled": true,
"server_name": "your.domain.com"
}
}
关于第三方客户端的 TLS 指纹
如果通过 sing-box 或 Mihomo 等客户端连接 NaiveProxy 服务端,这些客户端不会使用 Chromium 的网络栈,而是使用各自的 TLS 实现。这意味着 NaiveProxy 最核心的 TLS 指纹优势会丧失。如果你希望保留这一优势,应使用原版 NaiveProxy 客户端,而不是通过第三方客户端中转。
与 Caddy 原版的区别
NaiveProxy 使用的 Caddy 是 klzgrad 维护的特殊分支,而非 Caddy 官方版本。主要区别在于:
| 特性 | Caddy 官方版 | NaiveProxy 的 Caddy |
|---|---|---|
forwardproxy 插件 | 可以通过 xcaddy 安装,但行为有差异 | 内置修改版,针对 NaiveProxy 优化 |
probe_resistance 功能 | 部分支持 | 完整支持 |
| HTTP/2 代理行为 | 标准 | 经过优化以配合 NaiveProxy 客户端 |
不要用 Caddy 官方版 + 社区 forwardproxy 插件替代 NaiveProxy 的 Caddy,两者的 forwardproxy 行为存在差异,可能导致连接失败或丧失伪装效果。
客户端支持
NaiveProxy 目前的客户端支持相对有限,这是使用它的主要门槛之一:
| 平台 | 客户端 | 支持状态 | 备注 |
|---|---|---|---|
| Windows / macOS / Linux | NaiveProxy 原版客户端 | 支持 | 完整支持,保留 Chromium 指纹优势 |
| Windows / macOS / Linux | sing-box | 支持(HTTP 代理方式) | 无 Chromium 指纹,仅协议兼容 |
| iOS | Shadowrocket | 不支持 | — |
| iOS | Quantumult X | 不支持 | — |
| iOS | Stash | 支持 | 通过 HTTP 代理方式 |
| iOS | Surge | 不支持(原生) | — |
| Android | NekoBox | 支持 | 通过 sing-box 集成 |
| Android | Husi | 支持 | sing-box 内核 |
| Linux | dae | 不支持 | — |
关于 iOS 平台
NaiveProxy 在 iOS 平台的原生支持十分有限。如果你的主力设备是 iPhone,NaiveProxy 可能不是最合适的选择。建议在 iOS 上使用 VLESS + Reality 或 Hysteria 2 等支持更广泛的协议。
常见问题
Q:NaiveProxy 和 Trojan 都用了 TLS,有什么区别?
核心区别在于 TLS 指纹的来源:
- Trojan 通常使用 Go 的
crypto/tls或其他 TLS 库,TLS 指纹与真实浏览器不同(尽管可以通过 uTLS 进行模拟) - NaiveProxy 直接使用 Chromium 的
net/模块,TLS 指纹来自真实的 Chrome 代码,无法通过指纹区分
Q:为什么 NaiveProxy 的客户端体积这么大?
因为它内嵌了 Chromium 的网络栈(net/ 模块)。这部分代码是 Chrome 浏览器的核心网络组件,体积本身就比较大。这是为了获得真实 Chrome TLS 指纹所必须付出的代价。
Q:服务端能同时提供正常的网站服务吗?
可以,而且这是推荐的配置。NaiveProxy 的 Caddy 服务端本身就是一个功能完善的 Web 服务器,你可以在同一个配置文件中配置网站内容。非代理请求会正常响应 Web 内容,代理请求则通过 forwardproxy 插件处理。
Q:可以在没有域名的情况下使用 NaiveProxy 吗?
技术上可以使用 IP + 自签名证书,但需要在客户端跳过证书验证,这会破坏 TLS 的安全性,也会使流量特征异常(真实浏览器不会信任自签名证书的站点)。实际上,没有域名时应改用 VLESS + Reality。
Q:NaiveProxy 支持 UDP 代理吗?
不支持。NaiveProxy 基于 HTTP CONNECT 协议,只支持 TCP 流量代理。对于需要 UDP 代理的场景(如 DNS、游戏),需要配合其他工具或选用支持 UDP 的协议(如 Hysteria 2、TUIC)。
延伸阅读
- AnyTLS 协议 — 同样关注流量伪装的新型协议,客户端支持更广泛
- VLESS 协议 — 无需域名的 Reality 方案,综合实用性更高
- Trojan 协议 — 同样基于 TLS,但部署和客户端支持更简便
- 代理协议总览 — 回到协议总览页面
- NaiveProxy 官方仓库:github.com/klzgrad/naiveproxy