NaiveProxy Caddy 搭建：认证、证书续期与更新恢复

NaiveProxy Caddy 搭建需要兼容的正向代理服务端、受信任证书，以及只承接指定应用流量的客户端。本文限定双端 Ubuntu 24.04 LTS x64、官方 NaiveProxy 客户端 v154.0.8037.49-4 和预构建 Naive Caddy v2.11.7-naive。这些是文档适用版本，不是作者实测版本。［1］［2］

关键要点

• 使用项目提供的 Naive 兼容 Caddy，普通 Caddy 二进制不足以确认兼容性。
• 客户端凭据存入私密文件，SOCKS 监听仅绑定回环地址。
• 分别检查授权转发、错误凭据和未认证 CONNECT。
• 首次签发成功不能证明证书续期正常。
• 保留可恢复配置，并跟进 Chromium 与 Caddy 的安全更新。

本文依据文末官方资料整理，未完成完整端到端实测。表格列出检查方法与预期行为，不代表已经测得的结果。准备前先阅读自建服务的所有权与恢复清单。

NaiveProxy Caddy 搭建需要哪些条件？

使用你拥有管理权的服务器，独立核验 SSH 主机密钥，并保留网络故障时可用的供应商控制台。SSH 使用严格主机密钥校验和项目专用 known_hosts；通过独立可信渠道预置密钥。未知、变更或已撤销的密钥均应停止连接，不能用“密码登录成功”代替服务器身份校验。

另需自有域名、可用 DNS，以及提供 TCP 80、443 服务的权限。本路线使用 TCP 上的 HTTPS，不配置 QUIC。公开受信任证书须覆盖 proxy.example.com。操作前替换所有示例域名、邮箱、用户名和密码；只有服务器确实支持相应 IPv6 路径时才发布 AAAA 记录。

先判断维护操作系统与 Chromium 衍生客户端是否有助于你的任务。如果只需日常公网出口，可先看看自建与托管出口各要维护什么。NaiveProxy 是应用代理实现；Xray 与 V2Ray 核心的职责有助于区分代理核心与整台设备的路由方案。

保存安装前基线

在专用新服务器上，记录系统、架构、现有监听、防火墙规则和证书服务。配置与证书备份仅供管理员读取。以足够权限运行 ss -lntup，确认 TCP 80、443 的占用者；如已有服务，先解决所有权冲突，不要为了套用示例停止无关进程。

保留来自管理地址的 SSH 放行规则，仅在主机和供应商两层防火墙添加所需 TCP 规则，不关闭防火墙。检查双端系统时间与 CA 包；时钟错误也会破坏证书校验。

步骤 1：安装官方服务端并隔离文件

从固定 forwardproxy 发行页下载 Linux amd64 服务端，从 NaiveProxy 发行页下载对应 Linux x64 客户端归档。核对官方页面、发行说明和已发布的完整性材料，在私密暂存目录解包，不执行下载的 shell 安装器。该客户端发行说明推荐上述 Naive Caddy 版本。［1］［2］

以下命令假设解出的服务端程序为 ./caddy，且专用账号 naive-caddy 尚不存在。已有同名账号时先检查其用途，不盲目改动所有权。

sudo useradd --system --home-dir /var/lib/naive-caddy --shell /usr/sbin/nologin naive-caddy
sudo install -d -o root -g root -m 0755 /opt/naive-caddy/v2.11.7-naive
sudo install -o root -g root -m 0755 ./caddy /opt/naive-caddy/v2.11.7-naive/caddy
sudo install -d -o root -g naive-caddy -m 0750 /etc/naive-caddy
sudo install -d -o naive-caddy -g naive-caddy -m 0700 /var/lib/naive-caddy
sudo install -d -o root -g root -m 0755 /var/www/naive-site
/opt/naive-caddy/v2.11.7-naive/caddy version
/opt/naive-caddy/v2.11.7-naive/caddy list-modules

确认版本符合预期，并存在 http.handlers.forward_proxy 模块。服务进程可以写证书状态，但不能替换 root 持有的程序或配置。Caddy 的证书管理需要持久、可写的存储，不要把 home 放在临时目录，也不要在日常维护时清空状态。［3］

步骤 2：配置 NaiveProxy 认证与 HTTPS

通过密码管理器或 openssl rand -hex 24，分别生成随机用户名和密码。十六进制可避免 URL 转义歧义。私密保存，真实值不进入命令参数、截图、工单或共享日志。用 sudoedit 创建 /etc/naive-caddy/Caddyfile：

