VPS에서 Nginx Proxy Manager: 리뷰 및 설정 가이드

NPM vs Caddy vs Traefik: 어떤 리버스 프록시가 당신의 VPS에 맞는가

세 도구는 선택을 좌우하는 네 가지 축으로 나뉩니다. 어떻게 구성하는지, HTTPS를 어떻게 처리하는지, 서비스 수에 따라 어떻게 확장되는지, 유휴 상태에서 RAM을 얼마나 쓰는지입니다. 다음은 그 비교입니다.

유휴 RAM 수치는 다음의 대략적인 관측값입니다. 2026년의 한 비교고정된 요구 사항이 아닙니다. 실제 사용량은 이미지 버전, 활성화된 기능, 트래픽, 로깅에 따라 달라집니다.

전환 기준은 그 표에서 곧바로 도출됩니다. 대시보드를 원하고 자주 바뀌지 않는 소수의 서비스를 운영한다면 NPM이 적합한 도구입니다. 코드로서의 구성을 선호하거나, 가장 작은 자원 사용을 원하거나, Caddy의 다음 기능을 높이 산다면, ACME 설정 없이 자동 HTTPS 발급 및 갱신Caddy를 사용하세요. 저는 SSL 처리가 자동이고 Caddyfile이 짧아서 단일 사이트 배포에서는 Caddy를 직접 선택합니다. 컨테이너를 자주 추가, 제거, 재배포한다면 Traefik의 레이블 기반 자동 검색 덕분에 새 호스트를 일일이 손으로 등록하지 않아도 됩니다.

정밀한 제어나 비Docker 배포를 위해 일부 관리자가 선호하는 Certbot을 사용한 순수 Nginx도 있습니다. Certbot은 인증서 갱신을 자동화할 수 있지만, 가상 호스트 라우팅과 Nginx 구성은 여전히 직접 관리해야 합니다. NPM을 고려하는 주된 이유가 수동 프록시 구성을 피하는 것이라면, 순수 Nginx는 더 나은 선택이 되기 어렵습니다.

선택에 관한 한 가지 참고: byte-guard의 비교는 그 비교에서 Caddy를 가장 가벼운 옵션으로 꼽으며, 2026년 새 단일 호스트 설정에는 합리적인 선택입니다. Caddy는 NPM보다 가볍다는 점에서 앞서지만, 특별히 GUI를 원한다면 최선의 선택은 아닙니다.

기반 엔진에 대한 더 깊은 나란한 비교는 다음을 참조하세요. VPS에서의 Caddy vs Nginx 비교.

전제 조건: 필요한 것

배포하기 전에 다음을 준비하세요. 짧은 목록이지만 어느 항목이든 빠뜨리면 나중에 인증서 단계가 실패합니다.

• 다음을 갖춘 VPS. Docker 및 Docker Compose 설치됨 (Ubuntu 22.04 LTS 또는 Debian 12면 됩니다).
• 도메인 이름과 다음. DNS A 레코드 (IPv6를 사용한다면 AAAA도) VPS 공용 IP를 가리키는.
• VPS에 대한 SSH 접근.
• 방화벽에서 인터넷을 향해 열린 포트 80과 443.
• 본인만 접근 가능하고 공개되지 않은 포트 81(보안 섹션에서 다룹니다).

Docker Compose로 VPS에 Nginx Proxy Manager 설정하기

이 섹션은 Docker Compose를 사용해 NPM을 배포합니다. DNS 레코드가 VPS로 해석되면 컨테이너 설정 자체는 빠르지만, DNS 전파와 인증서 발급에는 시간이 더 걸릴 수 있습니다.

설정은 하나의 Docker Compose 파일과 공유 Docker 네트워크를 만드는 일회성 명령을 사용합니다. 디렉터리를 만들고, 네트워크를 만들고, 아래의 다음 docker-compose.yml 파일을 추가한 뒤 컨테이너를 실행하세요.

먼저 공유 Docker 네트워크를 만드세요.

docker network create proxy

그런 다음 다음을 만드세요. docker-compose.yml 파일:

