이런 상황일 때
프록시 호스트에 인증서를 붙이려는데 발급이 실패합니다. 화면에는 자세한 이유가 없고, 만료가 다가오는데 갱신도 조용히 실패하고 있는 것 같습니다.
한 줄 결론
원인은 대부분 세 갈래입니다 — ① 도메인이 이 서버를 가리키는가 ② 검증 경로(80 포트)가 바깥에서 닿는가 ③ 발급 한도에 걸렸는가. 요청 화면의 안내문 그대로, 도메인이 먼저 이 설치를 가리키고 있어야 합니다. 화면이 말해 주지 않는 이유는 로그에 있습니다.
핵심 개념
① 도메인이 나를 가리키는가
발급 기관은 그 도메인으로 직접 찾아와 확인합니다. 요청 화면의 실측 문구가 이것입니다 — 'These domains must be already configured to point to this installation.' DNS 가 다른 곳(예: 옛 서버, 프록시 서비스)을 보고 있으면 반드시 실패합니다.
② 검증 경로가 열려 있는가
기본 방식(HTTP 검증)은 바깥에서 80 포트로 들어와 확인 파일을 읽습니다. 공유기 포트포워딩·방화벽· 통신사 차단 중 하나라도 막히면 실패합니다. 안에서 잘 열리는 것과 밖에서 닿는 것은 다릅니다.
③ 발급 한도
Let's Encrypt 에는 도메인·실패 횟수 기준의 한도가 있습니다(수치는 공식 문서 확인). 실패 상태로 재시도를 반복하면 한도에 먼저 닿아, 원인을 고친 뒤에도 기다려야 하는 상황이 됩니다 — 실패하면 재시도 전에 원인부터입니다.
화면이 아니라 로그가 말한다
실패 화면은 짧고, 진짜 이유는 로그에 있습니다. 컨테이너 로그(docker logs)와 함께, 실측 기준 데이터 폴더의 /data/logs/ 아래에 접속·오류 로그 파일들이 있습니다.
이런 분에게 해당됩니다
- NPM 으로 도메인·인증서를 관리하는 홈서버 운영자
- 발급 실패가 반복되는데 이유를 모르는 분
- 만료 임박인데 갱신이 안 되는 분
확인해야 할 항목
- 도메인 조회(아래 ①)가 이 서버의 주소를 답하는가
- 바깥 회선(휴대폰 데이터 등)에서 80 포트가 닿는가
- 로그(아래 ②)에 실패 이유가 찍혀 있는가
- 짧은 시간에 발급 시도를 반복하지 않았는가
- 요청 화면의 Test 버튼으로 도달성을 먼저 확인했는가
잘못 이해하기 쉬운 부분
오해 실패하면 될 때까지 다시 시도하면 된다.
사실 실패 재시도에도 한도가 있습니다. 거듭 반복하면 한도에 닿아 원인을 고친 뒤에도 기다려야 합니다. 진단이 먼저, 재시도는 원인 제거 후 한 번입니다.
오해 집 안 브라우저에서 사이트가 열리니 80 포트는 문제없다.
사실 안에서 여는 것과 바깥에서 들어오는 것은 경로가 다릅니다. 검증은 바깥에서 오므로, 확인도 바깥 회선(휴대폰 데이터 등)에서 해야 의미가 있습니다.
오해 갱신은 자동이니 신경 쓸 것이 없다.
사실 자동 갱신도 같은 검증을 다시 통과해야 합니다. 발급 후 포트·DNS 를 바꿨다면 갱신 시점에 조용히 실패합니다 — 만료 알림 전에 로그를 한 번 보는 이유입니다.
안전한 행동 순서
- 아래 ① 로 도메인이 지금 어느 주소를 가리키는지 확인합니다. 이 서버가 아니면 DNS 부터 고칩니다.
- 바깥 회선에서 http://내도메인/ 이 닿는지 확인합니다 — 포트포워딩(80)과 방화벽을 봅니다.
- 요청 화면의 Test 버튼으로 도달성을 확인한 뒤에 저장합니다.
- 실패했다면 아래 ② 로 로그에서 실패 이유를 찾습니다 — DNS·연결·한도 중 무엇인지 문구로 갈립니다.
- 한도 문구라면 공식 문서에서 한도 기준을 확인하고 기다린 뒤 다시 시도합니다.
- 와일드카드나 80 포트를 열 수 없는 환경이면 DNS 검증 방식(공식 문서)을 검토합니다.
① 도메인이 어디를 가리키는지 (읽기만)
nslookup <도메인>
답이 이 서버의 공인 주소가 아니면 그것이 원인입니다. 없는 도메인은 NXDOMAIN 으로 나옵니다 — 실측으로 확인한 출력입니다 · 확인: 2026-08-07 · wp3 VM (Debian)
② 실패 이유를 로그에서 (읽기만)
docker logs --tail 100 <프록시컨테이너이름> docker exec <프록시컨테이너이름> ls /data/logs/
화면에 없는 이유가 여기 있습니다. 데이터 폴더의 logs 아래 파일들은 실측(v2.15.1)에서 확인한 위치입니다 · 확인: 2026-08-07 · wp3 VM (NPM v2.15.1 격리 시험 환경)
확인 체크리스트
- 도메인이 이 서버를 가리키는 것을 확인했다
- 바깥 회선에서 80 포트 도달을 확인했다
- Test 버튼을 먼저 눌러 봤다
- 로그에서 실패 이유를 읽었다
- 재시도 전에 원인을 제거했다
관련 도구와 버전 페이지
- Nginx Proxy Manager 버전 추적
이 사이트가 NPM 릴리스를 추적합니다. 대표 페이지에서 현재 안정판과 배포일을 확인할 수 있습니다.
자주 묻는 것
화면에는 실패라고만 나옵니다.
정상입니다 — 화면은 요약이고 이유는 로그에 있습니다. ② 의 두 곳을 보면 DNS 실패, 연결 시간 초과, 한도 초과가 문구로 구분됩니다.
집 공유기가 80 포트를 막습니다(통신사 차단).
HTTP 검증은 80 이 필수라 그 환경에서는 실패가 정상입니다. DNS 검증 방식(도메인 관리사의 API 로 확인)이 공식 대안입니다 — 방식 설명은 아래 공식 문서에 있습니다.
며칠 뒤 만료인데 갱신이 계속 실패합니다.
지금이 진단할 때입니다 — 만료 후에도 같은 원인으로 실패합니다. ①·② 순서로 원인을 찾고, 발급 후 바뀐 것(포트·DNS·공유기)이 없는지부터 보세요.
- Docker 컨테이너가 계속 재시작될 때 로그 확인 방법
- Docker 볼륨과 바인드 마운트의 차이
- Nginx Proxy Manager 공식 가이드 — Nginx Proxy Manager
- Let's Encrypt 발급 한도 — Let's Encrypt
- Let's Encrypt 검증 방식 — Let's Encrypt
마지막 검토일: 2026-08-07