Docker WordPress 주소에 :8080이 붙던 이유

WANY BLOG를 처음 Docker로 올렸을 때 외부 접속 구조는 단순했다. 방문자는 https://wanyblog.com으로 접속하고, 기존 Reverse Proxy가 요청을 WordPress가 열려 있는 내부 :8080 포트로 넘기는 방식이었다.

그런데 도메인을 열면 주소 뒤에 :8080이 붙는 쪽으로 리다이렉트됐다. :8080은 Reverse Proxy가 내부에서 접속할 때만 쓰는 포트라 외부 주소에 나타날 이유가 없었다.

처음 봤을 때는 Docker 포트 매핑이나 Reverse Proxy 규칙을 바꿔야 할 것처럼 보일 수 있다. 하지만 WANY 구성에서는 :8080 자체가 잘못된 게 아니었다. 외부에서는 443으로 접속하고 내부에서만 8080으로 넘기는 구조는 그대로 유지해야 했다.

8080을 없애는 대신 WordPress가 알고 있는 주소를 확인했다

당시 WordPress 데이터베이스의 home과 siteurl을 확인한 결과, 두 값이 공개 도메인이 아니라 내부 upstream 주소를 보고 있었다.

개념적으로는 이런 상태였다.

브라우저
  ↓ https://wanyblog.com
Reverse Proxy
  ↓ http://<내부 주소>:8080
WordPress

Reverse Proxy 입장에서는 마지막 줄의 내부 주소가 맞다. 문제는 WordPress까지 그 주소를 자기 공개 주소로 알고 있었다는 점이었다.

WordPress의 home과 siteurl은 단순히 관리자 화면에 표시되는 값이 아니다. WordPress 공식 문서에서도 Site Address와 WordPress Address가 프런트엔드와 관리자 영역을 비롯해 WordPress 전반에서 URL을 만드는 데 사용된다고 설명한다.

그래서 내부 주소가 저장돼 있으면 리다이렉트나 REST URL 같은 곳에 :8080이 따라 나올 수 있다. 이번 문제도 포트 매핑을 없앨 일이 아니라 **내부 upstream 주소와 외부 공개 주소를 분리해야 하는 문제**였다.

두 값은 공개 주소인 https://wanyblog.com으로 맞췄다.

home    = https://wanyblog.com
siteurl = https://wanyblog.com

WANY 프로젝트에는 같은 문제가 다시 생기지 않도록 공개 URL을 별도 설정값으로 두고, WordPress 설정에서도 그 값을 사용하도록 했다.

Reverse Proxy 뒤에서는 HTTPS 인식도 같이 맞췄다

URL만 바꾸고 끝내지는 않았다.

WANY BLOG는 브라우저와 Reverse Proxy 사이에서는 HTTPS를 사용하지만, Reverse Proxy에서 WordPress로 넘어가는 내부 구간은 HTTP다. 이런 구조에서는 WordPress가 현재 요청을 HTTP로 오해하면 관리자 주소나 리다이렉트가 다시 꼬일 수 있다.

현재 구성의 핵심만 줄이면 다음과 같다.

define('WP_HOME', 'https://wanyblog.com');
define('WP_SITEURL', 'https://wanyblog.com');
define('FORCE_SSL_ADMIN', true);

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])) {
    $forwarded_proto = strtolower(
        trim(explode(',', $_SERVER['HTTP_X_FORWARDED_PROTO'])[0])
    );

    if ('https' === $forwarded_proto) {
        $_SERVER['HTTPS'] = 'on';
        $_SERVER['SERVER_PORT'] = '443';
    }
}

실제 저장소에서는 도메인을 코드에 반복해서 적는 대신 WORDPRESS_PUBLIC_URL 값을 사용한다.

이 처리는 Reverse Proxy가 X-Forwarded-Proto를 정상적으로 전달한다는 전제다. WordPress 공식 HTTPS 문서에도 Reverse Proxy가 앞에서 SSL을 처리하고 WordPress 쪽은 HTTP로 동작하는 경우, HTTP_X_FORWARDED_PROTO를 보고 HTTPS 요청으로 인식시키는 방법이 안내돼 있다.

중요한 건 여기서도 Reverse Proxy의 목적지를 :8080에서 다른 포트로 바꾼 것이 아니라는 점이다. 내부 upstream은 그대로 두고 WordPress가 외부에서 보이는 자기 주소를 정확히 알게 만들었다.

홈 화면 하나만 열어보고 끝내지 않았다

수정 후에는 공개 URL이 다른 경로에서도 다시 내부 주소로 바뀌지 않는지 확인했다.

2026년 8월 30일에 남긴 검증 기록에서는 HTTPS 홈이 200으로 응답했고, HTTP 접속은 정확히 https://wanyblog.com/으로 이동했다. REST API도 200으로 응답하면서 공개 도메인을 기준으로 한 URL을 돌려줬다.

/wp-admin/ 역시 공개 HTTPS 로그인 주소로 이동했다. 테스트한 Location 헤더에서는 :8080이나 내부 주소가 더 이상 나오지 않았다.

이 확인이 중요했던 이유는 홈 화면만 정상으로 보여도 WordPress 내부 설정이 덜 정리돼 있으면 관리자 페이지나 REST 응답에서 예전 주소가 다시 튀어나올 수 있기 때문이다.

WANY BLOG는 지금도 Reverse Proxy의 내부 upstream으로 :8080을 사용한다. 없앤 것은 포트가 아니라 **그 내부 주소가 WordPress의 공개 주소 역할까지 하던 상태**였다.

Reverse Proxy 뒤 WordPress에서 도메인에 갑자기 내부 포트가 붙는다면, 포트 매핑부터 바꾸기 전에 home과 siteurl이 무엇을 보고 있는지, 그리고 WordPress가 프록시를 거친 HTTPS 요청을 제대로 인식하고 있는지부터 확인하는 편이 빠르다.