감사합니다. 그 PR을 아직 보지 못했습니다. 흥미롭네요. 제 환경은 Discourse의 nginx 웹 서버를 그대로 두고 Caddy를 Docker Compose에서 별도로 실행하여 그 앞에 배치한 점이 약간 다릅니다. 주로 엣지에서 HTTP/3를 제공하기 위해서입니다.
Discourse 측에서 작은 변경 사항이 하나 있습니다. 유닉스 소켓을 통해 요청이 들어올 때 nginx가 실제 클라이언트 IP로 Caddy의 X-Forwarded-For 값을 사용하도록 영구적인 app.yml 훅을 추가했습니다. 처음에는 Caddy의 X-Real-IP 우회 설정이 필요했지만, nginx 측 수정 사항을 추가한 후 이를 제거하고도 Discourse가 여전히 올바른 클라이언트 IP를 기록하는지 확인했습니다.
또한 Caddy 설정에서 HTTP/3은 활성화한 채로 QUIC 0-RTT/early data를 명시적으로 비활성화하여, 추가적인 early-data 엣지 케이스를 피했습니다.
제 방식은 사이트 레벨에서 Caddy의 HTTP 액세스 로깅도 활성화하여, Caddy의 기본 민감한 자격 증명 헤더 마스킹(redaction) 기능을 제공합니다. 생성된 Docker json-file 로그는 25 MB × 3 기준으로 로테이션합니다. 현재 해당 PR에는 로테이션 로그 블록이 Caddy의 전역 옵션에 있는 것을 확인했는데, Caddy 문서에서는 이를 런타임 로깅 설정으로 설명하고 HTTP 액세스 로깅 설정으로 설명하지 않습니다.
따라서 완전히 손대지 않은 표준 설치와는 약간 다르지만, nginx를 Caddy로 완전히 교체하는 방식과는 다른 접근법입니다.
해당 PR을 더 자세히 살펴보겠습니다. 당장은 바로 가이드를 작성하기보다는, 이 접근법에 대한 충분한 관심이 있는지, 단계별 가이드를 만드는 것이 가치가 있는지 확인하는 데 주로 관심이 있습니다.