插画来自画师厕所董事长

NaïveProxy 是什么？

我们来看官方的解释：

NaïveProxy使用Chrome的网络堆栈来伪装流量，具有很强的抗审查能力和低可探测性。重用Chrome的堆栈也确保了性能和安全方面的最佳实践。

NaïveProxy可以缓解以下几种流量攻击：

• 通过HTTP/2中的流量复用缓解指纹识别/流量分类
• 通过重复使用Chrome的网络堆栈缓解对于TLS参数指纹识别
• 通过「应用前置」，将代理服务器隐藏在一个常用的前端（Caddy）与应用层路由后面）来防御主动探测
• 通过填充长度缓解基于长度的流量分析。

以上特性使得 NaïveProxy 难以被识别。自 19 年诞生以来，在过去 6 年中，还未有过明确报告其能被 gfw 针对检测的案例，足以证明该协议的伪装性较强。

当然，要发挥最强的伪装性，规范的配置与使用习惯缺一不可，遵循木桶效应，整体的安全性往往取决于配置中最薄弱的一环。
请谨记，NaïveProxy 的目的是将代理流量混入正常流量中，在配置时要尽可能的和真实网页浏览流量对齐。在下文中我也会提到一些细节上的建议供参考。

开始之前

您必须先拥有以下资源：

1. 一台拥有国外公网 IP 的主机（建议 v4/v6 双栈；单栈环境需确保客户端协议匹配）
2. 一个域名

为了最佳效果，推荐同时满足：

1. 主机的 80 和 443 端口需要开放给 NaïveProxy 服务端使用。使用其他端口会使流量变得更加可疑，并增加被 gfw 的封禁几率，且在申请证书时需要额外配置。
2. 避免使用.cn顶级域，因为其包含实名注册信息。
3. 建议使用.com、.net、.org等常见顶级域，虽然没有研究表明 gfw 会对不同顶级域采用不同的监管手段，但是一些非主流的顶级域名可能会被学校或组织的防火墙阻止。

NaïveProxy 另一个没有被 gfw 针对的原因在于其配置难度之高，较高的技术门槛限制了其流行度。本文篇幅较长，因此，请您带上一点点耐心，让我们一起开始配置～

服务端配置

首先，将服务器的公网 IP 解析到您的域名上。

编译带有 Forward proxy 插件的 Caddy 服务器。

$ go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
$ ~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy@caddy2=github.com/klzgrad/forwardproxy@naive
$ sudo setcap cap_net_bind_service=+ep ./caddy

对于使用 OpenWrt 的嵌入式设备，可能需要使用交叉编译，我编译了适用于 aarch64 架构的二进制，请在这个仓库获取编译好的二进制或是进行云编译。

将编译好的二进制重命名并移动到/usr/bin/caddy-naive

创建一个目录用于存放 Caddy 配置，创建 Caddyfile：

mkdir -p /etc/caddy/
mkdir -p /etc/caddy/data
touch /etc/caddy/Caddyfile

编写 Caddyfile，并填入以下配置：

{
    order forward_proxy before file_server
    # 替换为你的真实邮箱，用于申请Let's Encrypt证书
    email user@example.com
    storage file_system /etc/caddy/data
    # 性能优化，防止Slowloris攻击
    admin off
    servers {
        max_header_size 16kb
        timeouts {
            read_header 10s
            read_body   10s
        }
    }
}

# 将80端口的HTTP请求全部升级到HTTPS
:80 {
    # 把example.com替换为你的真实网址
    redir https://example.com{uri} 308
}

# 处理来自443端口的连接，这是服务的主要入口
# 把example.com替换为你的真实网址
:443, example.com {
    route {
        # NaiveProxy 核心配置
        forward_proxy {
            # 设置代理用户名和密码，这里是支持多用户的
            basic_auth user1 password1
            basic_auth user2 password2

            hide_ip
            hide_via
            probe_resistance
        }

        # /var/www/my_site为存放伪装网站的路径
        root * /var/www/my_site
        file_server
    }

    handle_errors {
        @notfound expression {http.error.status_code} == 404
        rewrite @notfound /404.html
        file_server
    }
}

请根据注释提示填入您的配置。

对于伪装网站，上述配置中使用的是本地file_server，您也可以考虑反代其他网站，请自行权衡。如果您也使用本地file_server，建议做一个看着不假的网站，越像真的越好。虽然 gfw 并非人工审核，但凡事要做就做全嘛，一个有大量流量出入的服务器只有一个空白的 index.html 或者全 404 只会让您的端点显得更可疑。不要主动让出最短版。

对于密码设置，您可以用如下 bash 命令快速生成 64 位，符合 URL 标准的强密码：

n=64; (command -v openssl >/dev/null && openssl rand -base64 $((n*2)) | tr '+/' '-_' | tr -d '=\n' | head -c "$n" || LC_ALL=C tr -dc 'A-Za-z0-9-_' </dev/urandom | head -c "$n"); echo

完成后，使用如下命令尝试运行：

caddy-naive run --adapter caddyfile --config /etc/caddy/Caddyfile

