아래는 로컬에 도커로 워드 프레스 설치후 외부 공개를 위해 cloudflared에 터널 연결시 발생할 수 있습니다.
Cloudflare에서 터널이 Healthy로 표시되는데 도메인을 열면 502 Bad Gateway가 뜬다면, 먼저 cloudflared가 WordPress에 접속할 때 사용하는 주소를 확인하세요.
Windows 브라우저에서 열리는 주소가 Docker 컨테이너 안에서도 같은 대상을 가리키는 것은 아닙니다.
이 글은 Windows 11의 Docker Desktop에서 WordPress와 cloudflared를 별도 컨테이너로 실행하는 구성을 다룹니다. 내부 웹 서버는 HTTP 80번 포트, Windows에 공개한 포트는 8080인 예시입니다. 다른 배치에서는 주소가 달라집니다. 확인일: 2026년 9월 27일.
1. Healthy가 확인해 주는 구간
요청 경로를 세 구간으로 나눠 보세요.
방문자 → Cloudflare → cloudflared → WordPressHealthy는 터널의 Cloudflare 연결 상태입니다. 이것만으로 WordPress가 정상 응답한다고 판단할 수는 없습니다. Cloudflare 터널 상태·오류 문서를 기준으로 터널 연결과 사이트 응답을 따로 확인해야 합니다.
Cloudflare는 터널 경로에서 원본 서비스에 도달하지 못했다는 메시지와 함께 발생하는 502를 cloudflared와 내부 서비스 사이의 문제로 설명합니다. 다만 502라는 숫자만 보고 모든 장애의 원인을 터널 주소로 확정하지 마세요. 오류 문구와 터널 로그를 함께 봐야 합니다.
2. Service URL은 cloudflared의 실행 위치에 맞춥니다
아래 두 가지 중 내 환경에 해당하는 구성을 먼저 고르세요.
- cloudflared와 WordPress가 같은 Docker 네트워크에 있음: Compose 서비스 이름이
wordpress이고 내부 포트가 80이면http://wordpress:80을 사용합니다. - cloudflared가 Windows에서 직접 실행됨: WordPress의 Windows 공개 포트가 8080이고 실제로 접속된다면
http://127.0.0.1:8080을 사용합니다.
예를 들어 포트 매핑이 127.0.0.1:8080:80이면 Windows에서 접근하는 포트는 8080, 컨테이너 내부 포트는 80입니다. 같은 Docker 네트워크의 서비스끼리는 내부 포트를 사용합니다. 컨테이너 IP를 외우기보다 서비스 이름을 사용하는 이유도 여기에 있습니다. IP는 재생성 때 바뀔 수 있습니다. Docker Compose 네트워크 문서
일반적인 별도 네트워크 공간을 사용하는 컨테이너에서 127.0.0.1은 그 컨테이너 자신을 가리킵니다. Windows 호스트의 서비스에 접속해야 하는 별도 구성이라면 Docker Desktop의 host.docker.internal도 검토할 수 있지만, 대상 서비스의 바인딩과 접근 가능 여부를 확인해야 합니다. 이 글의 같은 네트워크 구성에서는 이 우회 주소가 필요하지 않습니다. Docker Desktop 네트워킹 문서
3. 설정을 바꾸기 전, 실행 상태와 네트워크를 확인합니다
Docker Desktop이 실행된 Windows PowerShell에서 다음 읽기 전용 명령을 실행하세요. Docker 엔진 접근 권한이 필요합니다.
docker ps --format "{{.Names}} {{.Status}} {{.Ports}}"WordPress와 cloudflared 컨테이너가 실행 중인지 확인합니다. Docker 엔진 연결 오류라면 Desktop 실행 상태부터 확인하세요. Up은 프로세스 실행 상태이므로 실제 웹 응답도 별도로 확인합니다.
다음 명령의 컨테이너 이름은 위 결과에 표시된 실제 이름으로 바꿔 주세요.
docker inspect --format '{{range $name, $net := .NetworkSettings.Networks}}{{$name}} {{end}}' WORDPRESS_CONTAINER
docker inspect --format '{{range $name, $net := .NetworkSettings.Networks}}{{$name}} {{end}}' CLOUDFLARED_CONTAINER두 결과에 공통 네트워크 이름이 있는지 확인합니다. 없다면 wordpress라는 이름을 사용하는 통신 조건부터 충족되지 않은 것입니다. 네트워크를 수정해야 한다면 Compose 설정을 검토하는 별도 작업으로 진행하세요.
Windows 공개 포트를 확인하는 명령은 다음과 같습니다. 실제 공개 포트가 다르면 8080을 바꾸세요.
curl.exe -I --max-time 10 http://127.0.0.1:8080/wp-login.php200은 HTTP 응답 성공, 301·302는 다른 주소로 이동하라는 응답입니다. 이동 응답이 왔다면 Location도 확인하세요. 이 검사는 Windows에서의 접근만 확인하며, cloudflared 컨테이너에서의 접근까지 보장하지 않습니다.
4. 대상 주소·포트·프로토콜을 한 항목씩 확인합니다
Cloudflare에서 해당 터널의 게시된 애플리케이션 경로를 열고, 접속하려는 호스트 이름의 Service URL을 확인합니다. 화면에 HTTP 유형과 주소 입력칸이 따로 있으면 HTTP를 선택하고 wordpress:80을, 전체 URL 입력칸이면 http://wordpress:80을 입력하는 방식입니다. 실제 서비스 이름과 내부 포트에 맞춰야 합니다.
변경 전 값을 기록하고 주소 한 항목만 수정한 뒤 다시 접속하세요. 내부 서비스가 HTTP라면 외부 도메인이 HTTPS라는 이유만으로 원본 주소도 HTTPS로 바꾸지는 마세요. 원본이 실제로 제공하는 프로토콜과 맞아야 합니다.
아직 실패하면 다음 로그를 접속 직후 확인합니다. 컨테이너 이름은 환경에 맞게 바꾸세요.
docker logs --since 5m --tail 50 CLOUDFLARED_CONTAINERconnection refused: 대상 프로세스, 수신 포트, 주소를 확인합니다.no such host: 서비스 이름과 공통 네트워크를 확인합니다.x509관련 오류: HTTPS 원본의 인증서 이름·신뢰 설정을 확인합니다.
로그는 원인 후보를 좁히는 단서입니다. Cloudflare 공식 오류별 안내와 대조하세요. 로그를 공유할 때는 토큰·도메인·IP 등 민감한 정보를 가립니다.
5. 이 구성에서 직접 확인한 결과
작성 시점의 Windows 11·Docker Desktop 환경(Docker Engine 28.1.1, Compose 2.35.1)에서 WordPress 7.1.2와 cloudflared 2026.9.3이 공통 네트워크를 사용하는 것을 확인했습니다. 터널 설정을 변경하지 않고, cloudflared와 네트워크 공간을 공유하는 임시 검증 컨테이너에서 두 주소를 요청했습니다.
http://wordpress:80/wp-login.php: HTTP 302, 연결 오류 없음.http://127.0.0.1:8080/wp-login.php: HTTP 응답 없음, cURL 오류 7(연결 실패).- Windows에서
http://127.0.0.1:8080/wp-login.php요청: HTTP 302.
이 결과는 같은 문자열의 주소라도 실행 위치에 따라 연결 대상이 달라짐을 보여 줍니다. 302만으로 로그인이나 사이트 전체가 정상이라고 결론 내리지는 않았습니다. 운영 중인 터널을 잘못 설정해 502를 일부러 재현하지도 않았습니다. 과거 장애의 원인을 이번 시험만으로 확정할 수는 없습니다.
6. 해결 확인과 되돌리기
수정 후 외부 도메인에서 홈페이지와 로그인 화면을 각각 열고, 새 요청 시 터널 오류가 다시 기록되는지 확인하세요. 도메인이 여러 개면 각각 검사합니다. 502가 사라진 뒤 다른 주소로 이동하거나 로그인 반복이 생기면, 그 증상은 WordPress URL·리디렉션 설정을 확인할 다음 단계입니다.
변경 후 문제가 커지면 기록해 둔 이전 Service URL로 되돌립니다. 이 진단을 위해 데이터베이스를 초기화하거나 볼륨을 삭제할 필요는 없습니다. 출처와 명령을 자신의 배치에 맞춰 확인하고, 한 번에 한 항목씩 바꾸는 것이 어느 변경이 효과가 있었는지 판단하는 데 도움이 됩니다.
이 글이 도움이 되었나요?