잘 보이던 홈페이지가 어느 날 열리지 않았다. 오라클 클라우드에 HestiaCP를 설치하고 워드프레스를 운영하고 있었는데, 브라우저에는 페이지가 작동하지 않는다는 안내만 나왔다. 이런 때는 서버가 꺼졌나 싶고, 괜히 플러그인부터 건드리게 된다.
이번에는 AI의 도움을 받아 접속 상태부터 확인했다. 결과부터 말하면 서버가 멈춘 게 아니었다. HTTPS로 들어온 방문자를 다시 같은 HTTPS 주소로 보내는 일이 반복되고 있었다. 이 글은 2026년 11월 9일 내 사이트에서 확인한 복구 기록이다.
오류 이름부터 확인했다
브라우저에 나온 오류는 ERR_TOO_MANY_REDIRECTS였다. 주소 이동이 너무 많이 반복돼 더는 진행하지 못한다는 뜻이다. 사이트가 오래 로딩되는 것과는 증상이 달랐다. 요청을 보내면 응답은 오는데, 본문 대신 다른 주소로 가라는 응답을 계속 받았다.
실제 확인에서도 https://storytus.com/으로 접속하면 바로 그 주소로 301 이동을 반복했다. 주소 끝에 붙는 슬래시 하나의 문제가 아니라, 같은 목적지로 되돌아오는 고리였다. 관리자 패널은 접속됐고 원본 서버도 HTTPS 요청에 응답했다. 적어도 이때는 서버 전원을 켜거나 워드프레스를 다시 설치할 상황이 아니었다.
Cloudflare와 서버가 서로 다른 방식으로 연결돼 있었다
내 도메인은 Cloudflare를 거쳐 서버로 들어간다. 여기서 브라우저와 Cloudflare 사이의 연결, Cloudflare와 원본 서버 사이의 연결을 나눠 봐야 했다. 방문자가 HTTPS 주소로 들어왔다고 해서 뒤쪽 연결까지 무조건 HTTPS인 것은 아니다.
확인 당시 Cloudflare의 SSL/TLS 모드는 Flexible이었다. 이 모드에서는 방문자와 Cloudflare 사이는 HTTPS여도 Cloudflare가 원본 서버에는 HTTP로 요청할 수 있다. 그런데 HestiaCP에서는 HTTP 방문자를 HTTPS로 보내는 자동 이동이 켜져 있었다.
- 방문자가 HTTPS 주소로 접속한다.
- Cloudflare는 Flexible 설정에 따라 원본 서버에 HTTP로 요청한다.
- 서버는 HTTPS로 다시 접속하라는 응답을 보낸다.
- 방문자는 같은 HTTPS 주소로 돌아오고, 뒤쪽에서는 같은 일이 반복된다.
Cloudflare 공식 문서에서도 Flexible과 원본 서버의 HTTPS 강제 이동이 충돌하면 이런 반복이 생길 수 있다고 설명한다. 내 사이트는 설정과 실제 응답이 그 설명에 맞아떨어졌다.
바꾼 것은 SSL 모드 하나였다
먼저 HestiaCP에 표시된 인증서와 원본 서버의 HTTPS 응답을 확인했다. 인증서는 만료 전이었고 HTTPS 연결도 가능한 상태였다. 이 조건을 확인한 뒤 Cloudflare의 도메인 설정에서 SSL/TLS 모드를 Flexible에서 Full (Strict)로 바꿨다. 기존 무료 플랜에서 처리했고, 유료 플랜으로 전환하거나 새 인증서를 구매하지 않았다.
Full (Strict)는 원본 서버와도 HTTPS로 연결하면서 인증서의 유효성을 확인하는 방식이다. 따라서 아무 사이트에서나 이 항목만 바꾸면 해결된다는 뜻은 아니다. 원본 인증서가 만료됐거나 도메인이 맞지 않으면 먼저 그 문제를 고쳐야 한다.
홈페이지가 뜨는지만 보고 끝내지 않았다
변경 뒤에는 홈페이지와 워드프레스 로그인 페이지가 모두 200 응답을 반환하는지 확인했다. www 주소로 들어와도 정상 주소에 도착하는지 살폈다. 브라우저에는 예전에 받은 주소 이동 정보가 남아 있어, 새 응답을 받아오는 과정도 필요했다.
- 설정 전후의 SSL 모드를 기록한다.
- 홈페이지와 로그인 페이지를 각각 확인한다.
- www 유무에 따른 주소 이동도 확인한다.
- 같은 오류가 남으면 새로고침뿐 아니라 새 세션에서도 비교한다.
- 문제가 계속되면 Cloudflare 규칙과 워드프레스의 주소 설정도 따로 살핀다.
쿠키를 전부 지우는 일부터 시작할 필요는 없다. 다른 사이트 로그인까지 풀릴 수 있다. 브라우저 쪽 정리가 필요하다면 해당 사이트의 데이터부터 범위를 좁히는 편이 낫다.
접속 복구와 보안 점검은 별개였다
접속 오류를 고친 뒤 방문자에게 가짜 사람 인증 화면이 나온다는 제보도 받았다. 이 문제는 SSL 모드가 아니라 별도로 연결돼 있던 Worker의 외부 스크립트 주입 경로에서 확인했다. 해당 사이트의 Worker 연결은 끊었다. 인증 화면에서 Windows 실행 창에 명령을 붙여넣으라고 한다면 따라 하지 말아야 한다.
이번에 배운 점은 홈페이지가 안 열린다는 한마디 안에도 서로 다른 문제가 섞일 수 있다는 것이다. 나는 먼저 오류 이름과 실제 응답을 확인하는 쪽이 덜 돌아가는 길이었다. 플러그인 삭제나 재설치는 그다음에 판단해도 늦지 않았다.