Caddy 会自动为配置的域名申请证书，完成后，使用浏览器直接访问您的域名，应该能成功联通，并看到伪装网站。

设置守护进程

您可以考虑使该 Caddy 服务器自动启动并在后台运行，以下是 Openwrt 上用 procd 的实现方式，不同平台会有差异（在 Ubuntu 上可以使用 Systemd）。

创建/etc/init.d/caddy-naive并填入以下内容：

#!/bin/sh /etc/rc.common
USE_PROCD=1
START=99
STOP=10

BIN="/usr/bin/caddy-naive"
CONF="/etc/caddy/Caddyfile"

start_service() {
  procd_open_instance
  procd_set_param command "$BIN" run --adapter caddyfile --config "$CONF"
  procd_set_param respawn 3600 5 5
  procd_set_param stdout 1
  procd_set_param stderr 1
  procd_set_param limits nofile=1048576
  procd_close_instance
}

设置开机自启并立即启动服务：

/etc/init.d/caddy-naive enable
/etc/init.d/caddy-naive start

使用以下命令来查看状态／停止／重启

/etc/init.d/caddy-naive status
/etc/init.d/caddy-naive stop
/etc/init.d/caddy-naive restart

提示

之后每次更改 Caddyfile 后，都要重启一次守护进程以使 Caddy 读取新的配置。

客户端配置

官方客户端

NaïveProxy 官方在 release 中提供了 cli 客户端，支持 Linux／macOS／Windows／OpenWrt 等常见系统。额外还提供安卓插件，详见下文 NekoBox 段落

下载并解压，在./naive的同级目录下写入如下配置到config.json：

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "https://<username>:<password>@example.com"
}

启动后，Naïve 会在本地监听 1080 端口的 SOCKS 代理请求。

使用 curl 进行测试：

curl --socks5-hostname 127.0.0.1:1080 https://google.com

接下来就可以设置系统或浏览器代理到127.0.0.1:1080，并正常使用了。

但是这样无法代理一些不听系统代理的应用。我更偏向像传统 VPN 一样接管整个系统流量的用法，所以接下来要请出我们的 SingBox。

GUI.for.SingBox

这是一个专为桌面端（Linux／macOS／Windows）打造的代理程序，使用 SingBox 内核，支持 TUN 模式（也就是通过虚拟网卡接管全局流量）。

首先，从 release 中下载 GUI.for.SingBox。

SingBox 内核自1.13.0-alpha.28起才支持 Naïve 协议，我们需要使用 alpha 版本的内核。

打开 GUI.for.SingBox，设置 → 内核 → 选择更新 alpha 内核 → 切换版本至 alpha 内测版内核：

接下来，我们要创建节点信息，节点信息会保存在 GUI.for.SingBox 可执行文件下的./data/subscribes中，在 macOS 下，这个路径是~/Library/Application Support/GUI.for.SingBox/subscribes。

在该路径下新建一个 json 文件存储节点信息，本示例中我将其命名为my_naive.json，填入以下配置：

[
  {
    "type": "naive",
    "tag": "my_naive",
    "server": "example.com",
    "server_port": 443,
    "username": "username",
    "password": "password",
    "tls": {
      "enabled": true,
      "server_name": "example.com"
    }
  }
]

在server和server_name中填入您的服务器域名，在username和password中分别填入您的账号密码，tag字段是这个节点的标签，您可以选择一个您喜欢的填入。

在 GUI 中导航到订阅 → 添加，在弹窗中选择手动管理，并填入保存的 json 的路径：

保存后点击「更新」或「更新全部」让 GUI.for.SingBox 读取一次配置。

接下来需要在 GUI 中创建一个连接配置，导航到配置，选择添加，在弹出的窗口中进行操作。

我这里会按照最简单的全局代理进行配置，我建议您在初次配置时也这么做，待成功配置全局代理后再优化连接规则。

在通用设置中将工作模式改为全局：

在入站设置中添加一个tun-in的入站模式并启用，将TUN模式堆栈改为Mixed，启用自动设置全局路由和严格路由：

在出站设置中，系统提供了一些预设分类，鉴于我们只有一个节点，我建议直接进行如下设置：

将您的 Naïve 节点加入：节点选择、自动选择、漏网之鱼和GLOBAL。

在路由设置中，选择Local-DNS作为解析节点域名的DNS服务器，默认出站标签选择漏网之鱼：

至于规则集和规则使用默认配置即可，无须修改，只需要确保规则里拥有并启用了以下四条：

在 DNS 设置中，我这里使用的是双栈服务器，所以解析策略使用了IPV6优先，请根据你的网络环境进行选择。同时为了防止 DNS 泄露，将回退DNS 设置为 Remote-DNS，且因我们本来就要全局代理，所以一并在规则中关闭 clash_mode,direct,route,Local-DNS：

至此，我们完成了该客户端的配置。回到概览，选择刚才的配置，启动内核。您系统中所有的 TCP 流量都应被代理。

NekoBox

