【要注意】Caddy v2.11でHostヘッダーの転送仕様がサイレント変更！既存のHTTPSバックエンドに影響あり

「セキュリティ」のためにHTTPSでしか公開してないWebサービスがいくつかあって、リバースプロキシがすごく面倒になるんだよね。ある書籍管理のUIなんかもそうだ。OPNsenseのデフォルトも自己署名証明書だし。

内部CAをデプロイして頑張ることもできるけど、HTTPSエンドポイントをそのまま使ってCaddy経由で転送して、ドメイン名を統一しちゃうほうが楽なことが多いよ。

どっちの指摘もその通りだね。特に「ひどい変更」ってところ。リバースプロキシのデフォルト設定が変わる最悪のケースって、まさにこういうやつだよ。リクエストはアップストリームまで届くのに、Hostヘッダーがvhostと一致しなくてルーティングや認証が静かに壊れるっていう。UniFiコントローラー、Proxmox VE、OPNsense、vCenterなんかは全部バックエンドで自己署名証明書によるHTTPSを強制してくるから、先週全部こっそり動かなくなって大変だったよ。2.11に原因があるって特定するまでかなり時間かかったし。リリースノートに一言書いておいてくれれば、数時間のロスが防げたのにな。

Caddyでの通常のリバースプロキシ設定はこんな感じだね。

photos.example.com {
  reverse_proxy immich_server:2283
}

これは何の問題もない。バックエンドのImmichのWebサーバー側がHTTPSやTLS暗号化なしで応答しているからね。ほとんどのサービスはこうなってるよ。開発者だって、デプロイ時にリバースプロキシでHTTPS化する人が多いってわかってるから、自分たちでわざわざ面倒なことをしたくないんだよ。

ただ、セキュリティのためにHTTPSでしか公開しないって決めてるWebサーバーもある。そういうのは独自の証明書やTLSを使っていて、設定には少し手間がかかる。Caddyfileに数行追加して、「これはHTTPSで通信するから、Webサーバー側の証明書が正しくなくても気にしなくていいよ（Caddy自体の証明書が正しければ問題ないから）」って教えてやる必要があるんだ。OPの投稿にあるような設定だね。見た目は少しゴチャゴチャしてて冗長だけど、問題はないよ。

というわけで、自分のCaddyfileを見て tls_insecure_skip_verify なんて記述がどこにもないなら、今まで対応する必要がなかったってことだし、これからも何もする必要はないよ。

ちなみに自分はCrafty（Minecraft）とWireguard-easyだけはHTTPSオンリーだから、それらには header_up Host {host} を追加する必要があったな。

自分のサービスの一部はこんな感じで設定してるよ。

transport http {
  tls_insecure_skip_verify
}

ただ、DNSチャレンジでLet's Encryptの正規証明書を使ってるし、HTTPS化もできてるから、この設定が本当に必要なのか自信がないんだよね。NPMからCaddyへの移行をClaudeに手伝ってもらった時、彼が勝手に追加したんだ。

一度削除してCaddyをリロードして、動くかどうか試してみればいいよ。動かなくなったら、そのサービスはHTTPSでしか応答していないってことだね。

理解しておくべきなのは、これはあくまでCaddyとコンテンツを持つWebサーバー（アップストリーム）間の通信の話だってこと。CaddyとHTTPS証明書の話をするときは、普通はエンドユーザー（スマホでネットを見てるおばあちゃんとか）がURLにアクセスして、Caddyまで安全にHTTPSで到達して、そのあとCaddyがWebサーバーと安全に通信するかどうか、という部分を指すからね。

そうは思わないな。