OVEROUTESOVEROUTES
首页
阅读须知
  • 总览
  • 选购要点
  • 推荐机场
  • 客户端使用
  • 概述
  • IP 与线路
  • 选型指南
  • 选购参考
  • 基础部署
  • 安全加固
  • 概述
  • 3X-UI
  • Xboard
  • 协议总览
  • Shadowsocks
  • Shadowsocks 2022
  • VMess
  • Trojan
  • VLESS
  • Hysteria 2
  • TUIC
  • AnyTLS
  • NaiveProxy
  • Mieru
  • ShadowTLS
  • VLESS-XHTTP
  • WireGuard
  • 传统协议
  • 孤家寡人协议
  • 软件总览
  • Mihomo
  • sing-box
  • Xray
  • V2Fly
  • dae (Linux)
  • Shadowrocket (iOS)
  • QuantumultX (iOS)
  • Stash (iOS/macOS)
  • Loon (iOS)
  • Surge (macOS/iOS)
  • NekoBox (Android)
  • Husi (Android)
  • Exclave (Android)
配置
首页
阅读须知
  • 总览
  • 选购要点
  • 推荐机场
  • 客户端使用
  • 概述
  • IP 与线路
  • 选型指南
  • 选购参考
  • 基础部署
  • 安全加固
  • 概述
  • 3X-UI
  • Xboard
  • 协议总览
  • Shadowsocks
  • Shadowsocks 2022
  • VMess
  • Trojan
  • VLESS
  • Hysteria 2
  • TUIC
  • AnyTLS
  • NaiveProxy
  • Mieru
  • ShadowTLS
  • VLESS-XHTTP
  • WireGuard
  • 传统协议
  • 孤家寡人协议
  • 软件总览
  • Mihomo
  • sing-box
  • Xray
  • V2Fly
  • dae (Linux)
  • Shadowrocket (iOS)
  • QuantumultX (iOS)
  • Stash (iOS/macOS)
  • Loon (iOS)
  • Surge (macOS/iOS)
  • NekoBox (Android)
  • Husi (Android)
  • Exclave (Android)
配置
  • 主流序列

    • 代理协议总览
    • Shadowsocks
    • Shadowsocks 2022
    • VMess
    • Trojan
    • VLESS
    • Hysteria 2
  • 新生序列

    • TUIC
    • AnyTLS
    • ShadowQUIC
    • VLESS-Encryption
    • Sudoku
  • 小众序列

    • NaiveProxy
    • Mieru
    • SS-ShadowTLS
    • VLESS-XHTTP
    • Juicity
  • 传统与其他

    • WireGuard
    • 传统协议
    • 孤家寡人协议

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 网站响应,无法确认代理服务的存在。

与其他协议的对比

对比维度NaiveProxyTrojanVLESS + RealityAnyTLS
TLS 指纹与 Chrome 完全一致依赖实现(可定制)可通过 uTLS 定制可通过 uTLS 定制
是否复用真实浏览器代码是(Chromium)否否否
需要域名是是否是
需要 TLS 证书是是否是
服务端软件Caddy(特定构建)Xray / sing-boxXray / sing-boxsing-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 / LinuxNaiveProxy 原版客户端支持完整支持,保留 Chromium 指纹优势
Windows / macOS / Linuxsing-box支持(HTTP 代理方式)无 Chromium 指纹,仅协议兼容
iOSShadowrocket不支持—
iOSQuantumult X不支持—
iOSStash支持通过 HTTP 代理方式
iOSSurge不支持(原生)—
AndroidNekoBox支持通过 sing-box 集成
AndroidHusi支持sing-box 内核
Linuxdae不支持—

关于 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
最近更新: 2026/4/9 14:18
Next
Mieru