VPS에서 Caddy vs Nginx: 설정 파일 비교

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Nginx 블록의 TLS 줄은 Certbot이 이미 실행되었다고 가정합니다. 위와 같은 HTTP 업스트림의 경우, Caddy는 들어오는 Host 헤더를 그대로 전달하고 다음을 설정합니다: X-Forwarded-For, X-Forwarded-Proto, 그리고 X-Forwarded-Host 기본적으로. Nginx에서는 업스트림이 원래 호스트, 스킴, 클라이언트 주소 체인을 필요로 할 때 보통 프록시 헤더를 명시적으로 추가합니다. 그것이 축소판으로 본 트레이드오프입니다. Caddy는 실용적인 프록시 기본값을 제공하고, Nginx는 그 동작의 더 많은 부분을 명시적으로 다루게 합니다.

정적 파일 제공:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

기본 인증, 사용자 이름과 비밀번호 뒤에서 모든 것을 보호:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

두 도구 모두 비밀번호를 별도로 해시합니다. Caddy는 다음을 사용합니다: caddy hash-password; Nginx는 다음을 사용합니다: htpasswd .htpasswd 파일을 만들기 위해서입니다. 해당 지시어는 basic_auth 이며, 참고로 현재 Caddy에서 그렇습니다. 그것은 basicauth 이었는데 v2.8.0에서 이름이 바뀌었습니다. 다음에 언급된 대로입니다: Caddy basic_auth 문서, 그리고 오래된 튜토리얼은 여전히 사람들을 여기서 걸려 넘어지게 합니다.

팁: Caddyfile의 그 해시는 비밀번호가 아닙니다. 다음에서 나온 bcrypt 출력입니다: caddy hash-password. 명령을 실행하고 출력된 것을 붙여넣으세요. Caddy는 설정에서 평문 비밀번호를 거부하는데, 이는 올바른 기본값이자 처음에는 작은 놀라움입니다.

설정 파일 자체가 그 논거를 만들어냅니다. Caddy는 TLS, 합리적인 프록시 헤더, 리다이렉트를 몇 줄로 접어 넣습니다. Nginx는 명시적이고 장황하며 모든 조절 손잡이를 건네줍니다. 수년간 Nginx를 다뤄왔다면 그 장황함은 몸에 밴 습관이고 그 제어력이 바로 핵심입니다. 그렇지 않다면 Caddyfile은 머릿속에 담아둘 수 있는 설정입니다. 실용적인 요점은 간단합니다. Caddy의 설정은 한눈에 읽기가 더 쉽고, Nginx는 더 명시적인 제어를 제공합니다.

성능과 메모리: 벤치마크를 신중하게 읽기

공개된 테스트는 대체로 같은 방향을 가리킵니다. Nginx는 보통 더 적은 메모리를 사용하고 순수 처리량에서 앞서는 경우가 많지만, 그 이점의 크기는 환경에 크게 좌우됩니다.

In 한 서드파티 4코어 VM 테스트에서 Nginx는 초당 약 48,000개의 요청에 도달했으며, Caddy는 약 42,000개였습니다. 같은 테스트는 HTTPS p99 지연 시간을 Nginx는 2.1 ms, Caddy는 2.4 ms로 보고했습니다. 이를 보편적인 성능 격차가 아니라 하나의 구성에서 나온 결과로 간주하세요.

비교 표의 메모리 범위는 다음에서 나옵니다: 별도의 VPS 테스트. 또 다른 50,000개 동시 연결에서의 합성 테스트 는 Nginx는 145 MB, Caddy는 520 MB로 보고했지만, 그 테스트는 상당히 다른 하드웨어와 워크로드 조건을 사용했습니다. 그 절대 수치는 위의 VPS 수치와 직접 비교해서는 안 됩니다.

신뢰할 수 있는 결론은 더 좁습니다. Nginx는 일반적으로 메모리 소모가 더 작고 고처리량 또는 고동시성 워크로드에서 앞서는 경향이 있습니다. 일반적인 소규모에서 중규모 VPS 리버스 프록시의 경우 둘 다 대개 충분히 빠르므로, 운영상의 단순함이 종종 더 유용한 결정 요인이 됩니다.

이 섹션의 결론: 서버가 메모리 제약이 있거나 자체 부하 테스트에서 프록시 처리량이 병목임이 드러나지 않는 한, 운영을 기준으로 선택하세요.

와일드카드 인증서의 함정(Caddy가 항상 무설정은 아니다)

Caddy는 와일드카드 인증서를 자동화할 수 있지만, 기본 HTTP-01 또는 TLS-ALPN-01 챌린지로는 안 됩니다. 다음에 대한 인증서는: *.example.com DNS-01 검증이 필요합니다. Let's Encrypt가 와일드카드 인증서에 대해 이를 의무화합니다. 이는 DNS 제공업체 플러그인(xcaddy를 통해 Caddy 바이너리에 내장)과 tls 블록에 설정된 DNS 호스트용 API 토큰을 의미합니다. Caddy가 마케팅하는 한 줄 입력하고 손 떼는 식의 이야기가 아닙니다.

이는 자신이 관리하는 실제 도메인 아래에 많은 서비스를 두는 홈랩 사용자를 곤란하게 만듭니다. 예를 들어 *.home.example.com같은 경우이며, 와일드카드 발급이 다음만큼 자동이라고 가정하는 경우입니다: app.example.com. 순수하게 내부용인 이름, 예를 들어 *.homelab.internal 같은 경우는 공개 Let's Encrypt 와일드카드가 아니라 로컬/내부 PKI 영역으로 다루세요. 정확히 말하자면, Caddy는 와일드카드를 잘 처리하지만 기본 챌린지로는 하지 않으며, 그 설정은 단일 도메인 사례에서 한 단계 올라간 것입니다. 여기서 Nginx도 같은 처지인데, DNS-01 요구 사항은 서버가 아니라 Let's Encrypt에서 나오기 때문입니다.