{
    order forward_proxy before file_server
    log {
        exclude http.log.error
    }
}
:443, proxy.example.com {
    tls admin@example.com
    forward_proxy {
        basic_auth REPLACE_USER REPLACE_PASSWORD
        hide_ip
        hide_via
        probe_resistance
    }
    file_server {
        root /var/www/naive-site
    }
}

按官方示例让 :443 位于地址列表首位。probe_resistance 会改变未认证探测的响应方式，因此看似正常的网页响应不能证明已授权 CONNECT 转发。站点目录只放刻意公开的静态页面，不含秘密或不准备公开的目录内容。［4］

启动监听前先设置权限并验证：

sudo chown root:naive-caddy /etc/naive-caddy/Caddyfile
sudo chmod 0640 /etc/naive-caddy/Caddyfile
sudo -u naive-caddy /opt/naive-caddy/v2.11.7-naive/caddy validate --config /etc/naive-caddy/Caddyfile --adapter caddyfile

配置验证检查配置能否完成预备加载，不能证明证书签发或代理转发成功。这里失败就停止，依次核对构建、模块、语法和读取权限，不带病启动。

步骤 3：启动服务与回环客户端

以 root 创建 /etc/systemd/system/naive-caddy.service。该专用单元只授予绑定低端口的能力，不让守护进程以 root 运行；状态目录在重启后保持不变。Caddy 官方提供 systemd 服务管理路线。［3］

[Unit]
Description=Naive Caddy proxy
After=network-online.target
Wants=network-online.target

[Service]
User=naive-caddy
Group=naive-caddy
Environment=HOME=/var/lib/naive-caddy
WorkingDirectory=/var/lib/naive-caddy
ExecStart=/opt/naive-caddy/v2.11.7-naive/caddy run --config /etc/naive-caddy/Caddyfile --adapter caddyfile
ExecReload=/opt/naive-caddy/v2.11.7-naive/caddy reload --config /etc/naive-caddy/Caddyfile --adapter caddyfile
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/naive-caddy
Restart=on-failure
RestartSec=5
UMask=0077

[Install]
WantedBy=multi-user.target

运行 sudo systemctl daemon-reload，再执行 sudo systemctl enable --now naive-caddy。检查 systemctl status naive-caddy、仅管理员可访问的 journal 和监听归属。证书错误应修复 DNS、端口可达性、权限或时间，不给客户端添加跳过校验选项。

在 Ubuntu 客户端，将解出的 naive 安装到 root 持有的版本目录，例如 /opt/naive-client/v154.0.8037.49-4/naive。创建当前用户持有、权限 0700 的目录，并在其中保存权限 0600 的 config.json：

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "https://REPLACE_USER:REPLACE_PASSWORD@proxy.example.com"
}

以私密配置路径作为程序参数启动，凭据不直接出现在命令行中。首次试用保持前台运行，只将测试应用配置为 SOCKS5 127.0.0.1:1080，并记住原设置。TUN 与系统代理的差异说明其他应用为何可能完全不经过此监听。

如何验证转发与拒绝行为？

使用你管理的小型 HTTPS 端点完成可重复检查。curl 显式选择 SOCKS，并避免 NO_PROXY 导致绕过：

curl --fail --show-error --noproxy '' --proxy socks5h://127.0.0.1:1080 https://check.example.net/health

替换为你有权访问的测试目的地。socks5h 仅要求这次 curl 请求通过代理解析主机名，不能据此推断其他应用的 DNS 行为。日志仅限授权人员查看，不公开凭据或访问目的地。

每次用客户端副本做负例时，先停止上一个前台试验客户端，再仅用修改后的副本启动同一回环端口，确认监听属于该进程。一次只改一个条件；进入下一项前恢复正确文件，并重做正例请求。

检查方法	预期行为	失败处理
正确的私密客户端配置	受控目的地返回预期正文	分开排查本地监听、服务端 TLS、认证和目的地
复制配置，仅将密码换成另一个有效十六进制值	代理转发失败	若仍成功，先查进程、配置选择与绕过，不继续暴露服务
curl 发起未认证的 HTTPS 代理 CONNECT	不能通过授权隧道到达受控目的地	不强求 407；探测抵抗可能掩饰拒绝
复制配置，使用另一个自有域名，解析到服务端但不在证书内	TLS 身份校验失败	恢复正确名称，不关闭证书校验
只重启 naive-caddy 后发起新请求	重启后新授权请求可用	核对持久状态、服务身份和权限

未认证检查使用 curl --noproxy '' --proxy https://proxy.example.com:443 https://check.example.net/health，不提供凭据。应确认受控目的地没有经隧道被访问；公开掩护页面可访问与此无关。

