自動化 HTTPS 網站伺服器 - Caddy Server

這應該是這波 Reverse Proxy 評估的最後一篇，打鐵趁熱，把本次蒐集到的情資一次檢視完。

一樣是分享 HTTPS Nginx Docker 懶人安裝法時有讀者推薦，不沾手實現 HTTPS 的方便選擇 - Caddy Server。

閒扯淡：Caddy 這個命名真的不優，Google 查「Caddy」盡是福斯休旅車，所以，啟動專案前，花點時間取個好 Google 不撞名的代號很重要，別讓菜市場名成為推廣的絆腳石啊! 繼續看，Caddy 是用 GO 寫的，連程式語言的名字也...

Caddy 使用 GO 開發，標榜功能強大達到企業商用等級，且支援自動化 HTTPS 的開源網站伺服器。依 W3Tech 統計，2022/12 在網站伺服器的市佔擠到前十，但僅 0.1% 仍屬小眾選擇：

參考網路教學，我在 Azure VM 裝了 Caddy Docker 容器小玩一下。

先準備 docker-compose.yml 如下：(教學範例還掛了另一個 portainer 容器共用名為 caddy 的網路做展示，我改成只跑 Caddy Server，範例站台則改用 ASP.NET Core 另外執行，屆時 Reverse Proxy 比照 Nginx Proxy Manager 文章走 10.3.0.4 5000 Port)

version: '3.3'
networks:
  caddy:
services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    container_name: caddy
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./site:/srv
      - ./caddy_data:/data
      - ./caddy_config:/config
    networks:
      - caddy
volumes:
  caddy_data:
    external: true
  caddy_config:

volumes 要設定一些映對路徑，site、cadd_data、caddy_config 等目錄供 Caddy 寫入設定、 Log、憑證等資料，Reverse Proxy 設定則寫在 Caddyfile，包含 Let's Encrypt 註冊用 Email，以及哪個網域名稱對映到哪個 IP 哪個 Port，超級精簡，沒半句廢話：

{
    email email_for_letsencrypt@mail.com
}
my-server.location.cloudapp.azure.com {
    reverse_proxy 10.3.0.4:5000
}

短短六行，範例 ASP.NET Core 網站已自動啟用 HTTPS。

不過，使用 Nginx 時要另外設定 X-Forwarded-From 等 Header。查了一下 Caddy 似乎會自動加入不需額外設定。為驗證這點，我改跑以下 Minimal API 聽 5000 Port 檢查 Caddy 帶入的 Header：

using System.Text.Json;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", async (HttpRequest req, HttpResponse resp) => {
    //read all request headers and return them as a JSON object
    var headers = req.Headers.ToDictionary(h => h.Key, h => h.Value.ToString());
    await resp.WriteAsJsonAsync(headers, new JsonSerializerOptions { WriteIndented = true });
});

經實測，Caddy 的確已自動加上 X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Proto 三個 Request Header：

【心得】

Caddy Server 設定 Reverse Proxy 的方法，簡潔到讓人驚豔，也確實能無腦啟用 HTTPS，作為 ASP.NET Core 或一般網站的 Reverse Proxy 非常省事方便。至於缺點，Caddy 在效能上小輸 Nginx，Golang 很強，但用 C 寫的 Nginx 更威，萬夫莫敵。另一方面，Caddy 較年輕，功能及套件不如 Nginx 豐富。若要用在工作上，則還要面對主管或企業主「小眾選擇 vs 主流產品」的質疑。若無前述考量，Caddy 的簡單易用真的很吸引人，能不能用該不該用，看緣份吧。