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 核心角色