在已配置代理的浏览器中打开IP 地址工具，与预期服务端出口比较。结论只覆盖该浏览器请求，不证明 UDP、IPv6、全部 DNS 或所有应用均符合预期。每次负例后恢复正确配置，再做一次正例。

NaiveProxy 证书续期与更新应如何维护？

Caddy 可自动签发和续期，前提是 DNS、验证入口、存储及 CA 持续可用。记录到期时间，监控服务错误。用仍有效的证书重启服务，不等于完成续期测试。［5］

将 staging 与生产隔离

ACME 演练使用独立域名、服务端口安排、账号和存储目录，通过 Caddy 的 acme_ca 指定 staging 端点。在隔离的 Ubuntu 客户端，从 CA 官方来源获取指定测试 CA 证书，仅为 Naive 进程将 SSL_CERT_FILE 指向明确的信任包，并保留主机名校验。不要系统级安装测试根证书，也不要共用生产证书状态。［6］［7］

先记录 staging 首次签发；要证明续期，必须观察后续替换证书及对应续期证据。若只有第一张证书，就如实保留“续期未验证”。不要删生产证书存储或反复强制签发来制造结果。

更新前，在仅管理员可读的备份中保留已知可用程序、私密配置、单元和证书状态。核对双项目发行与安全公告；Chromium 更新属于客户端维护责任。新版放入另一目录，验证配置后只修改本单元的程序路径，重做正例、负例和重启检查。回退恢复旧路径及兼容配置，只作临时恢复，不能长期保留存在漏洞的版本。

撤销访问与移除服务

替换或删除相应 basic_auth 凭据，验证后重新加载该单元。如需立即结束已建立隧道，停止并重启服务，同时接受对其他用户的中断。新连接中旧凭据应失败，新凭据应可用。彻底停用时恢复应用原代理设置、停止客户端、禁用并停止 naive-caddy，仅移除它自己的防火墙规则。恢复不再需要后，再安全退役凭据和无用 DNS 记录；此前保留私密恢复材料。

总结

将兼容服务端、证书状态和客户端配置作为不同维护边界。只有授权转发正常、负例被拒绝、重启与撤销符合预期，才接受这条路线。本文提供检查方法，不声称作者部署已经通过这些检查。

常见问题

普通 Caddy 软件包能直接用于 NaiveProxy 吗？

本路线使用 Naive 兼容的预构建发行版。普通软件包不能证明具备所需正向代理模块及 padding 兼容性。

TLS 握手成功是否代表 NaiveProxy 认证通过？

不能。应先通过已认证客户端访问受控目的地，再换用错误凭据重复请求，以检查认证拒绝和意外绕过。

为什么 Naive 客户端只监听回环地址？

若无认证的本地 SOCKS 入口暴露给其他机器，它们可能借用你的远端凭据。回环绑定把网络可达范围限制在客户端主机。

未认证 CONNECT 一定返回 HTTP 407 吗？

不一定，探测抵抗可能隐藏认证边界。关键是未认证请求不能获得授权转发，而不是某个固定状态码。

staging 演练能否关闭 TLS 校验？

应保留校验，仅在隔离客户端进程中明确信任指定测试 CA。演练结束后移除测试信任，不削弱生产环境。

重启 Caddy 能证明证书已续期吗？

不能。重启可能仍复用同一张证书；续期证据必须包含生命周期中的证书替换，不能只有服务启动成功。

修改密码会立刻断开已有隧道吗？

不要作此假设。需要立即撤销时应结束现有连接，再验证使用旧凭据的新连接失败，并确认新凭据可用。

来源:

1. NaiveProxy client release v154.0.8037.49-4 — https://github.com/klzgrad/naiveproxy/releases/tag/v154.0.8037.49-4
2. Naive Caddy release v2.11.7-naive — https://github.com/klzgrad/forwardproxy/releases/tag/v2.11.7-naive
3. Caddy: running as a service — https://caddyserver.com/docs/running
4. NaiveProxy: server and client configuration — https://github.com/klzgrad/naiveproxy
5. Caddy: automatic HTTPS — https://caddyserver.com/docs/automatic-https
6. Caddyfile: global options — https://caddyserver.com/docs/caddyfile/options
7. Let's Encrypt: staging environment — https://letsencrypt.org/docs/staging-environment/

Sources checked 2026 年 10 月 11 日。

延伸阅读：

• VPS 与托管 VPN 的维护取舍
• 分清 TUN 模式和系统代理的覆盖范围
• Xray 与 V2Ray 核心职责