Nginx Proxy Manager로 도메인 연결하는 법
IP:포트 주소 대신 내 도메인과 HTTPS로 셀프호스팅 서비스를 여는 방법
- Nginx Proxy Manager는 여러 웹 서비스를 하나의 서버에서 도메인별로 나눠 연결할 수 있게 해주는 리버스 프록시 관리 도구입니다.
- 먼저 DNS의 A 또는 AAAA 레코드가 Nginx Proxy Manager가 있는 서버의 공인 IP를 가리키도록 설정해야 합니다.
- Proxy Host에서는 도메인과 실제 서비스의 내부 주소·포트를 연결합니다.
- Nginx Proxy Manager는 Let’s Encrypt를 이용한 무료 SSL 인증서 발급과 HTTPS 적용을 지원합니다.
- 일반적인 구성에서는 외부 HTTP 80번, HTTPS 443번 포트가 Nginx Proxy Manager까지 정상적으로 도달해야 합니다.
Nginx Proxy Manager 도메인 연결을 해두면 매번 서버의 IP 주소와 포트 번호를 외워서 접속할 필요가 없습니다. 예를 들어 192.168.0.10:9000처럼 접속하던 서비스를 app.example.com 같은 주소로 정리할 수 있습니다.
셀프호스팅을 처음 시작하면 Docker 컨테이너 하나를 실행하는 것까지는 비교적 간단합니다. 하지만 Portainer, 개인 클라우드, 대시보드처럼 서비스가 늘어나면 각각 다른 포트를 사용하게 되고 외부 접속과 HTTPS 설정도 복잡해집니다.
이때 Nginx Proxy Manager를 앞에 두면 사용자가 입력한 도메인을 보고 어느 서비스로 요청을 전달할지 결정할 수 있습니다. 여기에 DNS와 SSL 인증서까지 제대로 연결하면 일반 웹사이트처럼 깔끔한 주소로 셀프호스팅 서비스를 운영할 수 있습니다.
이 글에서는 단순히 버튼을 누르는 순서만 설명하지 않습니다. DNS → 공유기 또는 방화벽 → Nginx Proxy Manager → 실제 서비스로 요청이 이동하는 구조부터 살펴본 뒤, 어디에서 문제가 생기는지도 함께 정리합니다.
Nginx Proxy Manager 도메인 연결 전 구조 이해하기
Nginx Proxy Manager는 Nginx를 기반으로 리버스 프록시 구성을 GUI에서 관리할 수 있게 만든 프로젝트입니다. 공식 문서에서도 홈 네트워크 등의 웹 서비스를 외부에 노출하고, 도메인 전달과 무료 SSL을 쉽게 구성하는 것을 주요 목적으로 설명합니다.
여기서 가장 먼저 구분해야 하는 것은 도메인과 실제 서비스 주소가 서로 다른 역할을 한다는 점입니다. 도메인은 사용자가 기억하기 쉬운 입구이고, Docker 컨테이너나 서버에서 실행 중인 서비스의 IP와 포트는 실제 목적지입니다.
예를 들어 홈서버에서 어떤 웹 애플리케이션이 192.168.0.20:3000으로 실행되고 있다고 가정해보겠습니다. 같은 네트워크에서는 이 주소를 직접 입력할 수 있지만, 이를 그대로 공개 주소처럼 사용하는 방식은 관리하기 불편합니다.
Nginx Proxy Manager를 사용하면 app.example.com으로 들어온 요청을 받아 192.168.0.20의 3000번 포트로 전달하는 구성을 만들 수 있습니다. 실제 애플리케이션의 포트는 그대로 두고 외부에서 사용하는 주소만 깔끔하게 정리하는 방식입니다.
이 구조의 장점은 서비스가 많아질수록 커집니다. 예를 들어 서비스 A가 3000번, 서비스 B가 8080번, 서비스 C가 9000번 포트를 사용하더라도 외부에서는 각각 다른 서브도메인을 사용할 수 있습니다.
즉 a.example.com, b.example.com, c.example.com처럼 구분하고 Nginx Proxy Manager에서 각각의 목적지만 지정하면 됩니다. 사용자는 내부에서 어떤 포트를 사용하는지 알 필요가 없습니다.
Nginx Proxy Manager를 단순한 ‘도메인 연결 프로그램’으로 생각하면 설정 과정이 헷갈리기 쉽습니다. 실제로는 인터넷에서 들어오는 웹 요청을 먼저 받은 뒤, 도메인을 기준으로 적절한 내부 서비스에 넘겨주는 관문에 가깝습니다.
Nginx Proxy Manager 공식 설정 예제에서는 Docker 호스트의 80, 443, 81 포트를 컨테이너의 같은 포트에 연결합니다. 공식 문서에서 80은 Public HTTP, 443은 Public HTTPS, 81은 Admin Web Port로 안내합니다.
따라서 81번은 관리 화면에 접근하는 용도이고, 실제 방문자의 HTTP·HTTPS 요청은 80번과 443번으로 들어오는 구조입니다. 인터넷에 서비스를 공개한다면 이 차이를 알고 방화벽과 포트 전달을 구성해야 합니다.
Nginx Proxy Manager 도메인 연결 전 DNS 설정
Nginx Proxy Manager 도메인 연결에서 가장 먼저 확인할 부분은 Nginx Proxy Manager 화면이 아니라 DNS입니다. 도메인을 입력했을 때 요청이 자신의 서버가 있는 네트워크까지 도착해야 그다음 단계인 리버스 프록시가 동작할 수 있기 때문입니다.
IPv4 주소로 서버를 연결한다면 일반적으로 DNS에 A 레코드를 사용합니다. IPv6 주소를 사용한다면 AAAA 레코드를 이용합니다. Cloudflare 공식 문서도 A와 AAAA 레코드를 각각 IPv4와 IPv6 주소에 도메인을 연결하는 레코드로 설명합니다.
예를 들어 공인 IPv4 주소가 203.0.113.10이고 app.example.com을 만들고 싶다고 가정해보겠습니다. DNS 관리 화면에서 app이라는 이름의 A 레코드를 만들고 실제 환경에서는 자신의 공인 IPv4 주소를 입력하는 식입니다.
여기서 예시로 표시한 203.0.113.10 같은 주소를 그대로 사용하면 안 됩니다. 실제 설정에서는 자신의 서버가 인터넷에서 접근 가능한 공인 IP를 확인하고 그 값을 넣어야 합니다.
Cloudflare를 DNS 제공자로 사용하는 경우 A, AAAA, CNAME 레코드에는 Proxy status 설정도 존재합니다. Cloudflare 공식 문서에 따르면 Proxied 상태에서는 HTTP·HTTPS 트래픽이 Cloudflare 네트워크를 거친 뒤 원본 서버로 전달되고, DNS only에서는 DNS가 실제 원본 주소를 직접 반환합니다.
따라서 Cloudflare의 주황색 구름을 켜는 것과 Nginx Proxy Manager의 리버스 프록시는 같은 기능이 아닙니다. Cloudflare 프록시를 켜면 방문자 → Cloudflare → Nginx Proxy Manager → 내부 서비스처럼 한 단계가 추가되는 구조로 이해하면 쉽습니다.
처음 연결할 때는 DNS, 포트 전달, Nginx Proxy Manager 설정을 한꺼번에 바꾸지 않는 편이 문제를 찾기 쉽습니다. 먼저 도메인이 올바른 공인 IP를 가리키는지 확인하고, 그다음 외부 요청이 Nginx Proxy Manager까지 도달하는지 단계별로 점검하세요.
홈서버가 공유기 안쪽에 있다면 DNS만 설정했다고 바로 연결되는 것은 아닙니다. DNS는 도메인이 찾아갈 공인 주소를 알려줄 뿐이고, 공유기가 받은 요청을 내부의 Nginx Proxy Manager 서버까지 전달하는 과정이 별도로 필요합니다.
일반적인 IPv4 NAT 환경에서는 공유기에서 외부 TCP 80번과 443번 요청을 Nginx Proxy Manager가 실행되는 장치로 전달하도록 구성합니다. 공유기 제조사마다 메뉴 이름이 다르므로 ‘포트 포워딩’, ‘포트 전달’, ‘NAT’처럼 표시될 수 있습니다.
Nginx Proxy Manager 공식 Docker 구성도 호스트의 80번과 443번을 각각 컨테이너의 80번과 443번에 연결합니다. 관리 인터페이스에는 별도로 81번 포트를 사용합니다.
Nginx Proxy Manager 관리용 81번 포트를 무조건 인터넷 전체에 공개하는 방식은 피하는 편이 안전합니다. 대신 관리 화면은 내부 네트워크나 신뢰할 수 있는 접근 경로에서 사용하고, 외부 방문자에게 필요한 웹 트래픽은 80·443번을 중심으로 구성하세요.
또 하나 확인해야 할 부분은 공인 IP입니다. 공유기의 WAN 주소가 인터넷에서 확인되는 주소와 다르거나 통신사 네트워크 구조상 직접적인 인바운드 연결을 받을 수 없다면 단순 포트 포워딩만으로는 외부 연결이 되지 않을 수 있습니다.
이 경우 Nginx Proxy Manager의 Proxy Host 값을 계속 바꾸는 것은 해결책이 아닙니다. 먼저 자신의 인터넷 회선에서 외부 연결을 서버까지 전달할 수 있는 구조인지 확인해야 합니다.
도메인이 안 열린다고 해서 Nginx Proxy Manager가 항상 원인은 아닙니다. DNS가 틀리면 요청이 집까지 오지 않고, 공유기 설정이 틀리면 요청이 서버까지 오지 않습니다. Nginx Proxy Manager는 요청이 자신에게 도착한 이후부터 역할을 시작합니다.
Proxy Host에서 Nginx Proxy Manager 도메인 연결하기
DNS와 네트워크 경로를 준비했다면 이제 실제 Nginx Proxy Manager 도메인 연결을 만들 차례입니다. 핵심은 외부에서 사용할 도메인과 내부에서 실제로 실행 중인 웹 서비스의 주소를 하나의 Proxy Host로 묶는 것입니다.
Nginx Proxy Manager가 Docker로 정상 실행 중이라면 공식 기본 구성 기준 관리 인터페이스는 컨테이너의 81번 포트를 사용합니다. 실제 접근 주소는 Docker 포트 매핑과 서버 주소에 따라 달라질 수 있습니다.
관리 화면에서 Proxy Hosts 영역으로 이동해 새 Proxy Host를 추가합니다. 여기에서 Domain Names에는 앞에서 DNS에 만든 도메인을 넣고, Forward Hostname/IP에는 실제 웹 애플리케이션에 접근할 수 있는 호스트명 또는 IP를 지정합니다.
Forward Port에는 해당 서비스가 실제로 듣고 있는 포트를 입력합니다. 예를 들어 내부 서비스가 192.168.0.20:3000에서 HTTP로 동작한다면 개념적인 설정은 다음과 같습니다.
Domain Names: app.example.com Scheme: http Forward Hostname / IP: 192.168.0.20 Forward Port: 3000
이 예시는 구조를 이해하기 위한 값입니다. 실제 환경에서는 app.example.com 대신 자신이 DNS에 등록한 도메인을, 192.168.0.20과 3000 대신 실제 서비스의 주소와 포트를 입력해야 합니다.
여기서 자주 하는 실수가 Forward Hostname/IP에 공인 IP를 다시 넣는 것입니다. Nginx Proxy Manager와 목적지 서비스가 같은 로컬 네트워크에 있다면 일반적으로 Nginx Proxy Manager가 실제로 접근할 수 있는 내부 주소를 목적지로 지정하는 편이 구조가 단순합니다.
두 컨테이너가 같은 Docker 네트워크에 연결되어 있고 이름 해석이 가능한 구성이라면 IP 대신 Docker 서비스명이나 컨테이너가 접근 가능한 호스트명을 활용할 수도 있습니다. 다만 Docker 네트워크 구성에 따라 접근 가능 여부가 달라지므로 실제 연결 구조를 먼저 확인해야 합니다.
Proxy Host를 만들기 전에 Nginx Proxy Manager가 실행되는 서버에서 목적지 서비스에 실제로 접근할 수 있는지 확인하세요. 목적지 자체가 열리지 않는다면 도메인이나 SSL을 바꿔도 프록시는 정상적으로 연결할 수 없습니다.
Scheme도 목적지 서비스에 맞춰야 합니다. 내부 애플리케이션이 일반 HTTP로 제공된다면 http를 선택하고, 실제 목적지 자체가 HTTPS로 서비스되는 구성이라면 그에 맞게 설정해야 합니다.
외부 사용자가 HTTPS로 접속한다고 해서 Forward Scheme까지 반드시 HTTPS여야 하는 것은 아닙니다. Nginx Proxy Manager에서 TLS를 종료하고 내부 서비스에는 HTTP로 전달하는 구조도 가능하며, 이것이 리버스 프록시에서 흔히 볼 수 있는 구성 중 하나입니다.
Nginx Proxy Manager 도메인 연결이 저장되면 요청 흐름은 훨씬 명확해집니다. 사용자가 도메인을 입력하면 DNS가 서버 쪽 주소를 찾고, 웹 요청이 Nginx Proxy Manager에 도착한 뒤 등록된 도메인과 일치하는 Proxy Host가 선택됩니다.
그다음 Nginx Proxy Manager가 설정된 Forward Hostname/IP와 Forward Port로 요청을 넘깁니다. 즉 DNS는 ‘어느 서버로 갈지’, Proxy Host는 ‘그 서버 안에서 어느 서비스로 갈지’를 나눠 담당한다고 생각하면 이해하기 쉽습니다.
Let’s Encrypt SSL 인증서와 HTTPS 적용하기
Nginx Proxy Manager 도메인 연결이 정상적으로 동작한다면 다음 단계는 HTTPS입니다. HTTP 상태로도 웹 서비스에 접속할 수 있지만, 인터넷을 통해 로그인 정보나 세션 쿠키 같은 데이터를 주고받는 서비스라면 HTTPS를 적용하는 것이 기본적인 운영 방식입니다.
HTTPS에서는 TLS 인증서를 이용해 브라우저와 서버 사이의 통신을 보호합니다. Nginx Proxy Manager는 인증서 관리 기능을 제공하며, Let’s Encrypt를 이용해 도메인에 사용할 인증서를 발급받는 구성을 지원합니다.
Proxy Host를 편집한 뒤 SSL Certificate 영역에서 인증서를 요청할 수 있습니다. 실제 화면의 세부 항목은 Nginx Proxy Manager 버전에 따라 달라질 수 있지만, 핵심은 도메인 소유권 검증 → 인증서 발급 → 해당 Proxy Host에 인증서 적용 순서입니다.
Let’s Encrypt가 인증서를 발급하기 전에 해당 도메인을 실제로 제어하고 있는지 확인해야 합니다. 이를 ACME Challenge라고 하며, 대표적으로 HTTP-01과 DNS-01 방식이 있습니다.
Nginx Proxy Manager 도메인 연결에서 HTTP-01이 동작하는 방식
Let’s Encrypt 공식 문서에 따르면 HTTP-01에서는 ACME 클라이언트가 http://도메인/.well-known/acme-challenge/... 경로에 검증용 데이터를 제공하고, Let’s Encrypt가 인터넷에서 해당 주소에 접근해 확인합니다.
중요한 점은 HTTP-01 검증 자체가 80번 포트에서 시작된다는 것입니다. Let’s Encrypt는 HTTP에서 HTTPS로의 리다이렉션을 따라갈 수 있지만 HTTP-01을 임의의 다른 포트에서 수행하도록 바꿀 수는 없습니다.
따라서 HTTP-01 방식으로 인증서 발급과 갱신을 진행한다면 외부의 80번 포트 요청이 Nginx Proxy Manager까지 정상적으로 도달할 수 있어야 합니다. Let’s Encrypt도 일반적인 웹 서버에서는 80번과 443번을 모두 제공하고 HTTP 요청을 HTTPS로 리다이렉트하는 구성을 권장합니다.
인증서가 적용되면 사용자는 https://app.example.com처럼 HTTPS 주소로 서비스에 접속할 수 있습니다. 내부 서비스가 HTTP를 사용하더라도 Nginx Proxy Manager가 외부 클라이언트와 TLS 연결을 처리하고 내부 서비스로 요청을 전달하는 구성이 가능합니다.
HTTPS를 적용했다고 내부 애플리케이션의 포트까지 인터넷에 직접 공개할 필요는 없습니다. 외부 웹 요청은 Nginx Proxy Manager가 받고, Nginx Proxy Manager만 내부 애플리케이션에 접근하도록 역할을 나누는 것이 리버스 프록시 구성의 핵심입니다.
80번 포트를 사용할 수 없는 환경이라면 HTTP-01만 고집할 필요는 없습니다. Let’s Encrypt의 DNS-01은 _acme-challenge 아래에 TXT 레코드를 만들어 도메인 제어 권한을 증명하며, 공개 웹 서버가 없어도 도메인 검증이 가능합니다.
DNS-01은 와일드카드 인증서 발급도 지원합니다. 다만 자동 발급과 갱신을 구성하려면 DNS 제공자의 API를 사용하는 경우가 많고, API 자격 증명 관리도 중요해집니다. Nginx Proxy Manager에서 사용할 수 있는 DNS Challenge 기능과 공급자는 설치 버전과 환경에 맞춰 확인해야 합니다.
인증서가 한 번 발급됐다는 이유로 HTTP-01에 필요한 네트워크 경로를 바로 막아버리면 이후 재검증이나 갱신 과정에서 문제가 생길 수 있습니다. 대신 일반적인 공개 웹 서비스라면 80번 요청을 HTTPS로 리다이렉트하는 구성을 사용하고, 80번을 열 수 없는 환경에서는 DNS-01 같은 다른 검증 방식을 검토하세요.
연결이 안 될 때 확인할 항목과 이후 관리 방법
Nginx Proxy Manager 설정을 모두 끝냈는데도 도메인이 열리지 않는다면 설정을 처음부터 반복하기보다 요청이 어느 단계까지 도착하는지 확인하는 편이 빠릅니다. Nginx Proxy Manager 도메인 연결은 여러 계층이 이어져 있기 때문에 한 곳만 잘못돼도 최종적으로는 같은 ‘접속 불가’처럼 보입니다.
가장 먼저 DNS를 확인합니다. 도메인이 엉뚱한 IP를 가리키고 있다면 Nginx Proxy Manager 설정을 아무리 수정해도 요청 자체가 해당 서버에 도착하지 않습니다.
DNS가 맞다면 다음은 네트워크 경로입니다. 홈서버라면 공유기나 방화벽에서 필요한 웹 요청이 Nginx Proxy Manager가 실행되는 서버까지 전달되는지 확인합니다. 특히 HTTP-01 인증을 사용한다면 80번 포트의 외부 접근 가능 여부도 중요합니다.
그다음 Nginx Proxy Manager의 Proxy Host를 확인합니다. Domain Names의 오타, 잘못된 Forward Hostname/IP, 틀린 Forward Port, 목적지와 맞지 않는 Scheme은 모두 연결 실패의 원인이 될 수 있습니다.
마지막으로 목적지 애플리케이션 자체를 확인합니다. 예를 들어 Proxy Host가 192.168.0.20:3000으로 요청을 전달하도록 설정되어 있어도 그 주소에서 애플리케이션이 실행되지 않는다면 Nginx Proxy Manager가 전달할 대상이 없습니다.
문제를 찾을 때는 DNS → 외부 80/443 → Nginx Proxy Manager → Forward Host/Port → 실제 애플리케이션 순서로 점검하세요. 중간 단계를 건너뛰지 않으면 ‘도메인은 맞는데 왜 안 열리지?’ 같은 문제를 훨씬 빠르게 좁힐 수 있습니다.
예를 들어 도메인은 서버를 제대로 가리키고 Nginx Proxy Manager 화면에도 접속되지만 Proxy Host에서 502 계열 오류가 발생한다면, 외부 DNS보다 Nginx Proxy Manager와 백엔드 서비스 사이의 연결을 먼저 의심해볼 수 있습니다.
Docker를 사용한다면 컨테이너의 네트워크도 확인해야 합니다. Nginx Proxy Manager 컨테이너에서 다른 컨테이너의 이름을 목적지로 사용할 계획이라면 두 컨테이너 사이에 실제 통신 가능한 Docker 네트워크가 구성되어 있어야 합니다.
반대로 내부 IP와 호스트에 공개된 포트를 목적지로 사용하는 구성이라면 Nginx Proxy Manager가 그 주소에 접근할 수 있는지 확인하면 됩니다. 어떤 방식이든 중요한 것은 브라우저에서 보이는 주소가 아니라 Nginx Proxy Manager 기준에서 목적지에 도달할 수 있느냐입니다.
Nginx Proxy Manager 도메인 연결은 한 번 성공했다고 끝나는 설정도 아닙니다. 서버 IP 변경, 공유기 교체, DNS 변경, Docker 네트워크 변경, 애플리케이션 포트 변경 등이 생기면 기존 Proxy Host가 더 이상 올바른 목적지를 가리키지 않을 수 있습니다.
특히 가정용 인터넷에서 공인 IP가 고정되어 있지 않다면 주소가 바뀌었을 때 DNS 레코드가 예전 주소를 계속 가리키는 상황을 고려해야 합니다. 이런 환경에서는 사용 중인 DNS 사업자가 지원하는 동적 DNS 갱신 방법 등을 검토할 수 있습니다.
SSL 인증서도 마찬가지입니다. 자동 갱신을 사용하더라도 인증에 필요한 DNS나 네트워크 조건이 나중에 깨지면 갱신에 실패할 수 있습니다. 따라서 도메인을 장기간 운영한다면 인증서 만료 상태와 갱신 오류를 주기적으로 확인하는 편이 좋습니다.
셀프호스팅에서 중요한 것은 ‘설정값을 외우는 것’보다 요청 경로를 이해하는 것입니다. DNS는 입구를 찾고, 공유기와 방화벽은 요청을 서버까지 보내며, Nginx Proxy Manager는 도메인을 보고 실제 애플리케이션을 선택합니다. 이 구조를 알면 다른 리버스 프록시를 사용할 때도 같은 원리로 문제를 찾을 수 있습니다.
자주 묻는 질문 FAQ
로컬 IP와 포트로만 사용할 서비스라면 반드시 필요한 것은 아닙니다. 하지만 app.example.com처럼 외부에서 기억하기 쉬운 주소와 일반적인 HTTPS 인증서를 사용하려면 자신이 제어할 수 있는 도메인을 준비하는 것이 편리합니다.
HTTP-01 검증은 80번 포트에서 시작하므로 이 방식을 사용한다면 접근 가능해야 합니다. 80번 포트를 사용할 수 없다면 DNS TXT 레코드로 검증하는 DNS-01 등 환경에 맞는 다른 ACME Challenge 방식을 검토할 수 있습니다.
가능합니다. 예를 들어 cloud.example.com과 app.example.com을 같은 서버 쪽으로 보내고, Nginx Proxy Manager에서 각각 다른 Proxy Host와 내부 포트를 지정할 수 있습니다.
역할이 다릅니다. Cloudflare의 프록시를 사용하면 인터넷과 원본 서버 사이에 Cloudflare 네트워크가 위치하고, Nginx Proxy Manager는 서버 쪽에서 도메인별로 실제 내부 서비스를 선택해 요청을 전달하는 역할을 맡을 수 있습니다.
Forward Hostname/IP와 Forward Port가 실제 서비스 주소와 맞는지 먼저 확인하세요. Docker 컨테이너 이름을 사용했다면 Nginx Proxy Manager와 대상 컨테이너 사이의 Docker 네트워크 통신도 확인하는 것이 좋습니다.
📖 핵심 용어 미니 사전
본문에 나온 용어가 낯설다면 아래에서 먼저 확인해보세요.
클라이언트 요청을 먼저 받은 뒤 설정된 규칙에 따라 내부의 실제 웹 서버나 애플리케이션으로 전달하는 서버입니다.
사람이 사용하는 도메인 이름을 서버를 찾는 데 필요한 IP 주소 등의 정보와 연결해주는 시스템입니다.
Nginx Proxy Manager에서 특정 도메인으로 들어온 요청을 어느 호스트와 포트로 전달할지 지정하는 프록시 설정입니다.
HTTPS 통신에서 서버의 신원을 확인하고 클라이언트와 서버 사이의 암호화 연결을 구성하는 데 사용되는 인증서입니다.
Let’s Encrypt 같은 인증기관이 인증서를 발급하기 전에 신청자가 해당 도메인을 제어하는지 검증하는 절차입니다.
🔗 공식 자료
설치 방법이나 인증 방식은 소프트웨어 업데이트에 따라 달라질 수 있습니다. 실제 서버를 설정할 때는 아래 공식 문서를 함께 확인하는 것이 좋습니다.
📖 출처
- Nginx Proxy Manager — Guide
- Nginx Proxy Manager — Full Setup Instructions
- Cloudflare Developers — Create DNS Records
- Let’s Encrypt — Challenge Types
- Let’s Encrypt — Best Practice: Keep Port 80 Open
Nginx Proxy Manager 도메인 연결은 DNS로 서버의 입구를 찾고, Nginx Proxy Manager가 도메인별로 실제 내부 서비스를 연결하는 구조입니다. DNS → 80·443 포트 → Proxy Host → 내부 서비스 → SSL 순서로 이해하면 설정과 문제 해결이 훨씬 쉬워집니다.
