개인 블로그를 Synology NAS에서 WordPress로 운영하다 보면, 웹호스팅을 사용할 때보다 직접 확인하고 관리해야 할 부분이 조금 더 많습니다.
평소에는 문제없이 잘 운영되다가도 인증서, Cloudflare, Reverse Proxy, 포트 설정 중 하나에서 문제가 생기면 사이트 전체 접속이 막힐 수 있습니다.
이번에는 제가 운영 중인 워드프레스 블로그에 갑자기 접속이 되지 않는 문제가 발생했습니다.
처음에는 WordPress 문제인지, Cloudflare 문제인지, NAS 문제인지 바로 판단하기 어려웠습니다. 하지만 하나씩 확인해보니 원인은 Let’s Encrypt 인증서 만료였습니다.
조금 더 정확히 말하면, 보안 강화를 위해 기존에 80번 포트를 막아둔 상태였고, 이 설정이 Let’s Encrypt 인증서 자동 갱신 과정에 영향을 준 것으로 보였습니다.
인증서가 정상적으로 갱신되지 못한 상태에서 만료되었고, Cloudflare Full(strict) 설정이 원본 서버의 만료된 인증서를 신뢰하지 못하면서 526 오류가 발생한 것입니다.
이번 글에서는 Synology NAS에서 운영 중인 WordPress 블로그가 Cloudflare 526 오류로 접속되지 않았던 원인과, Let’s Encrypt 인증서 갱신, 80번 포트 재개방, Cloudflare 설정 복구, wp-admin 리디렉션 정리까지의 과정을 정리해보겠습니다.
먼저 전체 흐름을 간단히 정리하면
이번 문제의 흐름을 먼저 간단히 정리하면 다음과 같습니다.
- 블로그 접속 시 Cloudflare 526 Invalid SSL Certificate 오류가 발생했습니다.
- DSM에서 확인해보니 블로그 도메인에 연결된 Let’s Encrypt 인증서가 만료되어 있었습니다.
- 기존에는 보안 강화를 위해 외부 80번 포트를 막아둔 상태였습니다.
- 이로 인해 Let’s Encrypt 인증서 자동 갱신 과정에 문제가 생겼을 가능성이 있었습니다.
- 우선 Cloudflare SSL 모드를 Full(strict)에서 Full로 임시 변경해 접속을 복구했습니다.
- 이후 80번 포트를 다시 열고 DSM에서 인증서를 갱신했습니다.
- 인증서 갱신 후 Cloudflare SSL 모드를 다시 Full(strict)로 되돌렸습니다.
- 마지막으로 /wp-admin 경로에서 생긴 HTTP 리디렉션 문제를 Cloudflare Redirect Rule로 정리했습니다.
단순히 “인증서가 만료됐다”로 끝나는 문제가 아니라, Cloudflare, Synology DSM, Let’s Encrypt, 80번 포트, Reverse Proxy가 함께 연결된 문제였습니다.
처음 나타난 증상
블로그 주소로 접속했을 때 평소처럼 워드프레스 화면이 열리지 않았습니다.
대신 Cloudflare 오류 화면이 표시되었습니다. 화면을 보면 Browser와 Cloudflare는 정상으로 표시되지만, Host 쪽에는 Error가 표시되어 있었습니다.
오류 내용은 다음과 같았습니다.
526 Invalid SSL Certificate
처음 이 화면을 봤을 때는 블로그 서버 자체가 멈춘 것처럼 느껴졌습니다. 하지만 오류 화면을 자세히 보면 문제의 방향을 어느 정도 짐작할 수 있었습니다.
방문자 브라우저와 Cloudflare 사이의 연결은 정상이고, Cloudflare와 원본 서버 사이에서 문제가 발생한 상태였습니다.
쉽게 말하면 WordPress 글이나 테마가 깨진 문제가 아니라, Cloudflare가 제 NAS 원본 서버의 SSL 인증서를 신뢰하지 못한 상황에 가까웠습니다.
이때부터 WordPress 설정이나 플러그인보다 SSL 인증서 상태를 먼저 확인해야겠다고 판단했습니다.
왜 Cloudflare 526 오류가 발생했을까
제 블로그는 Cloudflare SSL/TLS 설정을 Full(strict) 모드로 사용하고 있었습니다.
FFull(strict)는 방문자와 Cloudflare 사이뿐만 아니라, Cloudflare와 원본 서버 사이의 인증서까지 확인하는 방식입니다.
Cloudflare SSL/TLS 설정에서 Full(strict) 모드가 적용된 화면입니다. 이 모드에서는 원본 서버의 SSL 인증서가 정상이어야 Cloudflare와 NAS 사이의 연결이 유지됩니다.
쉽게 말하면 Cloudflare가 제 NAS에 접속할 때도 “이 서버의 SSL 인증서가 유효한가?”를 확인합니다.
이 설정은 보안 측면에서는 좋은 방식입니다. 하지만 원본 서버의 인증서가 만료되었거나, 도메인과 맞지 않거나, 신뢰할 수 없는 인증서라면 Cloudflare가 원본 서버와의 연결을 차단할 수 있습니다.
이번에 표시된 526 Invalid SSL Certificate 오류도 이 부분과 관련이 있었습니다.
Cloudflare 자체가 문제가 생긴 것이 아니라, Cloudflare가 제 원본 서버의 SSL 인증서를 확인하는 과정에서 문제가 발생한 것입니다.
그래서 이 화면을 확인한 뒤에는 WordPress 내부 설정보다 먼저 NAS에 적용된 인증서 상태를 확인해야겠다고 판단했습니다.
먼저 한 조치, Cloudflare SSL 모드 임시 변경
사이트가 완전히 접속되지 않는 상태였기 때문에 먼저 임시 복구가 필요했습니다.
그래서 Cloudflare의 SSL/TLS 설정에서 Full(strict)를 잠시 Full로 변경했습니다.
Full 모드는 Cloudflare와 원본 서버 사이의 암호화 통신은 유지하지만, 원본 인증서를 Full(strict)만큼 엄격하게 검증하지는 않습니다.
그래서 원본 인증서가 만료된 상황에서도 일단 사이트 접속을 임시로 복구하는 데 도움이 될 수 있습니다.
다만 이 설정은 어디까지나 임시 조치입니다.
인증서 문제를 해결한 뒤에는 다시 Full(strict)로 되돌리는 것이 좋습니다. 저는 사이트 접속 상태를 우선 확인한 뒤, 인증서 갱신 작업을 진행했습니다.
Synology DSM에서 인증서 상태 확인
다음으로 Synology DSM에 접속해 인증서 상태를 확인했습니다.
DSM에서 인증서를 확인하는 경로는 다음과 같습니다.
제어판 → 보안 → 인증서
DSM 인증서 화면에서 블로그 도메인에 연결된 인증서가 만료된 것을 확인했습니다.
정상 인증서라면 만료 예정일이 여유 있게 표시되지만, 제 경우에는 인증서가 이미 만료된 상태였습니다.
이 단계에서 문제 원인이 거의 확실해졌습니다.
처음에는 WordPress나 Docker 문제를 의심할 수도 있었지만, 인증서 상태를 확인하면서 이번 접속 장애는 NAS에 적용된 SSL 인증서 만료 문제라는 것을 알 수 있었습니다.
Let’s Encrypt 인증서 갱신 시도
DSM 인증서 화면에서 해당 도메인 인증서를 선택하고 갱신을 시도했습니다.
하지만 처음에는 인증서 갱신이 바로 성공하지 않았습니다.
이때 생각해야 할 부분이 있었습니다.
Synology DSM에서 Let’s Encrypt 인증서를 일반 방식으로 갱신할 때는 외부에서 도메인 소유 확인을 할 수 있어야 합니다.
상황에 따라 HTTP 경로를 통해 인증 확인이 이루어질 수 있습니다.
예를 들면 다음과 같은 형태입니다.
http://도메인/.well-known/acme-challenge/...
즉 Let’s Encrypt가 외부에서 제 도메인으로 접근했을 때, 인증 확인 경로에 도달할 수 있어야 합니다.
그런데 저는 평소 보안 강화를 위해 HTTPS 중심으로 운영하고 있었고, 기존에는 외부 80번 포트를 막아둔 상태였습니다.
이 설정이 인증서 자동 갱신 실패의 원인 중 하나였을 가능성이 있다고 판단했습니다.
80번 포트를 다시 개방한 이유
이번 문제를 겪기 전에는 보안 강화를 위해 외부 80번 포트를 막아둔 상태였습니다.
블로그는 HTTPS로 운영하고 있었고, Cloudflare와 NAS 사이도 SSL을 사용하는 구조였기 때문에 “굳이 80번 포트를 열어둘 필요가 있을까?”라고 생각했습니다.
하지만 이번에 Let’s Encrypt 인증서가 만료되고, DSM에서 인증서 갱신을 시도하면서 80번 포트의 역할을 다시 생각하게 되었습니다.
Synology DSM에서 Let’s Encrypt 인증서를 일반 방식으로 발급하거나 갱신할 때는 외부에서 도메인 소유 확인을 해야 하는 경우가 많습니다.
이때 다음과 같은 경로로 접근이 필요할 수 있습니다.
http://도메인/.well-known/acme-challenge/...
즉 외부 인증 서버가 제 도메인의 80번 포트를 통해 NAS까지 접근할 수 있어야 인증서 갱신이 정상적으로 진행될 수 있습니다.
Let’s Encrypt 인증서 갱신 과정에서 도메인 유효성 검사를 할 수 없다는 알림이 표시되었습니다. 이 메시지를 통해 80번 포트 접근 여부를 다시 확인하게 되었습니다.
이 알림을 보고 단순한 인증서 갱신 실패가 아니라, 외부에서 NAS까지 인증 확인 요청이 도달하지 못하는 문제일 수 있다고 판단했습니다.
기존처럼 80번 포트를 막아두면 보안상 깔끔해 보일 수는 있지만, Let’s Encrypt 자동 갱신에는 문제가 생길 수 있다는 점을 이번에 확인하게 되었습니다.
그래서 80번 포트를 다시 개방했습니다.
다만 이것은 블로그를 HTTP로 운영하기 위해서가 아닙니다.
실제 블로그 접속은 여전히 HTTPS를 기준으로 유지하고, 80번 포트는 인증서 갱신과 HTTPS 리디렉션을 위한 통로로 사용하는 방향이 더 현실적이라고 느꼈습니다.
80번 포트를 열어둔 뒤 확인한 것
80번 포트를 다시 개방한 뒤에는 HTTP 접속이 그대로 열려 있는지 확인하는 것이 아니라, HTTPS로 정상 이동하는지를 확인했습니다.
터미널에서 다음 명령으로 확인할 수 있습니다.
curl -I http://도메인
정상이라면 응답에 301 또는 302 리디렉션이 표시되고, Location 값이 HTTPS 주소로 나와야 합니다.
예시는 다음과 같습니다.
HTTP/1.1 301 Moved Permanently
Location: https://도메인/
실제로 확인해보니 HTTP 접속은 HTTPS 주소로 정상 리디렉션되었습니다.
이 상태라면 80번 포트는 열려 있지만, 일반 방문자는 최종적으로 HTTPS 블로그로 이동하게 됩니다.
DSM 재로그인 후 인증서 갱신 성공
인증서 갱신을 시도하는 과정에서 DSM에서 다시 로그인하라는 메시지가 표시되었습니다.
DSM에서 로그아웃한 뒤 다시 로그인하고 인증서 상태를 확인하니, 블로그 도메인 인증서가 새 날짜로 갱신되어 있었습니다.
인증서 만료일이 새로 표시되었고, 상태도 정상으로 바뀌었습니다.
인증서 갱신 후 블로그 도메인 인증서가 정상 상태로 바뀌고, 새 만료일이 표시되었습니다.
이 화면을 확인한 뒤 Cloudflare SSL/TLS 설정을 다시 Full(strict)로 되돌렸습니다.
처음에는 만료된 인증서 때문에 Cloudflare가 원본 서버를 신뢰하지 못했지만, 인증서가 정상적으로 갱신된 뒤에는 Full(strict) 모드에서도 블로그 접속이 정상화되었습니다.
이번 일을 겪고 나니 Let’s Encrypt 인증서 자동 갱신을 완전히 믿고 방치하기보다는, DSM에서 인증서 만료일을 가끔 확인하는 습관이 필요하다고 느꼈습니다.
Cloudflare SSL 설정을 다시 Full(strict)로 복구
인증서 갱신이 완료된 뒤에는 Cloudflare SSL/TLS 설정을 다시 Full(strict)로 되돌렸습니다.
Full은 임시 복구용으로 사용할 수 있지만, 장기적으로는 Full(strict)가 더 안전한 설정이라고 생각합니다.
최종적으로는 다음 상태를 목표로 했습니다.
- Cloudflare SSL/TLS 설정은 Full(strict) 유지
- 원본 서버 인증서 정상 갱신
- 블로그 HTTPS 접속 정상
- WordPress 관리자 접속 정상
- HTTP 접속 시 HTTPS로 리디렉션
이렇게 정리한 뒤 실제 접속 상태를 하나씩 확인했습니다.
HTTP 접속이 HTTPS로 이동하는지 확인
인증서 갱신 후에는 HTTP 접속이 HTTPS로 정상 이동하는지도 확인했습니다.
터미널에서 다음 명령으로 확인할 수 있습니다.
curl -I http://도메인
정상이라면 응답에 301 또는 302 리디렉션이 표시되고, Location 값이 HTTPS 주소로 나와야 합니다.
예시는 다음과 같습니다.
HTTP/1.1 301 Moved Permanently
Location: https://도메인/
실제로 확인해보니 HTTP 접속은 HTTPS 주소로 정상 리디렉션되었습니다.
이 단계에서 일반 블로그 접속은 정상화된 상태였습니다.
wp-admin 경로에서 발견한 추가 문제
일반 블로그 접속이 정상화된 뒤에는 WordPress 관리자 페이지도 확인했습니다.
이때 한 가지 추가 문제가 보였습니다.
슬래시가 없는 관리자 주소로 접근했을 때 응답 헤더의 Location 값이 HTTP 주소로 나오는 현상이 있었습니다.
예를 들면 이런 흐름입니다.
https://도메인/wp-admin
그런데 서버 응답은 다음처럼 HTTP 주소를 안내했습니다.
Location: http://도메인/wp-admin/
반면 끝에 슬래시를 붙인 주소는 정상적으로 동작했습니다.
https://도메인/wp-admin
이 주소는 WordPress 로그인 페이지로 정상 이동했습니다.
즉 WordPress 자체는 HTTPS를 어느 정도 인식하고 있었지만, 슬래시가 없는 /wp-admin 요청에서 내부 웹서버가 주소를 보정하는 과정에 HTTP 주소가 만들어지는 것으로 보였습니다.
왜 /wp-admin에서 HTTP 리디렉션이 생겼을까
제 블로그 구조를 단순화하면 다음과 같습니다.
외부 사용자는 HTTPS로 접속합니다.
하지만 NAS 내부에서 Reverse Proxy를 거쳐 WordPress 컨테이너로 전달될 때는 내부 HTTP 방식으로 연결될 수 있습니다.
이 구조 자체가 잘못된 것은 아닙니다. Reverse Proxy 환경에서는 흔한 구성입니다.
다만 내부 웹서버가 /wp-admin을 /wp-admin/으로 보정하는 과정에서, 외부 접속이 HTTPS였다는 정보를 충분히 반영하지 못하면 HTTP 주소가 만들어질 수 있습니다.
이 부분은 처음 보면 꽤 헷갈릴 수 있습니다.
겉으로는 HTTPS로 접속했는데, 중간 응답에서 HTTP 주소가 나타나기 때문입니다.
Synology Reverse Proxy 헤더 확인
Synology Reverse Proxy 설정에서 HTTPS 전달 정보를 확인했습니다.
프록시 환경에서는 원본 WordPress가 사용자의 실제 접속 방식이 HTTPS였다는 것을 알 수 있도록 헤더를 전달하는 것이 중요합니다.
대표적으로 다음과 같은 헤더를 사용할 수 있습니다.
- X-Forwarded-Proto: https
- X-Forwarded-Ssl: on
이 설정은 WordPress가 프록시 뒤에서 HTTPS 요청을 인식하는 데 도움이 됩니다.
실제로 /wp-admin/ 경로에서는 HTTPS 리디렉션이 정상적으로 작동했습니다.
하지만 /wp-admin처럼 슬래시가 없는 경로에서는 내부 웹서버의 경로 보정 리디렉션이 먼저 동작하는 것으로 보여, 이 설정만으로는 완전히 정리되지 않았습니다.
Cloudflare Redirect Rule로 wp-admin 경로 정리
최종적으로 Cloudflare Redirect Rule을 추가해 관리자 경로를 정리했습니다.
규칙의 핵심은 간단합니다.
https://도메인/wp-admin
→ https://도메인/wp-admin/
즉 슬래시가 없는 /wp-admin 요청이 NAS까지 전달되기 전에, Cloudflare에서 먼저 /wp-admin/ 형태로 정리해주는 방식입니다.
이렇게 하면 내부 웹서버가 HTTP 주소로 보정 리디렉션을 만들 기회가 줄어듭니다.
적용 후 다시 확인해보니 다음 흐름으로 정상 정리되었습니다.
https://도메인/wp-admin
→ https://도메인/wp-admin/ → WordPress 로그인 페이지
이제 관리자 접속 경로도 HTTPS 흐름으로 깔끔하게 정리되었습니다.
이번 문제를 통해 알게 된 점
이번 문제는 단순히 인증서 하나가 만료된 것처럼 보였지만, 실제로는 여러 설정이 함께 연결되어 있었습니다.
이번 일을 통해 알게 된 점을 정리하면 다음과 같습니다.
1. Cloudflare Full(strict)는 원본 서버 인증서를 엄격하게 확인한다
Cloudflare SSL/TLS 설정을 Full(strict)로 사용하면 Cloudflare는 원본 서버의 인증서까지 확인합니다.
이 설정은 보안 측면에서는 좋은 방식이지만, 원본 서버 인증서가 만료되면 사이트 접속 자체가 막힐 수 있습니다.
2. 원본 인증서가 만료되면 526 오류가 발생할 수 있다
Cloudflare 526 Invalid SSL Certificate 오류는 원본 서버의 SSL 인증서와 관련된 문제일 가능성이 큽니다.
방문자 브라우저와 Cloudflare 사이의 문제가 아니라, Cloudflare와 원본 서버 사이의 인증서 검증 문제일 수 있다는 점을 먼저 생각해야 합니다.
3. Let’s Encrypt 자동 갱신에는 80번 포트가 필요할 수 있다
Synology DSM에서 Let’s Encrypt 인증서를 일반 방식으로 갱신할 때는 외부에서 HTTP 경로로 도메인 소유 확인을 해야 하는 경우가 있습니다.
따라서 80번 포트를 완전히 막아두면 인증서 자동 갱신에 문제가 생길 수 있습니다.
4. 80번 포트를 열어도 HTTP로 운영한다는 뜻은 아니다
80번 포트를 열어둔다고 해서 블로그를 HTTP로 운영한다는 의미는 아닙니다.
HTTP 요청은 HTTPS로 리디렉션하고, 80번 포트는 인증서 갱신과 리디렉션을 위한 통로로 사용할 수 있습니다.
이번 경험을 통해 “80번 포트 차단 = 항상 더 안전함”으로 단순하게 생각하기보다, 운영 구조에 맞게 필요한 역할을 이해하는 것이 중요하다고 느꼈습니다.
5. WordPress 관리자 경로는 /wp-admin/ 형태가 더 안정적이었다
/wp-admin처럼 끝에 슬래시가 없는 주소에서는 내부 웹서버가 /wp-admin/으로 보정하는 과정에서 예상하지 못한 리디렉션이 생길 수 있습니다.
제 환경에서는 /wp-admin/처럼 슬래시가 붙은 형태가 더 깔끔하게 동작했습니다.
6. Reverse Proxy 환경에서는 HTTPS 전달 헤더가 중요하다
Cloudflare와 Reverse Proxy를 함께 사용하면 외부에서는 HTTPS로 접속하더라도 내부 서비스에는 HTTP로 전달될 수 있습니다.
이때 WordPress가 외부 접속이 HTTPS였다는 것을 알 수 있도록 적절한 헤더 설정이 필요할 수 있습니다.
7. 특정 경로 문제는 Cloudflare Redirect Rule로 정리할 수 있다
모든 문제를 NAS 내부에서만 해결하려고 하면 복잡해질 수 있습니다.
특정 경로에서만 문제가 생기는 경우에는 Cloudflare Redirect Rule을 활용해 앞단에서 요청을 정리하는 것도 하나의 방법이 될 수 있습니다.
앞으로의 운영 방향
이번 일을 겪고 나서 블로그 운영 방향도 조금 정리했습니다.
1. Cloudflare SSL/TLS 설정은 Full(strict)를 유지
임시 복구를 위해 Full로 변경할 수는 있지만, 인증서 문제가 해결된 뒤에는 Full(strict)로 되돌리는 것이 더 안전하다고 생각합니다.
앞으로도 기본 운영은 Full(strict)를 유지할 계획입니다.
2. 80번 포트는 다시 열어두기로 결정
기존에는 보안 강화를 위해 80번 포트를 막아두었지만, Let’s Encrypt 인증서 자동 갱신에는 80번 포트 접근이 필요할 수 있다는 점을 확인했습니다.
다만 80번 포트를 블로그의 일반 HTTP 접속 용도로 사용하는 것은 아닙니다.
HTTP로 들어온 요청은 HTTPS로 리디렉션하고, 80번 포트는 인증서 갱신과 HTTPS 리디렉션을 위한 통로로 유지하는 방향이 더 현실적이라고 판단했습니다.
3. 원본 서버 인증서 만료일 주기적 확인
Let’s Encrypt 인증서는 일정 기간마다 갱신되기 때문에, DSM에서 인증서 만료일을 가끔 확인하는 습관이 필요하다고 느꼈습니다.
자동 갱신을 믿고 완전히 방치하기보다는, 블로그 운영자가 주기적으로 한 번씩 확인하는 것이 안전하다고 생각합니다.
4. WordPress 관리자 주소는 /wp-admin/ 형태로 사용
관리자 페이지는 가능하면 다음 형태로 접속하는 것이 좋습니다.
https://도메인/wp-admin
끝에 슬래시가 붙은 형태가 WordPress 관리자 경로에서는 더 깔끔하게 동작했습니다.
비슷한 문제가 생겼을 때 확인할 체크리스트
나중에 같은 문제가 생기면 다음 순서로 확인하면 좋을 것 같습니다.
1. Cloudflare 오류 코드 확인
Cloudflare 오류 화면에 표시되는 코드가 중요합니다.
이번처럼 526 오류라면 원본 서버 SSL 인증서 문제를 먼저 의심해볼 수 있습니다.
2. DSM 인증서 만료일 확인
Synology DSM에서 인증서 상태를 확인합니다.
경로는 다음과 같습니다.
제어판 → 보안 → 인증서
여기서 블로그 도메인에 연결된 인증서가 만료되었는지 확인합니다.
3. Cloudflare SSL 모드 확인
Cloudflare SSL/TLS 설정이 Full(strict)라면 원본 인증서가 정상이어야 합니다.
긴급하게 사이트 접속을 확인해야 하는 경우에는 Full로 잠시 변경해볼 수 있지만, 문제 해결 후에는 다시 Full(strict)로 복구하는 것이 좋습니다.
4. 80번 포트 접근 가능 여부 확인
Let’s Encrypt 인증서 갱신이 실패한다면 80번 포트 접근이 막혀 있지 않은지 확인해야 합니다.
다만 공개 글에서는 실제 내부 IP, 포트포워딩 대상, 방화벽 상세 규칙 같은 민감한 정보는 그대로 적지 않는 것이 좋습니다.
5. HTTP에서 HTTPS 리디렉션 확인
터미널에서 다음과 같이 확인할 수 있습니다.
curl -I http://도메인
응답의 Location 값이 HTTPS 주소로 나오는지 확인합니다.
6. WordPress 관리자 경로 확인
관리자 페이지는 다음 형태로 접속하는 것이 좋습니다.
https://도메인/wp-admin
만약 /wp-admin 요청에서 HTTP 주소로 리디렉션된다면 Reverse Proxy 헤더나 Cloudflare Redirect Rule을 함께 확인해볼 수 있습니다.
마무리
이번 문제는 처음에는 WordPress 접속 장애처럼 보였지만, 실제 원인은 Synology NAS에 적용된 Let’s Encrypt 인증서 만료였습니다.
그리고 그 뒤에는 보안 강화를 위해 막아두었던 80번 포트와 인증서 자동 갱신 문제가 함께 연결되어 있었습니다.
Cloudflare Full(strict) 환경에서는 원본 서버 인증서 상태가 매우 중요합니다.
인증서가 만료되면 Cloudflare가 원본 서버를 신뢰하지 못하고 526 오류를 표시할 수 있습니다.
이번 경험을 통해 NAS에서 WordPress를 직접 운영할 때는 WordPress 설정만 볼 것이 아니라 Cloudflare, 인증서, 80번 포트, Reverse Proxy, HTTPS 리디렉션까지 함께 봐야 한다는 것을 다시 느꼈습니다.
개인 서버 운영은 웹호스팅보다 손이 더 가는 부분이 있습니다.
하지만 이런 문제를 하나씩 해결하다 보면, 내 블로그가 어떤 구조로 동작하는지 조금씩 더 잘 이해하게 되는 장점도 있는 것 같습니다.
Cloudflare 526 오류는 정말 골치 아프죠. 특히 Reverse Proxy 설정이 헷갈려서요.