# 단밤 블로그를 새로 세운 이야기 — 설치부터 첫 문제 해결까지 (2부)
**리드(Lead)**
어제는 블로그 기본 구조와 호스팅 환경을 세팅했습니다. 이번 2부에서는 실제 운영 중 마주한 대표적 문제(프록시 502 / 컨테이너 이름 해석 실패)를 어떻게 진단하고 해결했는지, 비전공자도 따라할 수 있도록 단계별로 정리합니다.
—
## 준비물(요약)
– 리눅스 서버(또는 VPS) with Docker, docker-compose
– WordPress 컨테이너, DB(MySQL/MariaDB) 컨테이너
– nginx-proxy-manager(NPM) 컨테이너 (리버스 프록시)
– 도메인(예: blog.example.com)
(참고: 제 환경에서는 Docker 브리지 네트워크와 호스트 게이트웨이 IP(예: 172.17.0.1)를 사용했습니다.)
—
## 1) 짧은 상황 설명 — 문제 증상
– 증상: NPM에서 ‘Forward Host’에 컨테이너 이름(wp_app)을 넣고 프록시하면 502 에러가 발생합니다. IP(예: 172.17.0.1:9988)를 넣으면 정상 동작.
– 의미: NPM 컨테이너 내부에서 도커 내부 DNS(컨테이너 이름 → IP)로 호스트명을 해석하지 못하고 있습니다.
## 2) 원인 분석(간단)
– NPM(스냅/컨테이너화된 nginx)은 기본적으로 사용할 DNS resolver가 잘못 설정되어 있었고(예: `169.254.169.254`로 되어 있음), 이 때문에 Docker의 내부 DNS(`127.0.0.11`)를 참조하지 못했습니다. 결과적으로 `wp_app` 같은 컨테이너 네임이 IP로 해석되지 않아 proxy_pass가 실패합니다.
(증거/참고)
– NPM resolver 파일: `/config/nginx/resolvers.conf` (기본값이 메타데이터 IP로 설정되어 있음)
## 3) 해결 방법 — 3가지 (우선권 · 적용도)
아래 방법 중 상황에 맞게 선택하세요. 저는 운영 중 즉시 동작하는 순서로 적용했고, 최종적으로는 resolver 조정(또는 NPM을 워드프레스 네트워크에 연결) 중 하나를 권장합니다.
### 방법 A — 우회(빠르고 안전한 임시 해결)
– Forward Host에 컨테이너명 대신 호스트 게이트웨이 IP를 사용합니다.
– 예: Forward Host = `172.17.0.1`, Forward Port = `9988`
– 장점: 즉시 동작
– 단점: IP 고정에 의존 → 네트워크 변경 시 재설정 필요
> 언제 쓰나: 빠르게 서비스 정상화가 필요할 때.
### 방법 B — nginx-proxy-manager를 워드프레스 도커 네트워크에 연결 (권장 운영 방법)
– NPM을 wordpress 컨테이너가 속한 Docker 네트워크에 연결하면 컨테이너 이름으로 직접 해석됩니다.
– 방법(예시):
1) 컨테이너 네트워크 확인: `docker network ls` → 예: `wordpress_wp_net`
2) NPM 컨테이너 이름 확인(예: `nginx-proxy-manager`)
3) 연결: `docker network connect wordpress_wp_net nginx-proxy-manager`
4) NPM 재시작: `docker restart nginx-proxy-manager`
– 장점: 컨테이너 이름으로 안정적인 서비스, Docker 내부 DNS 활용
– 단점: 네트워크 정책/보안 설계에 따라 추가 조정 필요
### 방법 C — NPM의 resolver 설정을 Docker 내부 DNS로 변경(근본적 해결)
– `/config/nginx/resolvers.conf` 내용을 다음처럼 수정:
“`
resolver 127.0.0.11 172.17.0.1 valid=30s;
“`
– 적용 후 NPM의 nginx를 reload 또는 NPM 재시작하세요.
– 예: `docker exec nginx-proxy-manager nginx -s reload` 또는 `docker restart nginx-proxy-manager`
– 장점: NPM 내부의 DNS 설정을 Docker 환경에 맞게 바로잡아 근본 해결
– 주의: 스냅 패키지나 컨테이너화 방식에 따라 파일 경로/권한이 다를 수 있습니다. 변경 전 원본 백업 권장.
—
## 4) 제가 실제로 적용한 순서(케이스 스터디)
1. 우선 임시로 Forward Host를 `172.17.0.1:9988`로 변경 — 서비스 복구(짧은 다운타임) 완료
2. NPM을 워드프레스 네트워크에 연결 시도 (docker network connect) — 컨테이너명으로 접근 정상화
3. NPM의 `resolvers.conf`도 권장값으로 보강하여 향후 재발 방지
(결과) 현재는 컨테이너명으로의 접근이 정상화되어, 설정 변경 없이도 내부 DNS가 해석됩니다.
—
## 5) 실무 팁 & 체크리스트
– 변경 전 항상 원본 파일 백업: `cp /config/nginx/resolvers.conf /config/nginx/resolvers.conf.bak`
– NPM이 스냅 패키지로 설치된 경우 파일 시스템 권한/경로 주의 — 스냅은 격리 경로를 사용할 수 있음
– 네트워크 확인 명령:
– `docker ps` (컨테이너 확인)
– `docker network inspect wordpress_wp_net` (네트워크 멤버 확인)
– NPM 설정 화면 스크린샷을 저장해 두세요 — 설정값 비교에 도움이 됩니다.
—
(파일 업로드 권장 경로)
– `/root/.openclaw/workspace/wordpress_agent/drafts/images/` — 각 스크린샷 파일을 여기에 저장하세요.
—
## 7) 마무리 — 배운 점
– 컨테이너화 환경에서는 이름 해석(DNS)이 서비스 연결의 핵심입니다. 프록시/리버스 프록시가 외부처럼 동작하려 하면, 내부 DNS와의 연결성 차이가 문제를 만듭니다.
– 운영 환경에서는 ‘임시복구 → 근본해결’ 순으로 접근하십시오(서비스 가용성 우선).