# docker-compose.yml
services:
  npm:
    image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
    restart: unless-stopped
    ports:
      - '80:80'                 # public HTTP
      - '443:443'               # public HTTPS
      - '127.0.0.1:81:81'       # admin UI, reachable only from the VPS itself
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy
networks:
  proxy:
    external: true

NPM이 서비스 이름으로 접근해야 하는 모든 백엔드 컨테이너를 동일한 외부 다음 proxy 네트워크에 연결하세요. 이렇게 하면 백엔드 애플리케이션의 포트를 VPS에 게시하지 않고도 NPM이 서비스 이름으로 컨테이너를 해석할 수 있습니다.

다음 둘 다 백업하세요. ./data 와 ./letsencrypt 업그레이드 전에요. 데이터 디렉터리에는 NPM의 데이터베이스와 생성된 구성이, Let's Encrypt 디렉터리에는 인증서 자료가 들어 있습니다.

이 파일에 관한 몇 가지. 이미지는 기본적으로 다음에 저장된 SQLite 데이터베이스를 사용합니다. ./data 볼륨입니다. 이것이 기본 백엔드이며 대부분의 단일 VPS 배포에 적합합니다. 외부 데이터베이스가 필요하다면 NPM은 MariaDB/MySQL과 PostgreSQL을 지원하며, 이는 데이터베이스 서비스와 그에 맞는 환경 변수를 추가하는 것을 의미합니다. 단일 VPS의 경우, 데이터베이스를 데이터 볼륨 밖으로 옮길 명확한 이유가 없다면 SQLite가 여전히 가장 간단한 기본값입니다. 다음 restart: unless-stopped 정책은 VPS가 재부팅되면 NPM이 다시 올라온다는 뜻이며, 이는 다른 모든 것 앞에 위치하는 서비스에 바라는 바입니다.

실행하고 작동 중인지 확인하세요.

docker compose up -d
docker compose ps

예상 출력: 다음 npm 컨테이너가 다음 상태로 Up포트 80과 443이 공개적으로 매핑되고, 포트 81은 다음에만 바인딩됩니다. 127.0.0.1. 첫 시작은 NPM이 JWT 키를 생성하고, 데이터베이스를 초기화하고, 기본 관리자 사용자를 만드는 동안 몇 분이 걸립니다. 다음 공식 설정 문서는 이 첫 실행 순서를 설명합니다.

관리 인터페이스를 열기 전에 로컬 컴퓨터에서 SSH 터널을 만드세요.

ssh -L 8181:127.0.0.1:81 user@your-vps

그런 다음 다음을 여세요. http://127.0.0.1:8181 브라우저에서요. 새로 설치한 경우 다음으로 로그인하세요. [email protected] 와 changeme그런 다음 즉시 기본 이메일과 비밀번호를 교체하세요. 기본 자격 증명이 유효한 동안에는 대시보드를 공개적으로 접근 가능하게 만들지 마세요.

관리자 자격 증명을 변경했다면 첫 프록시 호스트를 추가하세요.

1. 대시보드에서 다음으로 이동하세요. Hosts, 그다음 Proxy Hosts, 그다음 Add Proxy Host.
2. 설정 Domain Name을 당신의 서브도메인으로(예: cloud.example.com).
3. 설정 Forward Hostname / IP를 백엔드 컨테이너 이름 또는 IP로, 그리고 Forward Port를 해당 서비스가 수신하는 포트로.
4. 저장하세요. 프록시 호스트가 목록에 나타나고, 이제 그 서브도메인으로의 트래픽이 컨테이너에 도달합니다.

이와 함께 Docker 관리 UI를 운영한다면 동일한 패턴이 적용됩니다. 같은 방식으로 서브도메인을 컨테이너 관리 도구로 연결하고, 다음에 대해서도 동일하게 하세요. Prometheus와 Grafana 모니터링 스택 프록시 뒤에 두고 싶은 것.

서브도메인에 대한 자동 HTTPS 구성하기