NekoBox是一个专为安卓端打造的代理程序，通过插件提供对 NaïveProxy 协议的支持，也同时支持接管所有流量的 TUN 模式。

首先，从 release 中下载最新的 NekoBox 客户端并安装。

从 NaïveProxy 官方 release 中下载插件 apk 并安装。

打开 NekoBox，在主页右上角选择添加 → 手动输入 → Naïve，填写服务器配置后保存。

在 NekoBox 设置中可以修改运行模式和 TUN 实现。要使其接管全局流量，设置运行模式为 VPN ，TUN 实现为Mixed。

然后直接启动就可以了！NekoBox 配置真是轻松，赞美伟大的猫猫！

您可能会注意到配置中有一个 UDP over TCP 的选项，该选项对 Naïve 官方的服务端无效。我在下文的 UDP 支持中会详 述解决方案。

iOS 设备

我暂时还没有在 iOS 上实践过。不过 SingBox 内核是跨平台的，您应该可以使用大多 iOS 平台上支持1.13.0SingBox 内核的 APP 进行连接。

UDP 支持

前文提到，Naïve 官方的服务端无法代理 UDP 流量，因此您可能无法使用部分 VoIP 应用或游戏。Naïve 官方正在尝试添加对 RFC 9298 的支持，但目前尚未实现。

解决方法是使用 aUsernameWoW/forwardproxy 这个分支的 forwardproxy 插件来构建 Caddy。该分支支持 SingBox 的 UoT v1/v2 协议，将 UDP 包放入 TCP 包进行传输。需要注意的是，这样会损失一些网络性能；并且只有基于 SingBox 内核的客户端才能启用该功能，官方客户端可以连接，但是依然无法传输 UDP 流量。这是目前唯一能在 Naïve 中代理 UDP 流量的方法。

服务端

首先，我们需要用该分支的插件重新编译 Caddy 的服务端：

$ go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
$ ~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=github.com/aUsernameWoW/forwardproxy@udpintcp
$ sudo setcap cap_net_bind_service=+ep ./caddy

当然，对于 OpenWrt 或一些 aarch64 架构设备，我在这个仓库中也提供了编译好的二进制。

如果有正在运行的 Caddy 进程，先将其停止。用编译出来的新 Caddy 服务器覆盖之前的二进制。在之前教程中，Caddy 的二进制存在/usr/bin/caddy-naive，使用以下命令来替换：

rm /usr/bin/caddy-naive
mv ./caddy /usr/bin/caddy-naive

重新启动 Caddy 服务器，无须对 Caddyfile 或任何已有配置进行更改。

客户端：GUI.for.SingBox

打开 GUI.for.SingBox 的节点配置，在json中加入udp_over_tcp字段，就像这样：

[
  {
    "type": "naive",
    "tag": "my_naive",
    "server": "example.com",
    "server_port": 443,
    "username": "username",
    "password": "password",
    "udp_over_tcp": {
      "enabled": true,
      "version": 2
    },
    "tls": {
      "enabled": true,
      "server_name": "example.com"
    }
  }
]

更改并保存后，在 GUI 中点击更新订阅，使应用读取新配置。此时再进行连接就可以一并代理 UDP 流量了。

客户端：NekoBox

只需要在节点配置中打开 UDP over TCP 选项即可！赞美猫猫！

至此，您已经了解了 NaïveProxy 的常见配置方法。

参考文献

1. NaiveProxy 官方文档
2. SingBox 官方文档
3. NekoBox 官方文档
4. NaiveProxy | 墙高一尺我高一丈——Zokiio
5. 通过 Docker 搭建 NaiveProxy + Hysteria 代理——藍+85CD
6. NaiveProxy实战搭建教程——candicexiao
7. 立足科技 (2025) 【最强代理软件】GUI.For.SingBox详细使用教程，规则配置、TUN，策略组、分流规则集、路由规则、节点整理最新保姆级教程！关联翻墙客户端/ 2025/SingBox内核. [online video]. YouTube. 7 December. https://www.youtube.com/watch?v=ryXsaZnJbgA (Accessed: 1 January 2026)
8. Zohaib, A., Zao, Q., Sippe, J., Alaraj, A., Houmansadr, A., Durumeric, Z. and Wustrow, E. (2025) ‘Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China’, in Proceedings of the 34th USENIX Security Symposium (USENIX Security 25), Seattle, WA, USA, 13–15 August 2025. USENIX Association, pp. 783–802. Available at: https://gfw.report/publications/usenixsecurity25/en/ (Accessed: 1 January 2026)
9. Wu, M., Sippe, J., Sivakumar, D., Burg, J., Anderson, P., Wang, X., Bock, K., Houmansadr, A., Levin, D. and Wustrow, E. (2023) ‘How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic’, in Proceedings of the 32nd USENIX Security Symposium (USENIX Security 23), Anaheim, CA, USA, 9–11 August 2023. USENIX Association, pp. 2653–2670. Available at: https://gfw.report/publications/usenixsecurity23/en/ (Accessed: 1 January 2026)

对伪装不感兴趣，想找一个普通的VPN教程？不妨看看这个：