분류: 홈서버·셀프호스팅

Nginx Proxy Manager 인증서 발급·갱신 실패 해결 순서

발급 실패의 원인은 대부분 셋 중 하나입니다 — 도메인이 나를 가리키는가, 검증 경로가 열려 있는가, 발급 한도에 걸렸는가. 로그 읽는 법과 원인별 확인 순서를 정리했습니다.

마지막 확인

이런 상황일 때

프록시 호스트에 인증서를 붙이려는데 발급이 실패합니다. 화면에는 자세한 이유가 없고, 만료가 다가오는데 갱신도 조용히 실패하고 있는 것 같습니다.

한 줄 결론

원인은 대부분 세 갈래입니다 — ① 도메인이 이 서버를 가리키는가 ② 검증 경로(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 를 바꿨다면 갱신 시점에 조용히 실패합니다 — 만료 알림 전에 로그를 한 번 보는 이유입니다.

안전한 행동 순서

  1. 아래 ① 로 도메인이 지금 어느 주소를 가리키는지 확인합니다. 이 서버가 아니면 DNS 부터 고칩니다.
  2. 바깥 회선에서 http://내도메인/ 이 닿는지 확인합니다 — 포트포워딩(80)과 방화벽을 봅니다.
  3. 요청 화면의 Test 버튼으로 도달성을 확인한 뒤에 저장합니다.
  4. 실패했다면 아래 ② 로 로그에서 실패 이유를 찾습니다 — DNS·연결·한도 중 무엇인지 문구로 갈립니다.
  5. 한도 문구라면 공식 문서에서 한도 기준을 확인하고 기다린 뒤 다시 시도합니다.
  6. 와일드카드나 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·공유기)이 없는지부터 보세요.

함께 읽기

공식 출처

마지막 검토일: 2026-08-07

공식 출처

내용이 잘못되었나요? 수정 요청