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 를 참고합니다.