NaiveProxy：基于 Chromium 的 VLESS 安全替代方案
在激烈的封锁行动中，NaiveProxy 协议提供了一种独特的流量伪装方法——利用 Chromium 的原生网络栈。我们将逐步介绍使用 sing-box 和 Caddy 设置客户端和服务器的过程，避免常见陷阱。
流量伪装基础：为什么 NaiveProxy 优于 uTLS？
标准代理协议会伪装成 HTTPS 流量，但初始的 ClientHello 数据包仍然容易暴露。它以明文发送 TLS 版本、密码套件列表和域名。基于 Go 的实现（包括 Xray 和 sing-box）具有该语言特有的 ClientHello 指纹，即使使用 uTLS 也能被识别。uTLS 库仅模拟浏览器在第一个数据包的行为，无法复制网络栈的细微差别，如数据传输节奏、帧长度和 HTTP/2 的特性。NaiveProxy 通过嵌入 Chromium 片段，直接实现像素级完美的浏览器流量仿真。
NaiveProxy 架构：从 Chromium 到代理
协议的作者 klzgrad 将 Chromium 源代码精简至仅 0.3% 的功能，仅保留网络所需部分。主要特性：
- 使用 Chromium 原生 HTTP/2 栈实现多路复用
- ClientHello 及后续数据包与真实浏览器流量完美匹配
- 摒弃自定义密码套件，转用标准 TLS 机制
重要提示：它与标准 HTTP/2 代理在双向完全兼容。Naive 客户端可连接任意 HTTP/2 代理，Naive 服务器也接受标准客户端连接。但真正伪装仅在 Chromium 网络栈（如 sing-box）中实现。其他客户端（如基于 Go 的）虽可连接 Naive 服务器，但无法提供完全匿名性。
填充：三层防护对抗流量分析
协议采用多级填充来阻挡数据包长度分析：
- DATA 帧：每个流的前 8 个帧添加头部（2 字节数据长度 + 1 字节填充长度），后接原始数据和填充字节。
- CONNECT 请求：随机长度头部任意增大帧大小。
- END_STREAM：在每个 RST_STREAM 前添加额外帧。
测试发现 sing-box 的关键缺陷：添加填充时未清零缓冲区，而是发送了先前请求的残留数据。这泄露了敏感信息（如域名和头部）。在合并两个强制清零缓冲区的 PR 后，1.13.1+ 版本已修复。
客户端设置：sing-box 出站
需要 sing-box 1.13+。客户端配置：
{
"type": "naive",
"tag": "Proxy1",
"server": "1.2.3.4",
"server_port": 443,
"username": "username",
"password": "password",
"insecure_concurrency": 1,
"udp_over_tcp": {
"enabled": true
},
"quic": false,
"tls": {
"enabled": true,
"server_name": "s1.example.com"
}
}关键参数：
insecure_concurrency：保持为 1。较高值会使流量更容易被分析。udp_over_tcp：启用以支持 UDP。server_name：Caddy 中设置的域名。必须与 TLS 部分的 server_name 匹配。
Caddy 作为 TLS 终结器：配置与后备
Caddy 处理 TLS 连接，并将流量路由至代理或诱饵站点。配置（/etc/caddy/Caddyfile）：
{
email [email protected]
auto_https disable_redirects
}
:443, https://s1.example.com {
tls {
issuer acme {
disable_http_challenge
}
}
route {
@naive {
method CONNECT
header Proxy-Authorization "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
}
handle @naive {
reverse_proxy h2c://127.0.0.1:1080 {
header_up Proxy-Authorization {header.Proxy-Authorization}
}
}
handle {
root * /srv/naive-fallback
file_server
}
}
}关键点：
Proxy-Authorization头部承载 base64 编码的username:password（使用echo -n "username:password" | base64生成）。/srv/naive-fallback目录提供静态诱饵站点，抵御扫描。auto_https disable_redirects跳过 HTTP→HTTPS 重定向，因为 443 端口仅 HTTPS。
服务端：sing-box 入站与 Caddy 集成
服务端 sing-box 配置（/etc/sing-box/config.json）：
{
"log": {
"level": "warn",
"output": "/var/log/sing-box/sing-box.log"
},
"inbounds": [
{
"type": "naive",
"tag": "naive-in",
"network": "tcp",
"listen": "127.0.0.1",
"listen_port": 1080,
"users": [
{
"username": "username",
"password": "password"
}
]
}
],
"outbounds": [
{
"type": "direct"
}
]
}重要提示：
- 服务端仅监听 localhost:1080，由 Caddy 处理外部连接。
warn日志级别最小化磁盘 I/O。- 密码必须与客户端和 Caddy 设置完全匹配。
关键要点
- 完全伪装需 Chromium 栈：仅使用原生网络代码的实现（如 sing-box）才能完美匹配浏览器流量。
- 并发 = 风险：
insecure_concurrency超过 1 会增加数据包长度分析漏洞。 - 保持组件更新：使用 sing-box 1.13.1+ 修复填充数据泄露。
- 诱饵站点必不可少：Caddy 中的静态站点隐藏代理免受扫描。
- 现实并非万无一失：如 Reality 的历史所示，即使巧妙的方案也可能因新指纹（如连接数）被封锁。
— Editorial Team
暂无评论。