Hacker News 의견

• Caddy는 개발 중 HTTP2로 API를 로컬 테스트할 때 매우 유용함

  • 대부분의 개발 서버는 HTTP1만 지원하여 로컬호스트에 최대 6개의 동시 연결만 가능함
  • HTTP2는 SSL이 필요하여 로컬에서 테스트/설정하기 번거로움
  • Caddy 리버스 프록시를 사용하면 OS 신뢰 저장소에 루트 인증서를 설치하여 HTTP2를 즉시 사용할 수 있음
  • ElectricSQL은 사용자에게 이를 추천하며, HTTP2는 6개의 동시 연결을 잠그지 않음
  • Vite 앞에 Caddy를 배치하면 리로드가 훨씬 빨라짐
  • Vite는 브라우저에서 개별 파일을 로드하는 JS 모듈 시스템을 사용하며 HMR을 지원함
  • HTTP2를 통해 Caddy를 Vite 앞에 두면 이러한 문제를 모두 해결할 수 있음

• nginx에서 caddy-docker-proxy로 전환한 후 Pangolin으로 이동하여 매우 만족스러움

  • Pangolin은 traefik의 프론트엔드로, 내장 인증과 Wireguard를 통한 트래픽 터널링 기능을 제공함
  • Minecraft 서버를 위한 TCP 포워딩이 필요했으며, 이를 매우 간단하게 해결함
  • Nginx Proxy Manager의 더 나은 버전을 원하는 사람에게 추천함
  • 문서가 아직 부족하지만, 유지 관리자는 Discord에서 매우 도움을 줌

• Caddy에 대해 나쁜 말을 할 수 없지만, Nginx보다 인증서 설정이 더 쉬운 것이 유일한 장점으로 들림

  • Kubernetes 클러스터를 몇 년 전에 자동으로 인증서를 생성하고 갱신하도록 구성함
  • Ingress를 통해 모든 것이 처리되며, Nginx 로드 밸런서를 새 도메인에 지정하면 알아서 처리됨
  • 로컬 HTTPS가 자주 필요하지 않지만, 필요할 때는 외부 접근도 필요함
  • Nginx를 실행하는 서버를 사용하여 로컬호스트로 프록시함
  • 이 방법이 나에게는 잘 맞으며, 바꿀 이유가 없기 때문에 계속 사용할 것임

• Caddy를 매우 좋아하며, 몇 년 동안 사용해왔음

  • 매우 신뢰할 수 있으며 기본을 배우면 설정이 매우 쉬움
  • 문서가 조금 어렵지만, NGINX 위에 letsencrypt를 신뢰성 있게 작동시키려는 것보다 훨씬 많은 시간과 에너지를 절약함

• 친근한 라이선스(Apache v2)도 중요하며, 특히 Caddy의 모듈식 아키텍처와 관련이 있음

  • Caddy 주변의 생태계가 더 간단하고 안전하게 만들어짐
  • 예를 들어, 인터넷 클라이언트를 제공하면서 서버를 비공개로 유지함
  • Tailscale이나 OpenZiti와 같은 VPN이 이에 해당함

• 자동 HTTPS는 모든 사이트에 대해 TLS 인증서를 제공하고 갱신함

  • HTTP를 HTTPS로 자동으로 리디렉션함
  • 도메인의 IP를 Caddy에 지정할 때, 첫 번째 HTTPS 호출 시 인증서가 즉석에서 생성되는지 궁금함
  • apex 도메인을 www로 리디렉션해야 하는 필요성 때문에 중요함
  • 무료로 제공되는 서비스로 해결할 수 있지만, Caddy를 사용하면 더 간단할 수 있음

• 웹사이트를 처음부터 끝까지 읽고 나니 프로젝트의 신뢰성에 대해 확신이 서지 않음

  • 너무 자화자찬하는 내용이 많아 불쾌한 느낌이 남음
  • 저자들이 알려진 단점에 대해 솔직하지 않을 것 같음
  • 과거에 어떻게 공개했는지 아는 사람이 있는지 궁금함

• Caddy와 Caddy-Docker-Proxy를 결합하여 여러 도커 프로젝트가 있는 서버를 설정하는 훌륭한 방법임

  • 몇 대의 서버에서 실행 중이며 잘 작동함

• Caddy를 사랑함

  • 2년 전 NGINX/OpenResty에서 전환했으며, 설정이 훨씬 간단해짐
  • lua-resty-auto-ssl을 사용했지만, 이제는 사용하지 않음
  • 매달 70,000명의 방문자를 잘 처리함

• Traefik은 훌륭한 대안임

  • 몇 년 동안 v1과 v2를 사용해왔으며, 도커 레이블을 사용하여 서비스 구성을 함