이 섹션은 서브도메인에 대해 자동으로 갱신되는 유효한 Let's Encrypt 인증서를 갖추게 해줍니다. 사람들이 자주 걸리는 전제 조건은 이것입니다. 해당 서브도메인의 DNS A 레코드가 이미 VPS를 가리키고 있어야 하고, 포트 80이 인터넷에서 접근 가능해야 합니다. Let's Encrypt가 도메인으로 다시 연결하여 검증하기 때문입니다.

프록시 호스트를 만든 상태에서 인증서를 요청하세요.

1. 프록시 호스트를 편집하고 다음을 여세요. SSL 탭
2. 아래 SSL 인증서선택하기 Request a new SSL Certificate.
3. 활성화 Force SSL 와 HTTP/2 Support. HSTS는 HTTPS가 올바르게 작동하는지 확인한 후에만 켜세요. 브라우저가 정책을 캐시할 수 있어 인증서나 프록시 구성 실수로부터의 복구가 더 어려워질 수 있기 때문입니다.
4. Let's Encrypt 약관에 동의하고 저장하세요.

기본적으로 NPM은 비와일드카드 이름에 HTTP-01 챌린지를 사용하여 요청된 각 호스트명을 포트 80을 통해 검증합니다. 인증서는 여러 비와일드카드 이름을 포함할 수 있지만, HTTP-01은 와일드카드 인증서를 발급할 수 없습니다. 다음과 같은 와일드카드 이름은 *.example.com 지원되는 DNS 제공업체와 함께 DNS-01 챌린지가 필요합니다. 서비스당 서브도메인 하나라는 일반적인 설정에는 HTTP-01만 있으면 되고, 갱신은 자동입니다.

Nginx Proxy Manager를 위한 VPS 사이징

NPM 자체는 가볍습니다. 사이징 문제는 사실 NPM과 그 뒤에 있는 서비스를 합친 것에 관한 것입니다. 프록시의 유휴 자원 사용은 좀처럼 제약이 되지 않습니다. Nextcloud 인스턴스나 Ghost 블로그가 프록시 자체보다 더 많은 자원을 사용합니다.

실제로 각 등급이 어떻게 나뉘는지는 다음과 같습니다.

• 실용적 최소 기준선: 1 GB RAM, 1 vCPU, 10 GB 스토리지. 하나 서드파티 사이징 가이드 도 같은 기준선을 사용하지만, 이를 공식 NPM 요구 사항이 아니라 계획 지침으로 받아들이세요. NPM, 운영 체제, 몇 개의 가벼운 서비스에는 충분하지만 여유는 제한적입니다.
• 편안함: 2 GB RAM, 1 vCPU, 20 GB 스토리지. 여유를 두고 NPM과 서비스 서너 개에서 다섯 개까지. 대부분의 셀프 호스터에게 가장 적절한 지점입니다.
• 한 단계 위: 4 GB RAM, 2 vCPU. 서비스 여덟 개에서 열두 개까지, 또는 TLS 종료를 위한 CPU 여유가 필요할 만큼 의미 있는 트래픽이 있는 설정에.

사이징의 기준이 되는 수치는 NPM이 아니라 프록시 대상 앱들의 합입니다. 실행하려는 서비스의 RAM 사용량을 모두 더하고, 그 위에 프록시의 작은 유휴 오버헤드를 더한 뒤, 여유를 두고 그보다 위 등급을 선택하세요.

서버 사양을 정하는 것은 쉬운 부분입니다. NPM을 실행하려면 여전히 VPS를 프로비저닝하고, Docker를 설치하고, 이미지를 가져오고, 첫 실행 설정을 거쳐야 합니다. 프로비저닝 단계를 건너뛰고 싶다면 Cloudzy 마켓플레이스에 원클릭 다음이 있습니다. Nginx Proxy Manager 배포 NVMe VPS에서요. 새 서버에 컨테이너를 세워주므로, 바로 대시보드와 첫 프록시 호스트로 넘어갈 수 있습니다. 어느 쪽이든 위의 사이징 등급이 프로비저닝의 기준이 됩니다.

자주 묻는 질문