谢谢，我之前没看到那个 PR。这很有趣——我的设置略有不同，因为我保留了 Discourse 自带的 nginx Web 服务器，并在其前面通过 Docker Compose 单独运行 Caddy，主要是为了在边缘提供 HTTP/3 支持。
这里有一个小的 Discourse 端改动：我添加了一个持久的 app.yml 钩子，以便在请求通过 Unix 套接字到达时，nginx 使用 Caddy 的 X-Forwarded-For 值作为真实的客户端 IP。我最初需要 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 访问日志。
因此，这并非完全未修改的标准安装，但它也不同于完全用 Caddy 替换 nginx 的做法。
我会仔细查看那个 PR。目前我主要感兴趣的是，这种方法是否有足够的关注度，使得编写分步指南值得去做，而不是立即开始编写。