GUI를 원한다면: Nginx Proxy Manager(짧은 부연)

Nginx Proxy Manager는 위의 두 도구와는 전혀 다른 존재이며, 이름이 사람들을 혼란스럽게 하기에 한 단락을 할애할 가치가 있습니다. NPM은 Nginx 위에 얹은 GUI 래퍼입니다. port 81의 웹 인터페이스를 통해 리버스 프록시 규칙과 Let's Encrypt 인증서를 관리합니다. Nginx 코어가 아니며, Nginx 코어처럼 설정되지도 않습니다.

트레이드오프는 흔한 클릭 대 설정의 문제입니다. NPM은 정상 경로를 벗어나기 전까지는 쉬운 버튼입니다. 그 설정은 손으로 편집하는 단일 설정 파일이 아니라 애플리케이션 데이터베이스를 통해 관리됩니다. 기본 Docker 구성은 다음을 사용합니다: SQLite를 사용하며, MySQL/MariaDB와 PostgreSQL은 지원되는 외부 데이터베이스 옵션입니다. 그 차이는 이식성에도 영향을 줍니다. Caddy 구성은 종종 다음을 복사하는 것만으로 옮길 수 있습니다: 단일 Caddyfile. 반면 Nginx Proxy Manager 배포는 다음을 보존해야 합니다: 애플리케이션 데이터와 데이터베이스 를 보존해야 합니다. 편집보다 클릭을 정말로 선호하고 구성이 단순하게 유지된다면 NPM은 괜찮은 선택입니다. Infrastructure-as-code 워크플로에는 잘못된 선택입니다.

Nginx에서 Caddy로 마이그레이션하기(무엇이 옮겨지고 무엇이 옮겨지지 않는가)

이미 Nginx를 사용 중이고 이전을 저울질하고 있다면, 자동화에 대한 기대치를 낮추는 것부터 시작하세요. Caddy NGINX 설정 어댑터가 있지만 불완전하며 신뢰할 수 있는 원샷 마이그레이션 경로로 취급해서는 안 됩니다. Nginx에서 Caddy로의 마이그레이션은 대부분 수동 재작성이며, 그 대부분은 더 짧아집니다.

무엇이 옮겨지고 더 간단해지는지는 다음에 따릅니다: Caddy 커뮤니티의 변환 가이드:

• HTTP 업스트림의 경우, reverse_proxy 들어오는 Host 헤더를 그대로 전달하고 기본적으로 표준 X-Forwarded-* 헤더를 설정합니다. 따라서 그런 proxy_set_header 줄의 대부분이 사라집니다.
• PHP는 다음을 포함한 location 블록에서: try_files 더하기 fastcgi_pass 여러 파라미터가 잔뜩 있던 것이 단일 php_fastcgi 지시어로 축소됩니다.
• WebSocket 처리는 Caddy v2에서 자동입니다. 튜토리얼이 별도의 websocket 지시어를 추가하라고 한다면, 그것은 Caddy v1의 잔재입니다. 무시하세요.

자동으로 옮겨지지 않는 것: Caddy에 없는 특정 Nginx 모듈에 얽힌 것, 이식하기보다는 다시 생각해야 하는 복잡한 rewrite 및 location 로직, 그리고 위 섹션의 DNS 챌린지 설정으로 다시 데려가는 와일드카드 인증서 구성입니다. 모듈과 재작성에 시간을 배정하세요. 나머지는 대개 줄 수가 순수하게 줄어듭니다.

어느 것을 설치해야 할까요?(결정)

설정, 수치, 와일드카드의 함정, 그리고 마이그레이션 비용을 살펴봤으니, 결론은 여기입니다. 1인 개발자나 소규모 팀이거나, 이번이 갓 만든 VPS 배포이거나, 설정 후 잊어버리는 TLS를 원하거나, 단순한 라우팅으로 Docker를 실행하거나, 그저 몸에 밴 습관처럼 익숙한 설정을 원한다면 Caddy를 설치하세요. 이 글을 읽는 대부분의 사람이 여기에 해당합니다.

세밀한 제어나 성숙한 생태계의 특정 모듈이 필요하거나, 메모리 제약이 있는 서버에서 성능을 짜내고 있거나, 고동시성 정적 파일 제공을 하고 있거나, 팀이 이미 깊은 Nginx 전문성과 작동하는 설정 더미를 갖추고 있다면 Nginx를 설치하세요. 이들은 확실한 이유이며, 그중 하나가 당신의 경우라면 Nginx가 올바른 선택입니다. 이는 더 오래된 도구가 잘못된 도구인 경우가 아닙니다.

어느 쪽으로 정하든 다음 단계는 그것을 서버에 올리는 것입니다. 둘 다 Caddy 와 Nginx 우리 마켓플레이스에서 원클릭 배포로 제공되므로, 설치 작업을 건너뛰고 곧바로 Caddyfile이나 서버 블록으로 갈 수 있습니다. 1 GB VPS는 트래픽이 적은 단일 사이트 배포에 합리적인 출발점이지만, 프록시만이 아니라 프록시 뒤의 애플리케이션과 트래픽에 맞게 서버 사양을 정하세요. Caddy를 자체 호스팅 서비스의 정문으로 사용한다면, 다음 앞에 위치할 수 있습니다: Prometheus와 Grafana 모니터링 스택 또는 Uptime Kuma 배포 앞에, 별도의 TLS 도구를 필요로 하지 않고 위치할 수 있습니다.

이 섹션의 결론: Nginx를 가리키는 구체적인 이유가 없는 한 Caddy를 선택하세요.

자주 묻는 질문