ありがとうございます、そのPRは見ていませんでした。興味深いですね。私の環境は少し異なり、Discourseのnginx Webサーバーをそのまま残し、CaddyをDocker Composeで別途実行して、主にエッジでHTTP/3を提供しています。
Discourse側には小さな変更が1つあります。Unixソケット経由でリクエストが届いた際に、nginxがCaddyのX-Forwarded-For値を実クライアントIPとして使用するように、永続的なapp.ymlフックを追加しました。当初はCaddyのX-Real-IPワークアラウンドが必要でしたが、nginx側の修正を追加した後、それを削除してDiscourseが正しいクライアントIPを記録していることを確認できました。
また、Caddyの設定でQUIC 0-RTT/早期データを明示的に無効にし、HTTP/3は有効のままにしました。これは、追加の早期データのエッジケースを避けるためです。
私のアプローチにより、CaddyのHTTPアクセスログをサイトレベルで有効にすることができ、これにより機密性の高い認証情報ヘッダーのCaddyデフォルトのマスク処理が得られます。生成されるDockerのjson-fileログは25 MB × 3でローテーションしています。現在、PRにはCaddyのグローバルオプションにログローテーションブロックが含まれていますが、Caddyのドキュメントでは、これはランタイムログの設定であり、HTTPアクセスログの設定ではないと説明されています。
したがって、完全に untouched の標準インストールというわけではありませんが、nginxをCaddyに完全に置き換えるアプローチとも異なります。
そのPRを詳しく見てみます。現時点では、すぐにガイドを作成するよりも、このアプローチに関心がある人が十分いて、ステップバイステップのガイドを作成する価値があるかどうかを主に確認したいと考えています。