Caddy 是由 caddyserver 社群維護的開源網頁伺服器，在 GitHub 累積 76,987 顆星標與 5,069 次複製。2026 年 10 月 3 日，專案發布 v2.11.7 修補版本，修復 2.11.6 引入的 HTTP/2 代理崩潰與串流中斷問題，同時新增對 RFC 10036「Incremental」標頭的支援，把原先由 NGINX 專有的 X-Accel-Buffering 做法納入公開標準。此次更新延續 Caddy 以自動 HTTPS 為預設、以單一設定文件為核心的技術路線。
Caddy v2.11.7 於 2026 年 10 月 3 日發布，修復 HTTP/2 代理崩潰與串流中斷，並新增 RFC 10036 的 Incremental 標頭支援。
Caddy 是什麼？
Caddy 是 Go 語言撰寫的開源網頁伺服器平台，預設自動取得並更新 TLS 憑證，支援 HTTP/1.1、HTTP/2 與 HTTP/3，採 Apache-2.0 授權。
依照官方說明，Caddy 是一套可擴充的伺服器平台，最大特點是預設啟用 TLS，所有站台在未經額外設定下即會自動取得憑證。它支援公開網域由 ZeroSSL 與 Let’s Encrypt 簽發憑證，內部名稱與 IP 則由本機 CA 管理，並可在多台 Caddy 執行個體之間協調簽發，具備多發行者備援能力。
Caddy 提供兩種設定方式。Caddyfile 以簡潔的區塊語法描述站台，適合快速上手；原生 JSON 設定則提供完整控制，可涵蓋處理器、TLS 握手與儲存後端等所有細節。專案同時提供 JSON API 進行線上設定變更，以及設定適配器，把 Caddyfile、YAML、TOML、JSON 5 甚至 NGINX 設定轉換為原生格式。
專案由 Matthew Holt 於 2014 年在楊百翰大學就讀期間開始開發，名稱取自協助處理繁瑣事務的意涵。Caddy 是第一個預設自動使用 HTTPS 的網頁伺服器，至今有逾四百位貢獻者，累計處理數兆次 HTTPS 請求。名稱「Caddy」已註冊商標，專案隸屬於 ZeroSSL 母公司 HID Global 旗下的 Stack Holdings GmbH。
Caddy 2.11.7 發布了哪些重點更新？
v2.11.7 修復 2.11.6 造成的 HTTP/2 代理崩潰、SSE 串流滿 60 秒中斷與 Cookie 佔位符為空等問題，並新增 RFC 10036 標頭支援。
本次修補的核心，是修正 2.11.6 引入閒置逾時機制後產生的連帶問題。在 HTTP/2 環境下，若反向代理仍在讀取請求主體而處理常式已經返回，Caddy 可能因空指標而崩潰；在 HTTP/1.1 環境下，以 POST 開啟串流的 SSE 用戶端，會在主體讀取完成後恰好 60 秒被截斷。兩項問題已於對應的提交中修復，官方建議仍在使用 2.11.6 的部署儘速升級。
另一個問題是 Cookie 佔位符的行為。自 2.11.6 起，保留未知佔位符的指令如 respond 標頭，會在 Cookie 不存在時直接輸出 {http.request.cookie.*} 字面文字，純 HTTP 請求的 TLS 佔位符也有相同情況。此版本讓這些欄位恢復為空值。此外，設定中多個 Set-Cookie 值過去會被合併為單一欄位，導致用戶端無法解析，現已改為分開傳送。
效能方面，當沒有事件訂閱者且除錯記錄關閉時，CertMagic 不再為每次握手建立事件資料，憑證查找速度約提升一倍，配置次數由 15 次降至 10 次。Unix 通訊端在重新載入後會立即關閉並移除舊檔案，不再讓用戶端等待約兩分鐘的回收週期。命令列工具 caddy fmt 亦修正了輸入結尾大括號被刪除的問題。
RFC 10036 的 Incremental 標頭是什麼？
Incremental 是 RFC 10036 定義的回應標頭，用來指示代理與伺服器立即轉發串流內容，取代 NGINX 專有的 X-Accel-Buffering 做法。
Incremental 是 IETF 發布的 RFC 10036 中所定義的新標準標頭，用途是告知中介層與伺服器：這段回應應該邊產生邊送出，不應在緩衝區累積後才轉發。過去要做同樣的事，實務上依賴 NGINX 專有的 X-Accel-Buffering 標頭，該做法並非公開標準，其他伺服器與代理無法通用，跨元件部署時容易出現行為差異。
在 Caddy 的實作中，若上游回應帶有 Incremental: ?1，reverse_proxy 會立即轉發，效果等同於原本的 flush_interval -1；encode 指令也會改為串流輸出，而非先壓縮後整批送出。這對 Mercure、伺服器推送事件與其他即時串流應用特別有利，因為延遲取決於第一個位元組送出的時間。
若設定中的 request_buffers 或 response_buffers 會阻止增量轉發，Caddy 會依 RFC 要求回應 501 Not Implemented，而非默默改為緩衝；新增的 proxy_status_name 選項則會在該回應加上 Proxy-Status 標頭，說明拒絕轉發的原因。這項功能由社群貢獻者 dunglas 提交，也是 v2.11.7 最具標準意義的改動。
Caddy 的架構與技術特色有哪些？
Caddy 採模組化架構，內建 tls 與 http 兩個應用，以 JSON 為原生設定格式，並可透過設定適配器轉換 Caddyfile、YAML 或 NGINX 設定。
Caddy 本質上是一個執行 Go 應用程式的平台，所謂的 Caddy app 就是以模組形式實作的 Go 程式。標準發行版內建 tls 與 http 兩個應用，所有應用共用線上設定變更、自動產生文件與其他應用整合等能力。這種設計讓擴充不必更動核心，社群可透過外掛補上快取、身分驗證或特定後端整合。
在設定管理上，Caddy 幾乎把所有組態集中於單一文件中，而非分散在命令列旗標、環境變數與設定檔之間。官方指出這種做法可降低隱藏變數與隱性因素，讓伺服器狀態更容易掌握。相較於多數伺服器以設定檔為唯一入口，Caddy 以 API 為主要設定途徑，設定檔則由命令列工具載入。
執行特性方面，Caddy 沒有外部相依，連 C 標準函式庫都不需要，可在各種平台直接執行。它預設同時支援 HTTP/1.1、HTTP/2 與 HTTP/3，官方表示已在生產環境中服務數兆次請求、管理數百萬張 TLS 憑證，並能擴展至數十萬個站台。憑證事件、TLS 設定與 OCSP 相關問題發生時，Caddy 仍會持續運作，不會因單一環節異常而中斷服務。
Caddy 在市場與生態中扮演什麼角色？
Caddy 與 NGINX、Apache 並列主流網頁伺服器，以自動 HTTPS 與簡潔設定在容器與邊緣部署場景取得份額，並帶動 CertMagic 等周邊生態。
在網頁伺服器市場中，Caddy 的定位不是替換既有伺服器的通用方案，而是以設定簡潔與憑證自動化切入特定場景。對於站台數量多、憑證輪換頻繁、或部署環境以容器為主的團隊，自動 HTTPS 省下的維運成本相當直接；相對地，需要高度客製模組或既有 NGINX 設定的組織，遷移成本仍是主要考量。
生態層面上，Caddy 帶動了憑證管理函式庫 CertMagic 的發展，該函式庫獨立供應，也被其他 Go 專案採用。專案同時提供 xcaddy 建置工具，讓使用者能把自選外掛編譯進單一執行檔，這是 Caddy 有別於多數伺服器的擴充路徑。套件託管由 Cloudsmith 提供，企業若需商業支援，官方建議透過 Ardan Labs 簽訂支援合約。
商業模式方面，Caddy 以開源專案搭配贊助與支援服務運作，專案為 ZeroSSL 及 HID Global 旗下資產。官方文件提到，企業若因 Caddy 受益，可考慮贊助以支持全職維護，並換取私人協助與資源。這種由公司持有商標、社群維持開發的模式，與多數大型開源基礎設施的治理方式一致。
如何安裝與開始使用 Caddy？
使用者可從 GitHub Releases 下載執行檔並放入 PATH，或以 Go 1.26.0 以上版本自行編譯；官方建議先完成 Getting Started 教學以熟悉設定。
最簡單的跨平台安裝方式，是從 GitHub Releases 下載對應平台的執行檔，放入系統 PATH 後即可執行。官方網站另提供各作業系統的安裝說明，涵蓋套件管理器與容器映像等途徑。首次使用時，官方建議不論經驗程度都先完成 Getting Started 教學，以理解 Caddy 的運作方式。
若需自行編譯，專案要求 Go 1.26.0 或更新版本。開發用途可直接在 cmd/caddy 目錄執行建置，但官方提醒這種方式不會嵌入正確的版本資訊；若需要版本資訊或加入外掛，應改用 xcaddy 建置工具，它會自動完成建立目錄、初始化模組、鎖定版本與編譯等步驟。
在 Linux 上，Caddy 可能嘗試綁定低連接埠，若系統要求較高權限，可透過 setcap 指令授予網路綁定能力，或使用專案附帶的 setcap.sh 配合 go run 執行。官方特別提醒，相關權限設定僅為便利而提供，使用者應自行理解系統工具的行為與風險。
出處連結有哪些？
本文資訊整理自 Caddy 的 GitHub 儲存庫、v2.11.7 發布說明與官方網站文件，內容涵蓋版本更新、技術架構與安裝方式。
- 76,987GitHub 星標
- 5,069複製次數
- 447貢獻者
- 2,729提交次數
- Go主要語言
- Apache-2.0授權條款
- v2.11.7最新版本
- GitHub 儲存庫：https://github.com/caddyserver/caddy
- v2.11.7 發布說明：https://github.com/caddyserver/caddy/releases/tag/v2.11.7
- 官方網站與文件：https://caddyserver.com/docs/
常見問題有哪些？
Caddy 的常見疑問集中在授權條款、版本選擇、與 NGINX 的差異及憑證簽發方式，多數可從官方文件與發布說明找到答案。
Caddy 是免費的嗎？
是。Caddy 以 Apache-2.0 授權開源，可免費用於商業專案。企業若需要商業支援，官方建議透過 Ardan Labs 簽訂支援合約。
Caddy 與 NGINX 有什麼主要差異？
Caddy 預設自動取得並更新 TLS 憑證，設定集中於單一文件並以 API 為主要入口；NGINX 則以設定檔為核心，憑證管理通常需額外工具協助。
應該選擇哪個 Caddy 版本？
建議使用最新的 v2.11.7。官方明確表示，若部署仍為 2.11.6，應儘速升級，以修復 HTTP/2 代理崩潰與串流中斷問題。
Incremental 標頭需要手動設定嗎？
上游應用需在回應加上 `Incremental: ?1`，Caddy 才會立即轉發；若設定中的緩衝選項會阻止增量轉發，Caddy 會回傳 501 而非默默緩衝。
Caddy 的憑證由誰簽發？
公開網域預設由 ZeroSSL 與 Let's Encrypt 簽發，並支援多發行者備援；內部名稱與 IP 則由本機 CA 管理，無需對外連線。
Caddy 適合大型部署嗎？
官方指出 Caddy 已在生產環境處理數兆次請求、管理數百萬張憑證，並可擴展至數十萬個站台，具備大型部署的實績。
總結：Caddy 適合什麼樣的團隊？
Caddy 適合希望以最簡設定取得自動 HTTPS、串流代理與 HTTP/3 支援的團隊，尤其適合容器化與多站台部署情境。
Caddy 這次更新的價值，在於把長年存在於特定伺服器的私有做法，推進為可互通的新標準。Incremental 標頭進入 RFC 之後，即時串流與伺服器推送事件的轉發行為不再需要依賴單一實作，跨元件的部署組合也能維持一致。同時，2.11.7 迅速修補前一版的逾時迴歸問題，反映專案在引入新機制後仍維持密集的修補節奏。
對正在評估網頁伺服器的團隊而言，Caddy 的判斷點相對清楚：若維運痛點在於憑證輪換與設定複雜度，其自動 HTTPS 與單一設定文件能直接降低負擔；若既有架構已深度綁定其他伺服器的模組或設定，遷移成本則需要一併評估。以 76,987 顆星標、447 位貢獻者與十年的維護紀錄來看，Caddy 已具備作為長期基礎設施的成熟度。