Caddy 와 nginx — 비교의 자리
Caddy 와 nginx — 비교의 자리
리버스 프록시 · HTTPS 종단 · 정적 파일 서빙은 거의 모든 웹 서비스의 공통 자리. nginx 가 오랜 표준이었고, 그 사이에 자동 HTTPS 와 단순한 설정을 강조하는 Caddy 가 자리를 넓혔습니다. 이 글은 두 도구의 출자 · 자동 HTTPS 의 의미 · 문법 차이 · 이웃 도구 (traefik · HAProxy) · 리버스 프록시와 로드밸런서의 구분.
1. 두 도구에 대한 이야기
| 도구 | 첫 등장 | 메모 |
|---|---|---|
| nginx | 2004, Igor Sysoev | C 작성. 이벤트 기반. 2019 F5 인수. |
| HAProxy | 2001 (1.0), Willy Tarreau | C 작성. L4 / L7 로드밸런서로 시작. |
| Caddy | 2015, Matt Holt | Go 작성. v2 (2020) 에서 큰 재설계. 자동 HTTPS 를 1급 기능으로. |
| traefik | 2015, Containous (현 Traefik Labs) | Go 작성. 컨테이너 라벨 · 서비스 디스커버리 기반의 동적 설정. |
자동 HTTPS 의 토대 — ACME 프로토콜 (RFC 8555, 2019) 과 Let's Encrypt (2016 정식 운영). 2016 이전에는 인증서 발급 · 갱신이 수동.
2. Caddy 의 자동 HTTPS
Caddyfile 에 도메인을 적기만 해도 Caddy 가 ACME 클라이언트로 인증서를 발급 · 갱신. HTTP-01 또는 TLS-ALPN-01 챌린지를 자동 처리.
example.com {
reverse_proxy 127.0.0.1:8080
}
이 한 줄로 80 → 443 리다이렉트, 인증서 발급, 갱신 스케줄, HTTPS 종단까지 처리. 같은 일을 nginx 로 하려면 certbot · cron 갱신 · server 블록 두 개 (80 · 443) 필요.
3. Caddyfile vs nginx.conf
# Caddyfile
api.example.com {
reverse_proxy /v1/* 127.0.0.1:8080
encode zstd gzip
log
}
# nginx.conf
server {
listen 443 ssl http2;
server_name api.example.com;
ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
location /v1/ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
gzip on;
access_log /var/log/nginx/access.log;
}
nginx 는 더 명시적이고 세밀한 제어가 가능. Caddy 는 합리적 기본값을 강하게 가짐 (Host 헤더 · X-Forwarded-For 자동 설정 등).
4. nginx 의 강점
- 거대한 운영 사례 · 튜토리얼 풀.
- 매우 세밀한 모듈 · 디렉티브.
- 다양한 서드파티 모듈 (OpenResty 같은 확장).
- L7 캐싱 (
proxy_cache) 이 강력.
5. Caddy 의 강점
- 자동 HTTPS 가 표준.
- 단일 바이너리 (Go), 시작이 단순.
- JSON API 를 통한 동적 설정.
- 모듈 시스템 (plug-in) 으로 빌드 시 기능 추가.
6. traefik 의 자리
컨테이너 환경 (Docker / Compose · Kubernetes) 에서 라벨 / 리소스를 보고 자동 라우트 갱신. 정적 파일이 아닌 디스커버리 기반 설정. 단일 호스트의 단순 프록시는 Caddy, 컨테이너 환경의 동적 라우팅은 traefik 이 자주 채택된다는 대조가 흔합니다.
7. 리버스 프록시 vs 로드밸런서
| 개념 | 의미 |
|---|---|
| 리버스 프록시 | 클라이언트 요청 받아 내부 서버로 전달, 응답을 다시 보냄. 캐시 · 압축 · SSL 종단. |
| 로드밸런서 | 여러 백엔드로 요청 분산. L4 (TCP) 또는 L7 (HTTP) 수준. |
리버스 프록시는 보통 로드밸런싱을 함께. HAProxy 는 로드밸런서 출신, nginx · Caddy 는 리버스 프록시로 시작해 둘을 모두. 클라우드의 ELB · ALB · NLB 같은 매니지드 서비스도 같은 자리.
8. Caddy 단일 호스트 운영 예
{
email admin@example.com
}
example.com {
reverse_proxy 127.0.0.1:3000
}
api.example.com {
reverse_proxy 127.0.0.1:8080
@ratelimit {
path /login
}
rate_limit @ratelimit 5r/m # 플러그인 필요
}
static.example.com {
root * /var/www/static
file_server
encode zstd gzip
}
9. nginx 단일 호스트 운영 예
certbot 으로 인증서 발급 · 갱신:
# Linux
sudo certbot --nginx -d example.com
# 자동 갱신은 systemd timer 또는 cron 으로
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
10. 자주 걸리는 자리
80 포트 도달성 — ACME HTTP-01 챌린지가 80 으로 들어와야 함. 방화벽이나 클라우드 보안 그룹에서 80 / 443 을 모두 열어 둠.
rate limit · ACME 한도 — Let's Encrypt 는 도메인당 발급 한도가 있음. 와일드카드 인증서 · 루트가 다른 도메인을 무분별하게 등록하면 차단될 수 있음.
X-Forwarded-For 신뢰 — 리버스 프록시 뒤의 애플리케이션이 헤더를 신뢰하지 않으면 클라이언트 IP 가 프록시 IP 로 보임. Caddy 는 자동, nginx 는 명시 설정 필요.
proxy_pass 의 슬래시 차이 (nginx) — proxy_pass http://up; 과 proxy_pass http://up/; 는 URL 결합 의미가 다름. 운영 사고의 단골 원인.
HTTP/2 와 WebSocket — 일부 환경에서 헤더 전달 · 업그레이드 처리가 다름. 두 프록시 모두 명시 설정 가능.
하고픈 말
소규모 ~ 중규모 단일 호스트 운영에서는 Caddy 의 자동 HTTPS + 합리적 기본값이 가장 큰 가치. nginx 의 풍부한 튜닝 옵션이 절실한 자리 (대용량 캐싱 · OpenResty Lua) 가 아니면 Caddyfile 한 줄로 끝나는 길이 운영 비용에서 압승. 다만 nginx 의 거대한 운영 사례 풀은 별도 가치.
Next
- loopback-ssh-tunnel
- single-server-philosophy
Caddy 공식 · Caddy GitHub · nginx 공식 · traefik 공식 · HAProxy 공식 · Let's Encrypt · RFC 8555 ACME 를 참고합니다.