HTTPS證書管理：讓W(xué)eb服務(wù)器告別手動(dòng)續(xù)期)
如果你被 HTTPS 證書折騰過大概能理解我為什么第一次用 Caddy 的時(shí)候會(huì)有一種“相見恨晚”的感覺。Caddy 是一個(gè)用 Go 寫的開源 Web 服務(wù)器在 Nginx、Apache 這些老牌選手面前并不算新但它的招牌能力至今沒有對(duì)手能做得如此省心自動(dòng)管理 HTTPS 證書。你只要告訴它一個(gè)域名剩下的申請(qǐng)、部署、續(xù)期、重載全部由 Caddy 自己完成。這篇東西寫給兩類人一是想自己搭站、但不想花時(shí)間維護(hù)證書的朋友二是已經(jīng)在用 Nginx、想給內(nèi)部服務(wù)或者小項(xiàng)目找一個(gè)省事方案的人。我會(huì)把 Caddy 的核心邏輯、一個(gè)真實(shí)可用的配置案例以及我踩過的坑都梳理成實(shí)操筆記盡量讓新手也能照著抄。1. 為什么 Caddy 在 Web 服務(wù)器里值得獨(dú)占一個(gè)坑位1.1 自動(dòng) HTTPS 不是加分項(xiàng)而是底層能力很多 Web 服務(wù)器把 HTTPS 證書當(dāng)成“外部插件”來處理先裝服務(wù)器再裝證書客戶端再寫定時(shí)任務(wù)讓證書每三個(gè)月續(xù)一次。這套流程本身沒什么問題但問題在于它把本應(yīng)自動(dòng)的事情變成了人工記憶。你可能會(huì)在某一天打開瀏覽器發(fā)現(xiàn)站點(diǎn)提示證書過期然后才想起來上一個(gè)續(xù)期腳本不知道為什么沒跑成功。Caddy 的設(shè)計(jì)完全不同。它在核心層內(nèi)置了 ACME 客戶端也就是說證書申請(qǐng)、校驗(yàn)、存儲(chǔ)、續(xù)期、熱更新這些能力和 HTTP/HTTPS 服務(wù)本身是一體的。Caddy 啟動(dòng)的時(shí)候看到配置里的域名會(huì)自動(dòng)判斷該為誰申請(qǐng)證書、什么時(shí)候續(xù)期、續(xù)期之后怎么切換到新證書。你不需要額外裝 Certbot不需要寫 cron不需要手動(dòng) reload Nginx。我第一次跑 Caddy配置里只寫了三行啟動(dòng)之后看到日志里出現(xiàn)“certificate obtained successfully”說實(shí)話是有被震撼到的。因?yàn)橥瑯拥氖掠?Nginx 加 Certbot 至少得折騰十幾分鐘而且還得考慮多個(gè)域名、泛域名、DNS 校驗(yàn)這些變數(shù)。Caddy 把“自動(dòng) HTTPS”放到了服務(wù)器內(nèi)核里不是通過某個(gè)腳本在外部兜底所以它不只是“省事”而是把 HTTPS 變成了一種默認(rèn)能力。1.2 和 Nginx、Apache 的設(shè)計(jì)哲學(xué)差異Nginx 和 Apache 都是非常優(yōu)秀的服務(wù)器它們的優(yōu)勢(shì)在于極致靈活和生態(tài)龐大。但靈活性也有代價(jià)默認(rèn)配置偏保守很多安全能力需要你自己動(dòng)手開啟。比如 HTTP/2、安全響應(yīng)頭、證書自動(dòng)續(xù)期這些在 Nginx 里通常要一個(gè)模塊一個(gè)模塊地加一個(gè)指令一個(gè)指令地配。Caddy 的哲學(xué)正好相反能自動(dòng)的就自動(dòng)能安全默認(rèn)的就安全默認(rèn)。它專為“普通運(yùn)維者能用最簡單的方式把服務(wù)跑起來”而設(shè)計(jì)。配置格式稱為 Caddyfile和 Nginx 的配置文件比起來更像一份簡潔的說明書。同一個(gè)靜態(tài)站點(diǎn)Nginx 可能需要這樣那樣地配置 server 塊、證書路徑、重定向規(guī)則Caddy 只需要一個(gè)域名加一個(gè) file_server。我用過一段時(shí)間 Nginx也維護(hù)過好幾個(gè)站點(diǎn)的證書。說實(shí)話Nginx 并沒有“做錯(cuò)”什么只是它把很多決策留給了使用者。Caddy 則更適合那些希望少做決策、少寫配置、少熬夜修證書的人。如果你習(xí)慣手動(dòng)控制每一個(gè)細(xì)節(jié)Caddy 也支持 JSON 配置和豐富的全局選項(xiàng)并不是一個(gè)只能“傻瓜式使用”的玩具。但在默認(rèn)情況下它會(huì)替你擋住大部分低級(jí)錯(cuò)誤。對(duì)比項(xiàng)Nginx/Apache 常見方式Caddy 默認(rèn)行為證書申請(qǐng)額外安裝 Certbot/ACME 腳本內(nèi)置 ACME 客戶端自動(dòng)申請(qǐng)證書續(xù)期cron 定時(shí)任務(wù)內(nèi)部調(diào)度自動(dòng)續(xù)期并熱加載HTTP 跳 HTTPS需要手動(dòng)配置 rewrite默認(rèn)開啟 HTTPS 自動(dòng)跳轉(zhuǎn)站點(diǎn)配置復(fù)雜度配置指令多規(guī)則靈活Caddyfile 精簡可讀性好安全頭默認(rèn)未開啟可一行指令批量添加這些差別不是“誰比誰厲害”的差別而是“誰更適合接手日常繁瑣工作”的差別。Caddy 把證書管理從“運(yùn)維職責(zé)”變成了“服務(wù)器本能”。1.3 Caddyfile 的精簡配置思路Caddyfile 的語法核心是“站點(diǎn)塊”。一個(gè)站點(diǎn)塊對(duì)應(yīng)一個(gè)域名塊里寫這個(gè)站點(diǎn)要做什么。最基本的靜態(tài)站配置是example.com { root * /srv/example file_server }example.com是站點(diǎn)地址root指定文件根目錄file_server表示把文件作為靜態(tài)內(nèi)容輸出。就這么簡單。Caddy 看到example.com這個(gè)域名后會(huì)自動(dòng)為該域名申請(qǐng)證書并完成 HTTPS 部署。你不需要寫listen 443 ssl不需要寫證書路徑不需要寫location塊。這種設(shè)計(jì)非常貼近實(shí)際使用邏輯我想讓這個(gè)域名提供一個(gè)網(wǎng)站而不是“我要在 443 端口監(jiān)聽 TLS 連接再把請(qǐng)求路由到某個(gè) root 目錄同時(shí)還要處理證書路徑”。Caddyfile 是面向網(wǎng)站功能的不是面向底層原語的。正因?yàn)檎Z法簡單配置里才不會(huì)堆滿一堆復(fù)制粘貼來的模板。我遇到過不少人Nginx 配置是從網(wǎng)上抄來的里面可能有三四個(gè)無用的 location 塊改一處就莫名其妙報(bào)錯(cuò)。Caddy 的做法是從源頭減少配置量讓你把精力放在站點(diǎn)本身而不是服務(wù)器內(nèi)部結(jié)構(gòu)。2. 從零裝好一臺(tái)能自動(dòng)續(xù)期的 HTTPS 服務(wù)器2.1 安裝與首個(gè)站點(diǎn)配置Caddy 的安裝方式很多最簡單的是直接用官方預(yù)編譯二進(jìn)制或者用系統(tǒng)包管理器。Debian/Ubuntu 上推薦添加官方倉庫后安裝因?yàn)檫@樣可以獲得 systemd 服務(wù)文件后續(xù)用systemctl管理會(huì)非常方便。安裝完執(zhí)行caddy version能輸出版本號(hào)就說明基本環(huán)境沒問題。裝好之后把站點(diǎn)配置寫到/etc/caddy/Caddyfile。如果是用官方二進(jìn)制可以直接運(yùn)行caddy run --config /etc/caddy/Caddyfile。如果是通過軟件包安裝通常會(huì)自動(dòng)注冊(cè)系統(tǒng)服務(wù)你可以用sudo systemctl enable --now caddy啟動(dòng)之后Caddy 會(huì)默認(rèn)監(jiān)聽 80 和 443 端口。首次訪問你的域名它會(huì)嘗試向 ACME 服務(wù)器申請(qǐng)證書這一步需要域名正確解析到這臺(tái)服務(wù)器并且 80 端口能通過公網(wǎng)訪問。整個(gè)申請(qǐng)過程通常幾十秒內(nèi)完成之后站點(diǎn)就會(huì)自動(dòng)以 HTTPS 方式提供訪問。我在測(cè)試機(jī)上第一次跑的時(shí)候因?yàn)橛蛎馕鲞€沒完全生效等了好幾分鐘都沒拿到證書。后來等 DNS 生效重跑了一次systemctl restart caddy證書馬上就下來了。所以如果你第一次配置沒有成功不要急著懷疑 Caddy優(yōu)先檢查 DNS 和端口。2.2 域名解析與 80/443 端口的坑自動(dòng) HTTPS 不是魔法它依賴一個(gè)公開可達(dá)的域名和端口。Caddy 默認(rèn)使用的是 HTTP-01 校驗(yàn)方式ACME 服務(wù)器會(huì)通過http://你的域名/.well-known/acme-challenge/這樣的路徑來訪問一個(gè)隨機(jī) token。如果這個(gè)請(qǐng)求到不了你服務(wù)器上的 Caddy證書申請(qǐng)就失敗。所以第一步保證域名 A 記錄或 AAAA 記錄正確解析到服務(wù)器公網(wǎng) IP。如果你用了 CDN 的加速節(jié)點(diǎn)第一次申請(qǐng)證書時(shí)最好先把 CDN 功能關(guān)掉等證書拿到之后再打開。因?yàn)?CDN 節(jié)點(diǎn)可能會(huì)攔截或改寫 ACME 的校驗(yàn)請(qǐng)求反而導(dǎo)致申請(qǐng)失敗。第二步保證 80 端口可用。很多云服務(wù)商默認(rèn)安全組只放行 22 端口你得去控制臺(tái)把 80 和 443 都放行。如果服務(wù)器上有防火墻也要檢查一下。Caddy 本身只是軟件能不能被公網(wǎng)訪問是網(wǎng)絡(luò)層面的事。這時(shí)候最直接的排查命令是ss -tlnp | grep -E :80|:443如果看到 Caddy 進(jìn)程正在監(jiān)聽這兩個(gè)端口再從另一臺(tái)電腦上用curl -I http://你的域名測(cè)試確認(rèn) HTTP 請(qǐng)求能正常返回。只有這個(gè)鏈路通了ACME 校驗(yàn)才有成功的可能。如果域名在內(nèi)網(wǎng)或者服務(wù)器在 NAT 后面還需要在路由器上做端口映射。這些細(xì)節(jié)聽起來基礎(chǔ)但大部分證書申請(qǐng)失敗都出在這里。2.3 證書申請(qǐng)流程到底發(fā)生了什么雖然 Caddy 把過程封裝得很黑盒但明白底層流程對(duì)排查問題很有用。Caddy 作為 ACME 客戶端大致會(huì)做這幾件事如果是第一次使用它會(huì)生成一對(duì)賬號(hào)密鑰用于向 ACME 服務(wù)器證明你的身份。它會(huì)向 ACME 服務(wù)器申請(qǐng)一個(gè)新訂單訂單里包含你想申請(qǐng)的域名。ACME 服務(wù)器返回需要完成的校驗(yàn)方式Caddy 會(huì)選擇當(dāng)前配置允許的校驗(yàn)方式。比如 HTTP-01 校驗(yàn)Caddy 會(huì)在 80 端口臨時(shí)提供一個(gè)校驗(yàn)路徑內(nèi)容是該訂單對(duì)應(yīng)的 token。ACME 服務(wù)器從公網(wǎng)訪問這個(gè)路徑確認(rèn)你能控制這個(gè)域名。校驗(yàn)通過后CA 簽發(fā)證書Caddy 把證書和私鑰保存到本地?cái)?shù)據(jù)目錄。后續(xù)到續(xù)期時(shí)間Caddy 會(huì)重復(fù)類似流程并熱更新證書。這個(gè)過程和 Certbot 手動(dòng)執(zhí)行沒有本質(zhì)區(qū)別但 Caddy 把它放進(jìn)了服務(wù)器進(jìn)程內(nèi)部。好處是只要 Caddy 進(jìn)程活著續(xù)期這件事就不會(huì)被遺漏。它不需要依賴外部 cron也不需要在系統(tǒng)重啟后人工去檢查。對(duì)健忘的人以及需要長期穩(wěn)定運(yùn)行的小項(xiàng)目來說這太重要了。3. 證書文件、續(xù)期機(jī)制與安全加固的核心細(xì)節(jié)3.1 證書存在哪里怎么備份Caddy 會(huì)把證書和私鑰保存在數(shù)據(jù)目錄里。這個(gè)目錄的位置取決于安裝方式和運(yùn)行用戶。用 Debian 軟件包安裝時(shí)數(shù)據(jù)通常會(huì)在/var/lib/caddy/.local/share/caddy/certificates/下面文件名類似acme-v02.api.letsencrypt.org-directory/example.com/example.com.crt如果是手動(dòng)下載二進(jìn)制并以當(dāng)前用戶運(yùn)行數(shù)據(jù)目錄一般在~/.local/share/caddy/certificates/。不確定的時(shí)候可以用 find 找一下find / -type d -name certificates 2/dev/null | grep caddy找到之后建議把整個(gè)數(shù)據(jù)目錄定期備份。這里面不僅有證書還有 ACME 賬號(hào)私鑰和站點(diǎn)私鑰。換了服務(wù)器或者系統(tǒng)重裝恢復(fù)數(shù)據(jù)目錄就能讓 Caddy 直接復(fù)用原來的證書和賬號(hào)避免重新申請(qǐng)時(shí)碰到頻率限制。備份時(shí)注意私鑰文件權(quán)限最好只讓管理員賬號(hào)能讀不要放進(jìn)公開倉庫。如果你只是把證書文件拷貝出來發(fā)給別人這是不安全的。私鑰一旦泄露任何人都能用它冒充你的站點(diǎn)。Caddy 的自動(dòng) HTTPS 雖然省心但備份策略還是要自己管好。3.2 證書自動(dòng)續(xù)期與熱更新機(jī)制Lets Encrypt 簽發(fā)的證書有效期一般是 90 天所以每隔三個(gè)月就要續(xù)一次。Caddy不會(huì)等到最后一刻才續(xù)它會(huì)在證書有效期剩余一定比例時(shí)開始嘗試通常在證書剩余時(shí)間約 30% 到 40% 時(shí)觸發(fā)也就是證書簽發(fā)后的第 54 到 63 天左右。這個(gè)時(shí)間是隨機(jī)的目的是避免大量服務(wù)器在同一時(shí)刻向 CA 發(fā)起請(qǐng)求。續(xù)期成功之后Caddy 會(huì)把新證書替換到運(yùn)行中的 TLS 配置里這個(gè)過程不需要重啟進(jìn)程也不會(huì)中斷已經(jīng)建立的連接。老連接可以繼續(xù)走老證書新連接開始使用新證書。對(duì)我這種要跑線上服務(wù)的人這種無感替換非常關(guān)鍵。手動(dòng)用 Nginx 續(xù)期雖然也不難但如果沒執(zhí)行 reload新證書就不會(huì)生效折騰完還得驗(yàn)證一下。如果某次續(xù)期失敗了Caddy 不會(huì)直接放棄它會(huì)在后續(xù)周期里繼續(xù)重試并且日志里會(huì)有明確提示。最壞情況下你只需要在 Caddy 日志里看到 error然后去排查 DNS 或端口。等修復(fù)之后它基本能在下一次重試時(shí)把證書續(xù)上。這種“自己會(huì)再來一次”的機(jī)制比手動(dòng)定時(shí)任務(wù)少了很多人為失誤。3.3 安全頭、HTTP/2 與默認(rèn)加固證書是 HTTPS 的第一個(gè)環(huán)節(jié)但 Web 服務(wù)器安全不止證書。Caddy 的默認(rèn)行為已經(jīng)做得比較到位它默認(rèn)開啟 HTTP/2并且會(huì)自動(dòng)把 HTTP 請(qǐng)求跳轉(zhuǎn)到 HTTPS。如果你希望再加一層響應(yīng)頭可以在站點(diǎn)塊里用header指令統(tǒng)一設(shè)置。example.com { root * /srv/example file_server header { Strict-Transport-Security max-age31536000; includeSubDomains X-Content-Type-Options nosniff X-Frame-Options SAMEORIGIN Referrer-Policy strict-origin-when-cross-origin } }Strict-Transport-Security就是常說的 HSTS它會(huì)讓瀏覽器在一段時(shí)間內(nèi)強(qiáng)制使用 HTTPS 訪問站點(diǎn)減少降級(jí)攻擊。X-Content-Type-Options防止瀏覽器自動(dòng)猜測(cè)文件類型X-Frame-Options可以避免頁面被惡意嵌套到 iframe 里。這些頭在 Nginx 里也不是不能配但 Caddy 的寫法更接近“我要什么效果”而不是“我要設(shè)置哪個(gè) HTTP 頭”。還有一個(gè)容易被忽略的點(diǎn)Caddy 會(huì)默認(rèn)在日志里記錄客戶端的真實(shí) IP也會(huì)在反向轉(zhuǎn)發(fā)場(chǎng)景中自動(dòng)處理一些頭部字段。只要你不把敏感信息寫到公開日志里默認(rèn)配置已經(jīng)能滿足大多數(shù)場(chǎng)景。安全不是某一個(gè)功能而是“默認(rèn)會(huì)不會(huì)給你挖坑”。Caddy 在這方面至少不會(huì)故意讓你裸奔。3.4 把 WebDAV 等服務(wù)也納進(jìn)統(tǒng)一 HTTPS 體系我很喜歡 Caddy 的一點(diǎn)是它不只會(huì)托管靜態(tài)網(wǎng)站。只要你能把任意本地服務(wù)跑在某個(gè)端口就能讓 Caddy 作為統(tǒng)一入口為它套上 HTTPS 和安全認(rèn)證。尤其是 WebDAV 這一類需要長期訪問、又不想暴露裸的 HTTP 服務(wù)配到 Caddy 后面非常合適。比如你在本機(jī) 8081 端口跑了一個(gè) WebDAV 服務(wù)域名為dav.example.com。那么 Caddyfile 可以這樣寫dav.example.com { basicauth { alice $2a$14$... } reverse_proxy 127.0.0.1:8081 }basicauth可以先加一層用戶名密碼認(rèn)證密碼哈?？梢杂胏addy hash-password --plaintext 你的密碼生成。reverse_proxy這個(gè)指令負(fù)責(zé)把來自dav.example.com的請(qǐng)求轉(zhuǎn)給本機(jī)的 8081 端口。這樣你不需要在 WebDAV 服務(wù)本身實(shí)現(xiàn) HTTPS也不需要擔(dān)心它被直接暴露到公網(wǎng)Caddy 在前面統(tǒng)一處理了 TLS、認(rèn)證和訪問日志。如果你的 WebDAV 服務(wù)本身不想用插件我其實(shí)更推薦這種方式后端保持簡單前端統(tǒng)一入口。Caddy 替你解決證書和認(rèn)證后端只需要關(guān)心存儲(chǔ)和協(xié)議支持。對(duì)個(gè)人網(wǎng)盤、文件同步、小型協(xié)作場(chǎng)景來說這套組合非常實(shí)用而且全程免費(fèi)。4. 實(shí)操過程一個(gè)靜態(tài)站加后端服務(wù)轉(zhuǎn)發(fā)的典型配置4.1 場(chǎng)景描述與目錄結(jié)構(gòu)現(xiàn)在拿一個(gè)實(shí)際項(xiàng)目來串一遍流程。假設(shè)你有一臺(tái)云服務(wù)器公網(wǎng)域名example.com根目錄/srv/www放著一個(gè)靜態(tài)站點(diǎn)另外有一個(gè) API 服務(wù)跑在127.0.0.1:8080希望只有/api/路徑能訪問到它還有一個(gè) WebDAV 服務(wù)跑在127.0.0.1:8081用獨(dú)立的dav.example.com域名對(duì)外提供。整個(gè)項(xiàng)目要在裸機(jī)上快速上線并且全部啟用 HTTPS。服務(wù)器目錄大概長這樣/srv/www/ ├── index.html ├── assets/ └── ...API 服務(wù)和 WebDAV 服務(wù)都已經(jīng)在本機(jī)端口運(yùn)行Caddy 只負(fù)責(zé)把公網(wǎng)請(qǐng)求轉(zhuǎn)發(fā)給它們。這樣做的好處很明顯后端不需要綁定 80/443 端口不需要處理證書也不容易被掃描器直接攻擊。4.2 Caddyfile 實(shí)例逐行講解把下面的配置寫入/etc/caddy/Caddyfile然后重新加載 Caddyexample.com { root * /srv/www encode zstd gzip handle /api/* { reverse_proxy 127.0.0.1:8080 } handle { file_server } } dav.example.com { basicauth { alice $2a$14$... } reverse_proxy 127.0.0.1:8081 }第一行example.com是站點(diǎn)地址Caddy 會(huì)自動(dòng)為它申請(qǐng)證書。root * /srv/www中的*表示匹配所有請(qǐng)求它告訴 Caddy 文件根目錄在哪。encode zstd gzip開啟壓縮靜態(tài)資源可以節(jié)約流量。handle /api/*表示所有以/api/開頭的請(qǐng)求進(jìn)入這個(gè)塊然后由reverse_proxy 127.0.0.1:8080轉(zhuǎn)給本地 API 服務(wù)。handle不會(huì)自動(dòng)去掉/api/前綴后端收到完整路徑所以你在后端不需要額外改路由。緊接著的handle {}是兜底塊匹配所有剩余請(qǐng)求并用file_server返回靜態(tài)文件。這個(gè)結(jié)構(gòu)用大白話講就是/api/走后端其他路徑走靜態(tài)目錄。第二個(gè)站點(diǎn)塊dav.example.com則更簡單先做 Basic 認(rèn)證再把所有請(qǐng)求轉(zhuǎn)給 8081 端口的 WebDAV 服務(wù)。這里我提醒一下basicauth的密碼哈希不要用明文生產(chǎn)環(huán)境一定要用 Caddy 生成的 bcrypt 哈希。這個(gè)配置看起來不起眼但已經(jīng)包含了 TLS、壓縮、路由、認(rèn)證、后端轉(zhuǎn)發(fā)這些日常最常用的能力。4.3 啟動(dòng)、重載與排錯(cuò)命令寫完配置不要直接重啟先校驗(yàn)一下格式。Caddy 提供了兩個(gè)很有用的命令caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile caddy fmt --overwrite /etc/caddy/Caddyfilevalidate會(huì)解析配置并報(bào)告語法錯(cuò)誤或語義沖突fmt會(huì)統(tǒng)一格式。對(duì)我來說改完配置先 validate 已經(jīng)成為習(xí)慣了特別是改動(dòng)結(jié)構(gòu)比較大的時(shí)候可以避免因?yàn)樯賹懸粋€(gè)括號(hào)導(dǎo)致服務(wù)起不來。確認(rèn)沒問題后用系統(tǒng)服務(wù)重載sudo systemctl reload caddy如果你不是用系統(tǒng)服務(wù)而是手動(dòng)caddy run可以替代為caddy reload。重載過程中 Caddy 會(huì)平滑應(yīng)用新配置不會(huì)中斷已有連接。如果配置有誤進(jìn)程會(huì)保留舊配置繼續(xù)運(yùn)行不會(huì)讓你一頭撞死在線上。排查日志時(shí)用journalctl -u caddy -f這個(gè)命令會(huì)持續(xù)輸出 Caddy 日志。證書申請(qǐng)、續(xù)期、轉(zhuǎn)發(fā)錯(cuò)誤、ACME 校驗(yàn)失敗都會(huì)在這里顯示。我第一次配 WebDAV 的時(shí)候日志里總是報(bào) 401后來發(fā)現(xiàn)是basicauth的密碼哈希沒有更新重新生成一次就正常了。日志不是可看可不看的遇到問題第一反應(yīng)就是開日志。4.4 驗(yàn)證 HTTPS 與證書狀態(tài)配置好之后用瀏覽器打開https://example.com能看到鎖圖標(biāo)就說明證書生效。如果還想在命令行確認(rèn)證書有效期可以用openssl s_client -connect example.com:443 -servername example.com 2/dev/null | openssl x509 -noout -dates輸出里會(huì)顯示證書的開始時(shí)間和結(jié)束時(shí)間。只要結(jié)束時(shí)間在差不多三個(gè)月以后說明當(dāng)前證書是剛申請(qǐng)或者剛續(xù)過的。對(duì)于 Caddy 自動(dòng)續(xù)期的站點(diǎn)你不需要經(jīng)?？催@個(gè)但偶爾確認(rèn)一下能放心。再測(cè)試一下跳轉(zhuǎn)是否正常curl -I http://example.com正常情況下應(yīng)該看到類似301 Moved Permanently的響應(yīng)并且Location指向https://example.com。這就是 Caddy 默認(rèn)的 HTTPS 跳轉(zhuǎn)行為。如果這一步?jīng)]生效多半是全局配置里把自動(dòng)跳轉(zhuǎn)關(guān)掉了或者 80 端口沒有正常放行。5. 常見問題與排查技巧實(shí)錄5.1 證書申請(qǐng)失敗證書申請(qǐng)失敗是新手最容易碰到的問題。我把最常見的幾種原因整理成一個(gè)速查表現(xiàn)象可能原因解決辦法日志提示 timeout 或 connection refused80 端口不通檢查云安全組、防火墻、端口映射日志提示 no A recordDNS 沒解析到本機(jī)用dig確認(rèn)解析記錄日志提示 invalid responseCDN 或反向接入層干擾校驗(yàn)首次申請(qǐng)時(shí)暫時(shí)關(guān)閉 CDN 加速證書一直不成功但端口正常公網(wǎng) IP 被墻或網(wǎng)絡(luò)策略限制檢查服務(wù)器出口以及對(duì) ACME 服務(wù)器的連通性提示 rate limit同一域名申請(qǐng)?zhí)l繁使用 Caddy 的 staging CA 測(cè)試避免打正式額度如果你只是想測(cè)試配置可以使用 Lets Encrypt 的 staging 環(huán)境在 Caddy 全局配置里加一條{ acme_ca https://acme-staging-v02.api.letsencrypt.org/directory }這個(gè)環(huán)境簽發(fā)的證書瀏覽器不信任只適合測(cè)試流程。等確認(rèn)一切正常記得刪掉這行再重新申請(qǐng)正式證書。通過 staging 環(huán)境可以大幅降低遇到頻率限制的概率尤其適合反復(fù)調(diào)試的場(chǎng)景。5.2 后端轉(zhuǎn)發(fā)時(shí)的真實(shí) IP 與 WebSocket當(dāng)你用 Caddy 把請(qǐng)求轉(zhuǎn)給本地后端服務(wù)時(shí)后端日志里可能只看到127.0.0.1因?yàn)檫B接確實(shí)來自 Caddy 進(jìn)程。為了讓后端拿到真實(shí)客戶端 IPCaddy 會(huì)在轉(zhuǎn)發(fā)時(shí)帶上X-Forwarded-For、X-Forwarded-Proto等頭部。如果你的后端框架默認(rèn)信任這些頭日志里就會(huì)顯示真實(shí) IP如果后端在更復(fù)雜的網(wǎng)絡(luò)環(huán)境里可能還需要顯式配置信任范圍。WebSocket 是另一個(gè)容易踩坑的地方。很多 Web 服務(wù)需要長連接比如實(shí)時(shí)通知、在線終端。Caddy 的reverse_proxy對(duì) WebSocket 支持是開箱即用的不需要額外插件也不需要特殊配置。只要后端支持 WebSocketCaddy 會(huì)自動(dòng)升級(jí)連接并保持轉(zhuǎn)發(fā)。我第一次配的時(shí)候以為要寫什么特殊指令結(jié)果發(fā)現(xiàn)什么都不用做把請(qǐng)求轉(zhuǎn)過去就通了。不過有一點(diǎn)需要注意如果前端有多層轉(zhuǎn)發(fā)結(jié)構(gòu)每一層都應(yīng)該正確傳遞X-Forwarded-*頭部否則最終服務(wù)拿到的 IP 可能不準(zhǔn)。Caddy 在這方面的默認(rèn)行為對(duì)大多數(shù)場(chǎng)景夠了但如果你在云負(fù)載均衡后面最好檢查一下各層頭部策略。5.3 權(quán)限、內(nèi)存與長期運(yùn)行Caddy 是 Go 編寫的東西編譯成單一二進(jìn)制資源占用相對(duì)克制。我見過一個(gè)只托管靜態(tài)文件的 Caddy 實(shí)例內(nèi)存長期在 30MB 到 50MB 左右和一套全家桶方案比起來輕得多。如果還需要處理并發(fā)和壓縮內(nèi)存會(huì)高一些但總體還是可控的。權(quán)限問題也需要留意。如果你用非 root 用戶手動(dòng)運(yùn)行 Caddy又想監(jiān)聽 80 和 443 端口一般需要提權(quán)才能綁定到低端口。Linux 上可以用setcap給二進(jìn)制分配net_bind_service能力sudo setcap cap_net_bind_serviceep /usr/bin/caddy如果是通過官方軟件包安裝systemd 服務(wù)通常已經(jīng)處理了這些權(quán)限問題。數(shù)據(jù)目錄的屬主也要和運(yùn)行用戶一致否則 Caddy 可能沒有權(quán)限寫入證書和日志。日志和證書文件的權(quán)限是最容易被忽略的一旦出現(xiàn)“permission denied”優(yōu)先檢查服務(wù)用戶和目錄所有者。長期運(yùn)行的系統(tǒng)定期看一眼日志還是有必要的。Caddy 的默認(rèn)日志不算吵但如果某個(gè)后端服務(wù)頻繁超時(shí)日志里會(huì)不斷刷錯(cuò)誤。你可以通過日志輪轉(zhuǎn)來避免磁盤被撐滿也可以在配置里按需調(diào)整日志級(jí)別?？傊詣?dòng) HTTPS 不等于“完全不看服務(wù)器”而是把最繁瑣的證書操作從你的待辦事項(xiàng)里刪掉。最后再分享一點(diǎn)我的實(shí)際體會(huì)Caddy 不是萬能的如果你需要極度復(fù)雜的條件路由、自定義模塊組合或者有專門的性能調(diào)優(yōu)需求原來的 Nginx 體系也許更合適。但對(duì)我這種“想把站點(diǎn)快速安全跑起來不想被證書和 reload 折磨”的人來說Caddy 的體驗(yàn)確實(shí)是目前最舒服的。我現(xiàn)在把個(gè)人博客、內(nèi)部工具、WebDAV 都掛在一臺(tái)小服務(wù)器上一個(gè) Caddyfile 管到底證書從沒手動(dòng)續(xù)過。最后一個(gè)小建議把 Caddyfile 納入 git 管理每次改完先caddy validate再 reload這樣哪怕改壞也能快速回滾。希望這篇實(shí)操筆記能讓你少走一些我走過的彎路。 Caddy自動(dòng)HTTPS證書管理：讓W(xué)eb服務(wù)器告別手動(dòng)續(xù)期
如果你被 HTTPS 證書折騰過大概能理解我為什么第一次用 Caddy 的時(shí)候會(huì)有一種“相見恨晚”的感覺。Caddy 是一個(gè)用 Go 寫的開源 Web 服務(wù)器在 Nginx、Apache 這些老牌選手面前并不算新但它的招牌能力至今沒有對(duì)手能做得如此省心自動(dòng)管理 HTTPS 證書。你只要告訴它一個(gè)域名剩下的申請(qǐng)、部署、續(xù)期、重載全部由 Caddy 自己完成。這篇東西寫給兩類人一是想自己搭站、但不想花時(shí)間維護(hù)證書的朋友二是已經(jīng)在用 Nginx、想給內(nèi)部服務(wù)或者小項(xiàng)目找一個(gè)省事方案的人。我會(huì)把 Caddy 的核心邏輯、一個(gè)真實(shí)可用的配置案例以及我踩過的坑都梳理成實(shí)操筆記盡量讓新手也能照著抄。1. 為什么 Caddy 在 Web 服務(wù)器里值得獨(dú)占一個(gè)坑位1.1 自動(dòng) HTTPS 不是加分項(xiàng)而是底層能力很多 Web 服務(wù)器把 HTTPS 證書當(dāng)成“外部插件”來處理先裝服務(wù)器再裝證書客戶端再寫定時(shí)任務(wù)讓證書每三個(gè)月續(xù)一次。這套流程本身沒什么問題但問題在于它把本應(yīng)自動(dòng)的事情變成了人工記憶。你可能會(huì)在某一天打開瀏覽器發(fā)現(xiàn)站點(diǎn)提示證書過期然后才想起來上一個(gè)續(xù)期腳本不知道為什么沒跑成功。Caddy 的設(shè)計(jì)完全不同。它在核心層內(nèi)置了 ACME 客戶端也就是說證書申請(qǐng)、校驗(yàn)、存儲(chǔ)、續(xù)期、熱更新這些能力和 HTTP/HTTPS 服務(wù)本身是一體的。Caddy 啟動(dòng)的時(shí)候看到配置里的域名會(huì)自動(dòng)判斷該為誰申請(qǐng)證書、什么時(shí)候續(xù)期、續(xù)期之后怎么切換到新證書。你不需要額外裝 Certbot不需要寫 cron不需要手動(dòng) reload Nginx。我第一次跑 Caddy配置里只寫了三行啟動(dòng)之后看到日志里出現(xiàn)“certificate obtained successfully”說實(shí)話是有被震撼到的。因?yàn)橥瑯拥氖掠?Nginx 加 Certbot 至少得折騰十幾分鐘而且還得考慮多個(gè)域名、泛域名、DNS 校驗(yàn)這些變數(shù)。Caddy 把“自動(dòng) HTTPS”放到了服務(wù)器內(nèi)核里不是通過某個(gè)腳本在外部兜底所以它不只是“省事”而是把 HTTPS 變成了一種默認(rèn)能力。1.2 和 Nginx、Apache 的設(shè)計(jì)哲學(xué)差異Nginx 和 Apache 都是非常優(yōu)秀的服務(wù)器它們的優(yōu)勢(shì)在于極致靈活和生態(tài)龐大。但靈活性也有代價(jià)默認(rèn)配置偏保守很多安全能力需要你自己動(dòng)手開啟。比如 HTTP/2、安全響應(yīng)頭、證書自動(dòng)續(xù)期這些在 Nginx 里通常要一個(gè)模塊一個(gè)模塊地加一個(gè)指令一個(gè)指令地配。Caddy 的哲學(xué)正好相反能自動(dòng)的就自動(dòng)能安全默認(rèn)的就安全默認(rèn)。它專為“普通運(yùn)維者能用最簡單的方式把服務(wù)跑起來”而設(shè)計(jì)。配置格式稱為 Caddyfile和 Nginx 的配置文件比起來更像一份簡潔的說明書。同一個(gè)靜態(tài)站點(diǎn)Nginx 可能需要這樣那樣地配置 server 塊、證書路徑、重定向規(guī)則Caddy 只需要一個(gè)域名加一個(gè) file_server。我用過一段時(shí)間 Nginx也維護(hù)過好幾個(gè)站點(diǎn)的證書。說實(shí)話Nginx 并沒有“做錯(cuò)”什么只是它把很多決策留給了使用者。Caddy 則更適合那些希望少做決策、少寫配置、少熬夜修證書的人。如果你習(xí)慣手動(dòng)控制每一個(gè)細(xì)節(jié)Caddy 也支持 JSON 配置和豐富的全局選項(xiàng)并不是一個(gè)只能“傻瓜式使用”的玩具。但在默認(rèn)情況下它會(huì)替你擋住大部分低級(jí)錯(cuò)誤。對(duì)比項(xiàng)Nginx/Apache 常見方式Caddy 默認(rèn)行為證書申請(qǐng)額外安裝 Certbot/ACME 腳本內(nèi)置 ACME 客戶端自動(dòng)申請(qǐng)證書續(xù)期cron 定時(shí)任務(wù)內(nèi)部調(diào)度自動(dòng)續(xù)期并熱加載HTTP 跳 HTTPS需要手動(dòng)配置 rewrite默認(rèn)開啟 HTTPS 自動(dòng)跳轉(zhuǎn)站點(diǎn)配置復(fù)雜度配置指令多規(guī)則靈活Caddyfile 精簡可讀性好安全頭默認(rèn)未開啟可一行指令批量添加這些差別不是“誰比誰厲害”的差別而是“誰更適合接手日常繁瑣工作”的差別。Caddy 把證書管理從“運(yùn)維職責(zé)”變成了“服務(wù)器本能”。1.3 Caddyfile 的精簡配置思路Caddyfile 的語法核心是“站點(diǎn)塊”。一個(gè)站點(diǎn)塊對(duì)應(yīng)一個(gè)域名塊里寫這個(gè)站點(diǎn)要做什么。最基本的靜態(tài)站配置是example.com { root * /srv/example file_server }example.com是站點(diǎn)地址root指定文件根目錄file_server表示把文件作為靜態(tài)內(nèi)容輸出。就這么簡單。Caddy 看到example.com這個(gè)域名后會(huì)自動(dòng)為該域名申請(qǐng)證書并完成 HTTPS 部署。你不需要寫listen 443 ssl不需要寫證書路徑不需要寫location塊。這種設(shè)計(jì)非常貼近實(shí)際使用邏輯我想讓這個(gè)域名提供一個(gè)網(wǎng)站而不是“我要在 443 端口監(jiān)聽 TLS 連接再把請(qǐng)求路由到某個(gè) root 目錄同時(shí)還要處理證書路徑”。Caddyfile 是面向網(wǎng)站功能的不是面向底層原語的。正因?yàn)檎Z法簡單配置里才不會(huì)堆滿一堆復(fù)制粘貼來的模板。我遇到過不少人Nginx 配置是從網(wǎng)上抄來的里面可能有三四個(gè)無用的 location 塊改一處就莫名其妙報(bào)錯(cuò)。Caddy 的做法是從源頭減少配置量讓你把精力放在站點(diǎn)本身而不是服務(wù)器內(nèi)部結(jié)構(gòu)。2. 從零裝好一臺(tái)能自動(dòng)續(xù)期的 HTTPS 服務(wù)器2.1 安裝與首個(gè)站點(diǎn)配置Caddy 的安裝方式很多最簡單的是直接用官方預(yù)編譯二進(jìn)制或者用系統(tǒng)包管理器。Debian/Ubuntu 上推薦添加官方倉庫后安裝因?yàn)檫@樣可以獲得 systemd 服務(wù)文件后續(xù)用systemctl管理會(huì)非常方便。安裝完執(zhí)行caddy version能輸出版本號(hào)就說明基本環(huán)境沒問題。裝好之后把站點(diǎn)配置寫到/etc/caddy/Caddyfile。如果是用官方二進(jìn)制可以直接運(yùn)行caddy run --config /etc/caddy/Caddyfile。如果是通過軟件包安裝通常會(huì)自動(dòng)注冊(cè)系統(tǒng)服務(wù)你可以用sudo systemctl enable --now caddy啟動(dòng)之后Caddy 會(huì)默認(rèn)監(jiān)聽 80 和 443 端口。首次訪問你的域名它會(huì)嘗試向 ACME 服務(wù)器申請(qǐng)證書這一步需要域名正確解析到這臺(tái)服務(wù)器并且 80 端口能通過公網(wǎng)訪問。整個(gè)申請(qǐng)過程通常幾十秒內(nèi)完成之后站點(diǎn)就會(huì)自動(dòng)以 HTTPS 方式提供訪問。我在測(cè)試機(jī)上第一次跑的時(shí)候因?yàn)橛蛎馕鲞€沒完全生效等了好幾分鐘都沒拿到證書。后來等 DNS 生效重跑了一次systemctl restart caddy證書馬上就下來了。所以如果你第一次配置沒有成功不要急著懷疑 Caddy優(yōu)先檢查 DNS 和端口。2.2 域名解析與 80/443 端口的坑自動(dòng) HTTPS 不是魔法它依賴一個(gè)公開可達(dá)的域名和端口。Caddy 默認(rèn)使用的是 HTTP-01 校驗(yàn)方式ACME 服務(wù)器會(huì)通過http://你的域名/.well-known/acme-challenge/這樣的路徑來訪問一個(gè)隨機(jī) token。如果這個(gè)請(qǐng)求到不了你服務(wù)器上的 Caddy證書申請(qǐng)就失敗。所以第一步保證域名 A 記錄或 AAAA 記錄正確解析到服務(wù)器公網(wǎng) IP。如果你用了 CDN 的加速節(jié)點(diǎn)第一次申請(qǐng)證書時(shí)最好先把 CDN 功能關(guān)掉等證書拿到之后再打開。因?yàn)?CDN 節(jié)點(diǎn)可能會(huì)攔截或改寫 ACME 的校驗(yàn)請(qǐng)求反而導(dǎo)致申請(qǐng)失敗。第二步保證 80 端口可用。很多云服務(wù)商默認(rèn)安全組只放行 22 端口你得去控制臺(tái)把 80 和 443 都放行。如果服務(wù)器上有防火墻也要檢查一下。Caddy 本身只是軟件能不能被公網(wǎng)訪問是網(wǎng)絡(luò)層面的事。這時(shí)候最直接的排查命令是ss -tlnp | grep -E :80|:443如果看到 Caddy 進(jìn)程正在監(jiān)聽這兩個(gè)端口再從另一臺(tái)電腦上用curl -I http://你的域名測(cè)試確認(rèn) HTTP 請(qǐng)求能正常返回。只有這個(gè)鏈路通了ACME 校驗(yàn)才有成功的可能。如果域名在內(nèi)網(wǎng)或者服務(wù)器在 NAT 后面還需要在路由器上做端口映射。這些細(xì)節(jié)聽起來基礎(chǔ)但大部分證書申請(qǐng)失敗都出在這里。2.3 證書申請(qǐng)流程到底發(fā)生了什么雖然 Caddy 把過程封裝得很黑盒但明白底層流程對(duì)排查問題很有用。Caddy 作為 ACME 客戶端大致會(huì)做這幾件事如果是第一次使用它會(huì)生成一對(duì)賬號(hào)密鑰用于向 ACME 服務(wù)器證明你的身份。它會(huì)向 ACME 服務(wù)器申請(qǐng)一個(gè)新訂單訂單里包含你想申請(qǐng)的域名。ACME 服務(wù)器返回需要完成的校驗(yàn)方式Caddy 會(huì)選擇當(dāng)前配置允許的校驗(yàn)方式。比如 HTTP-01 校驗(yàn)Caddy 會(huì)在 80 端口臨時(shí)提供一個(gè)校驗(yàn)路徑內(nèi)容是該訂單對(duì)應(yīng)的 token。ACME 服務(wù)器從公網(wǎng)訪問這個(gè)路徑確認(rèn)你能控制這個(gè)域名。校驗(yàn)通過后CA 簽發(fā)證書Caddy 把證書和私鑰保存到本地?cái)?shù)據(jù)目錄。后續(xù)到續(xù)期時(shí)間Caddy 會(huì)重復(fù)類似流程并熱更新證書。這個(gè)過程和 Certbot 手動(dòng)執(zhí)行沒有本質(zhì)區(qū)別但 Caddy 把它放進(jìn)了服務(wù)器進(jìn)程內(nèi)部。好處是只要 Caddy 進(jìn)程活著續(xù)期這件事就不會(huì)被遺漏。它不需要依賴外部 cron也不需要在系統(tǒng)重啟后人工去檢查。對(duì)健忘的人以及需要長期穩(wěn)定運(yùn)行的小項(xiàng)目來說這太重要了。3. 證書文件、續(xù)期機(jī)制與安全加固的核心細(xì)節(jié)3.1 證書存在哪里怎么備份Caddy 會(huì)把證書和私鑰保存在數(shù)據(jù)目錄里。這個(gè)目錄的位置取決于安裝方式和運(yùn)行用戶。用 Debian 軟件包安裝時(shí)數(shù)據(jù)通常會(huì)在/var/lib/caddy/.local/share/caddy/certificates/下面文件名類似acme-v02.api.letsencrypt.org-directory/example.com/example.com.crt如果是手動(dòng)下載二進(jìn)制并以當(dāng)前用戶運(yùn)行數(shù)據(jù)目錄一般在~/.local/share/caddy/certificates/。不確定的時(shí)候可以用 find 找一下find / -type d -name certificates 2/dev/null | grep caddy找到之后建議把整個(gè)數(shù)據(jù)目錄定期備份。這里面不僅有證書還有 ACME 賬號(hào)私鑰和站點(diǎn)私鑰。換了服務(wù)器或者系統(tǒng)重裝恢復(fù)數(shù)據(jù)目錄就能讓 Caddy 直接復(fù)用原來的證書和賬號(hào)避免重新申請(qǐng)時(shí)碰到頻率限制。備份時(shí)注意私鑰文件權(quán)限最好只讓管理員賬號(hào)能讀不要放進(jìn)公開倉庫。如果你只是把證書文件拷貝出來發(fā)給別人這是不安全的。私鑰一旦泄露任何人都能用它冒充你的站點(diǎn)。Caddy 的自動(dòng) HTTPS 雖然省心但備份策略還是要自己管好。3.2 證書自動(dòng)續(xù)期與熱更新機(jī)制Lets Encrypt 簽發(fā)的證書有效期一般是 90 天所以每隔三個(gè)月就要續(xù)一次。Caddy不會(huì)等到最后一刻才續(xù)它會(huì)在證書有效期剩余一定比例時(shí)開始嘗試通常在證書剩余時(shí)間約 30% 到 40% 時(shí)觸發(fā)也就是證書簽發(fā)后的第 54 到 63 天左右。這個(gè)時(shí)間是隨機(jī)的目的是避免大量服務(wù)器在同一時(shí)刻向 CA 發(fā)起請(qǐng)求。續(xù)期成功之后Caddy 會(huì)把新證書替換到運(yùn)行中的 TLS 配置里這個(gè)過程不需要重啟進(jìn)程也不會(huì)中斷已經(jīng)建立的連接。老連接可以繼續(xù)走老證書新連接開始使用新證書。對(duì)我這種要跑線上服務(wù)的人這種無感替換非常關(guān)鍵。手動(dòng)用 Nginx 續(xù)期雖然也不難但如果沒執(zhí)行 reload新證書就不會(huì)生效折騰完還得驗(yàn)證一下。如果某次續(xù)期失敗了Caddy 不會(huì)直接放棄它會(huì)在后續(xù)周期里繼續(xù)重試并且日志里會(huì)有明確提示。最壞情況下你只需要在 Caddy 日志里看到 error然后去排查 DNS 或端口。等修復(fù)之后它基本能在下一次重試時(shí)把證書續(xù)上。這種“自己會(huì)再來一次”的機(jī)制比手動(dòng)定時(shí)任務(wù)少了很多人為失誤。3.3 安全頭、HTTP/2 與默認(rèn)加固證書是 HTTPS 的第一個(gè)環(huán)節(jié)但 Web 服務(wù)器安全不止證書。Caddy 的默認(rèn)行為已經(jīng)做得比較到位它默認(rèn)開啟 HTTP/2并且會(huì)自動(dòng)把 HTTP 請(qǐng)求跳轉(zhuǎn)到 HTTPS。如果你希望再加一層響應(yīng)頭可以在站點(diǎn)塊里用header指令統(tǒng)一設(shè)置。example.com { root * /srv/example file_server header { Strict-Transport-Security max-age31536000; includeSubDomains X-Content-Type-Options nosniff X-Frame-Options SAMEORIGIN Referrer-Policy strict-origin-when-cross-origin } }Strict-Transport-Security就是常說的 HSTS它會(huì)讓瀏覽器在一段時(shí)間內(nèi)強(qiáng)制使用 HTTPS 訪問站點(diǎn)減少降級(jí)攻擊。X-Content-Type-Options防止瀏覽器自動(dòng)猜測(cè)文件類型X-Frame-Options可以避免頁面被惡意嵌套到 iframe 里。這些頭在 Nginx 里也不是不能配但 Caddy 的寫法更接近“我要什么效果”而不是“我要設(shè)置哪個(gè) HTTP 頭”。還有一個(gè)容易被忽略的點(diǎn)Caddy 會(huì)默認(rèn)在日志里記錄客戶端的真實(shí) IP也會(huì)在反向轉(zhuǎn)發(fā)場(chǎng)景中自動(dòng)處理一些頭部字段。只要你不把敏感信息寫到公開日志里默認(rèn)配置已經(jīng)能滿足大多數(shù)場(chǎng)景。安全不是某一個(gè)功能而是“默認(rèn)會(huì)不會(huì)給你挖坑”。Caddy 在這方面至少不會(huì)故意讓你裸奔。3.4 把 WebDAV 等服務(wù)也納進(jìn)統(tǒng)一 HTTPS 體系我很喜歡 Caddy 的一點(diǎn)是它不只會(huì)托管靜態(tài)網(wǎng)站。只要你能把任意本地服務(wù)跑在某個(gè)端口就能讓 Caddy 作為統(tǒng)一入口為它套上 HTTPS 和安全認(rèn)證。尤其是 WebDAV 這一類需要長期訪問、又不想暴露裸的 HTTP 服務(wù)配到 Caddy 后面非常合適。比如你在本機(jī) 8081 端口跑了一個(gè) WebDAV 服務(wù)域名為dav.example.com。那么 Caddyfile 可以這樣寫dav.example.com { basicauth { alice $2a$14$... } reverse_proxy 127.0.0.1:8081 }basicauth可以先加一層用戶名密碼認(rèn)證密碼哈?？梢杂胏addy hash-password --plaintext 你的密碼生成。reverse_proxy這個(gè)指令負(fù)責(zé)把來自dav.example.com的請(qǐng)求轉(zhuǎn)給本機(jī)的 8081 端口。這樣你不需要在 WebDAV 服務(wù)本身實(shí)現(xiàn) HTTPS也不需要擔(dān)心它被直接暴露到公網(wǎng)Caddy 在前面統(tǒng)一處理了 TLS、認(rèn)證和訪問日志。如果你的 WebDAV 服務(wù)本身不想用插件我其實(shí)更推薦這種方式后端保持簡單前端統(tǒng)一入口。Caddy 替你解決證書和認(rèn)證后端只需要關(guān)心存儲(chǔ)和協(xié)議支持。對(duì)個(gè)人網(wǎng)盤、文件同步、小型協(xié)作場(chǎng)景來說這套組合非常實(shí)用而且全程免費(fèi)。4. 實(shí)操過程一個(gè)靜態(tài)站加后端服務(wù)轉(zhuǎn)發(fā)的典型配置4.1 場(chǎng)景描述與目錄結(jié)構(gòu)現(xiàn)在拿一個(gè)實(shí)際項(xiàng)目來串一遍流程。假設(shè)你有一臺(tái)云服務(wù)器公網(wǎng)域名example.com根目錄/srv/www放著一個(gè)靜態(tài)站點(diǎn)另外有一個(gè) API 服務(wù)跑在127.0.0.1:8080希望只有/api/路徑能訪問到它還有一個(gè) WebDAV 服務(wù)跑在127.0.0.1:8081用獨(dú)立的dav.example.com域名對(duì)外提供。整個(gè)項(xiàng)目要在裸機(jī)上快速上線并且全部啟用 HTTPS。服務(wù)器目錄大概長這樣/srv/www/ ├── index.html ├── assets/ └── ...API 服務(wù)和 WebDAV 服務(wù)都已經(jīng)在本機(jī)端口運(yùn)行Caddy 只負(fù)責(zé)把公網(wǎng)請(qǐng)求轉(zhuǎn)發(fā)給它們。這樣做的好處很明顯后端不需要綁定 80/443 端口不需要處理證書也不容易被掃描器直接攻擊。4.2 Caddyfile 實(shí)例逐行講解把下面的配置寫入/etc/caddy/Caddyfile然后重新加載 Caddyexample.com { root * /srv/www encode zstd gzip handle /api/* { reverse_proxy 127.0.0.1:8080 } handle { file_server } } dav.example.com { basicauth { alice $2a$14$... } reverse_proxy 127.0.0.1:8081 }第一行example.com是站點(diǎn)地址Caddy 會(huì)自動(dòng)為它申請(qǐng)證書。root * /srv/www中的*表示匹配所有請(qǐng)求它告訴 Caddy 文件根目錄在哪。encode zstd gzip開啟壓縮靜態(tài)資源可以節(jié)約流量。handle /api/*表示所有以/api/開頭的請(qǐng)求進(jìn)入這個(gè)塊然后由reverse_proxy 127.0.0.1:8080轉(zhuǎn)給本地 API 服務(wù)。handle不會(huì)自動(dòng)去掉/api/前綴后端收到完整路徑所以你在后端不需要額外改路由。緊接著的handle {}是兜底塊匹配所有剩余請(qǐng)求并用file_server返回靜態(tài)文件。這個(gè)結(jié)構(gòu)用大白話講就是/api/走后端其他路徑走靜態(tài)目錄。第二個(gè)站點(diǎn)塊dav.example.com則更簡單先做 Basic 認(rèn)證再把所有請(qǐng)求轉(zhuǎn)給 8081 端口的 WebDAV 服務(wù)。這里我提醒一下basicauth的密碼哈希不要用明文生產(chǎn)環(huán)境一定要用 Caddy 生成的 bcrypt 哈希。這個(gè)配置看起來不起眼但已經(jīng)包含了 TLS、壓縮、路由、認(rèn)證、后端轉(zhuǎn)發(fā)這些日常最常用的能力。4.3 啟動(dòng)、重載與排錯(cuò)命令寫完配置不要直接重啟先校驗(yàn)一下格式。Caddy 提供了兩個(gè)很有用的命令caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile caddy fmt --overwrite /etc/caddy/Caddyfilevalidate會(huì)解析配置并報(bào)告語法錯(cuò)誤或語義沖突fmt會(huì)統(tǒng)一格式。對(duì)我來說改完配置先 validate 已經(jīng)成為習(xí)慣了特別是改動(dòng)結(jié)構(gòu)比較大的時(shí)候可以避免因?yàn)樯賹懸粋€(gè)括號(hào)導(dǎo)致服務(wù)起不來。確認(rèn)沒問題后用系統(tǒng)服務(wù)重載sudo systemctl reload caddy如果你不是用系統(tǒng)服務(wù)而是手動(dòng)caddy run可以替代為caddy reload。重載過程中 Caddy 會(huì)平滑應(yīng)用新配置不會(huì)中斷已有連接。如果配置有誤進(jìn)程會(huì)保留舊配置繼續(xù)運(yùn)行不會(huì)讓你一頭撞死在線上。排查日志時(shí)用journalctl -u caddy -f這個(gè)命令會(huì)持續(xù)輸出 Caddy 日志。證書申請(qǐng)、續(xù)期、轉(zhuǎn)發(fā)錯(cuò)誤、ACME 校驗(yàn)失敗都會(huì)在這里顯示。我第一次配 WebDAV 的時(shí)候日志里總是報(bào) 401后來發(fā)現(xiàn)是basicauth的密碼哈希沒有更新重新生成一次就正常了。日志不是可看可不看的遇到問題第一反應(yīng)就是開日志。4.4 驗(yàn)證 HTTPS 與證書狀態(tài)配置好之后用瀏覽器打開https://example.com能看到鎖圖標(biāo)就說明證書生效。如果還想在命令行確認(rèn)證書有效期可以用openssl s_client -connect example.com:443 -servername example.com 2/dev/null | openssl x509 -noout -dates輸出里會(huì)顯示證書的開始時(shí)間和結(jié)束時(shí)間。只要結(jié)束時(shí)間在差不多三個(gè)月以后說明當(dāng)前證書是剛申請(qǐng)或者剛續(xù)過的。對(duì)于 Caddy 自動(dòng)續(xù)期的站點(diǎn)你不需要經(jīng)?？催@個(gè)但偶爾確認(rèn)一下能放心。再測(cè)試一下跳轉(zhuǎn)是否正常curl -I http://example.com正常情況下應(yīng)該看到類似301 Moved Permanently的響應(yīng)并且Location指向https://example.com。這就是 Caddy 默認(rèn)的 HTTPS 跳轉(zhuǎn)行為。如果這一步?jīng)]生效多半是全局配置里把自動(dòng)跳轉(zhuǎn)關(guān)掉了或者 80 端口沒有正常放行。5. 常見問題與排查技巧實(shí)錄5.1 證書申請(qǐng)失敗證書申請(qǐng)失敗是新手最容易碰到的問題。我把最常見的幾種原因整理成一個(gè)速查表現(xiàn)象可能原因解決辦法日志提示 timeout 或 connection refused80 端口不通檢查云安全組、防火墻、端口映射日志提示 no A recordDNS 沒解析到本機(jī)用dig確認(rèn)解析記錄日志提示 invalid responseCDN 或反向接入層干擾校驗(yàn)首次申請(qǐng)時(shí)暫時(shí)關(guān)閉 CDN 加速證書一直不成功但端口正常公網(wǎng) IP 被墻或網(wǎng)絡(luò)策略限制檢查服務(wù)器出口以及對(duì) ACME 服務(wù)器的連通性提示 rate limit同一域名申請(qǐng)?zhí)l繁使用 Caddy 的 staging CA 測(cè)試避免打正式額度如果你只是想測(cè)試配置可以使用 Lets Encrypt 的 staging 環(huán)境在 Caddy 全局配置里加一條{ acme_ca https://acme-staging-v02.api.letsencrypt.org/directory }這個(gè)環(huán)境簽發(fā)的證書瀏覽器不信任只適合測(cè)試流程。等確認(rèn)一切正常記得刪掉這行再重新申請(qǐng)正式證書。通過 staging 環(huán)境可以大幅降低遇到頻率限制的概率尤其適合反復(fù)調(diào)試的場(chǎng)景。5.2 后端轉(zhuǎn)發(fā)時(shí)的真實(shí) IP 與 WebSocket當(dāng)你用 Caddy 把請(qǐng)求轉(zhuǎn)給本地后端服務(wù)時(shí)后端日志里可能只看到127.0.0.1因?yàn)檫B接確實(shí)來自 Caddy 進(jìn)程。為了讓后端拿到真實(shí)客戶端 IPCaddy 會(huì)在轉(zhuǎn)發(fā)時(shí)帶上X-Forwarded-For、X-Forwarded-Proto等頭部。如果你的后端框架默認(rèn)信任這些頭日志里就會(huì)顯示真實(shí) IP如果后端在更復(fù)雜的網(wǎng)絡(luò)環(huán)境里可能還需要顯式配置信任范圍。WebSocket 是另一個(gè)容易踩坑的地方。很多 Web 服務(wù)需要長連接比如實(shí)時(shí)通知、在線終端。Caddy 的reverse_proxy對(duì) WebSocket 支持是開箱即用的不需要額外插件也不需要特殊配置。只要后端支持 WebSocketCaddy 會(huì)自動(dòng)升級(jí)連接并保持轉(zhuǎn)發(fā)。我第一次配的時(shí)候以為要寫什么特殊指令結(jié)果發(fā)現(xiàn)什么都不用做把請(qǐng)求轉(zhuǎn)過去就通了。不過有一點(diǎn)需要注意如果前端有多層轉(zhuǎn)發(fā)結(jié)構(gòu)每一層都應(yīng)該正確傳遞X-Forwarded-*頭部否則最終服務(wù)拿到的 IP 可能不準(zhǔn)。Caddy 在這方面的默認(rèn)行為對(duì)大多數(shù)場(chǎng)景夠了但如果你在云負(fù)載均衡后面最好檢查一下各層頭部策略。5.3 權(quán)限、內(nèi)存與長期運(yùn)行Caddy 是 Go 編寫的東西編譯成單一二進(jìn)制資源占用相對(duì)克制。我見過一個(gè)只托管靜態(tài)文件的 Caddy 實(shí)例內(nèi)存長期在 30MB 到 50MB 左右和一套全家桶方案比起來輕得多。如果還需要處理并發(fā)和壓縮內(nèi)存會(huì)高一些但總體還是可控的。權(quán)限問題也需要留意。如果你用非 root 用戶手動(dòng)運(yùn)行 Caddy又想監(jiān)聽 80 和 443 端口一般需要提權(quán)才能綁定到低端口。Linux 上可以用setcap給二進(jìn)制分配net_bind_service能力sudo setcap cap_net_bind_serviceep /usr/bin/caddy如果是通過官方軟件包安裝systemd 服務(wù)通常已經(jīng)處理了這些權(quán)限問題。數(shù)據(jù)目錄的屬主也要和運(yùn)行用戶一致否則 Caddy 可能沒有權(quán)限寫入證書和日志。日志和證書文件的權(quán)限是最容易被忽略的一旦出現(xiàn)“permission denied”優(yōu)先檢查服務(wù)用戶和目錄所有者。長期運(yùn)行的系統(tǒng)定期看一眼日志還是有必要的。Caddy 的默認(rèn)日志不算吵但如果某個(gè)后端服務(wù)頻繁超時(shí)日志里會(huì)不斷刷錯(cuò)誤。你可以通過日志輪轉(zhuǎn)來避免磁盤被撐滿也可以在配置里按需調(diào)整日志級(jí)別?？傊詣?dòng) HTTPS 不等于“完全不看服務(wù)器”而是把最繁瑣的證書操作從你的待辦事項(xiàng)里刪掉。最后再分享一點(diǎn)我的實(shí)際體會(huì)Caddy 不是萬能的如果你需要極度復(fù)雜的條件路由、自定義模塊組合或者有專門的性能調(diào)優(yōu)需求原來的 Nginx 體系也許更合適。但對(duì)我這種“想把站點(diǎn)快速安全跑起來不想被證書和 reload 折磨”的人來說Caddy 的體驗(yàn)確實(shí)是目前最舒服的。我現(xiàn)在把個(gè)人博客、內(nèi)部工具、WebDAV 都掛在一臺(tái)小服務(wù)器上一個(gè) Caddyfile 管到底證書從沒手動(dòng)續(xù)過。最后一個(gè)小建議把 Caddyfile 納入 git 管理每次改完先caddy validate再 reload這樣哪怕改壞也能快速回滾。希望這篇實(shí)操筆記能讓你少走一些我走過的彎路。