Cloudflare 워드프레스 설정｜SSL·캐시·원복 30분 점검

Cloudflare를 워드프레스에 연결했다고 바로 HTML까지 빨라지는 것은 아닙니다. 기본 CDN은 이미지·CSS·JavaScript 같은 정적 파일을 주로 캐시하며, HTML과 JSON은 기본적으로 캐시하지 않습니다. 따라서 네임서버 변경, SSL 확인, 캐시 상태 측정 순서로 적용해야 속도 효과와 오류 원인을 구분할 수 있습니다.

이 글은 기존 사이트를 중단하지 않고 Cloudflare를 연결한 뒤 CF-Cache-Status로 결과를 확인하고 문제가 생겼을 때 되돌리는 순서입니다. 쇼핑몰이나 회원 사이트는 개인화 페이지가 있으므로 HTML 전체 캐시를 처음부터 켜지 않는 것이 안전합니다.

10초 요약

• 기존 DNS 레코드와 원본 서버 IP를 먼저 저장합니다.
• 웹사이트 레코드만 프록시하고 메일·인증 레코드는 임의로 바꾸지 않습니다.
• 원본 인증서가 유효하면 SSL/TLS를 Full (strict)로 설정합니다.
• 기본 상태에서는 정적 파일 캐시부터 확인합니다.
• HTML 캐시는 관리자·로그인·장바구니·회원 쿠키를 제외한 뒤 적용합니다.
• 오류가 나면 새 기능을 한 가지씩 끄고 캐시를 해당 URL만 삭제합니다.

적용 전에 남길 기록

Cloudflare가 검색한 DNS 결과를 그대로 확정하지 말고 호스팅 관리 화면의 실제 값과 비교하세요. 메일용 MX와 인증용 TXT는 빠지면 메일 수신이나 도메인 인증이 실패할 수 있습니다. TTL이 긴 레코드는 변경 전 값을 따로 저장해 두면 복구가 쉬워집니다.

1단계: 도메인 연결과 프록시 범위 정하기

1. Cloudflare에 도메인을 추가하고 검색된 DNS를 원본과 대조합니다.
2. 루트 도메인과 www 등 웹 트래픽 레코드를 프록시 대상으로 정합니다.
3. 도메인 등록기관에서 안내된 Cloudflare 네임서버로 교체합니다.
4. 활성화 후 홈페이지와 관리자 화면, 메일 송수신을 각각 확인합니다.

주황색 구름은 해당 호스트의 HTTP·HTTPS 요청이 Cloudflare를 통과한다는 뜻입니다. 메일 서버나 외부 서비스 검증 레코드를 무조건 프록시하면 안 됩니다. 원본 방화벽이 Cloudflare IP만 허용하는 구조라면 DNS 전용으로 되돌리기 전에 직접 접속 가능 여부도 점검하세요.

2단계: SSL/TLS는 원본 인증서부터 확인

Cloudflare 공식 문서는 가능한 경우 Full (strict)를 권장합니다. 이 모드는 방문자와 Cloudflare 구간뿐 아니라 Cloudflare와 원본 서버 사이도 암호화하고, 원본 인증서의 만료일·발급자·호스트명 일치를 확인합니다. 원본 서버의 443 포트와 인증서가 준비되지 않은 상태에서 바꾸면 526 오류가 발생할 수 있습니다.

Flexible은 원본까지 HTTP로 연결하므로 워드프레스와 서버가 HTTPS 리디렉션을 수행할 때 반복 이동이 생길 수 있습니다. 설정 후 시크릿 창에서 HTTP 주소가 HTTPS로 한 번만 이동하는지, 이미지와 스크립트에 혼합 콘텐츠 경고가 없는지 확인하세요.

3단계: 기본 캐시부터 측정

처음에는 HTML 전체 캐시 규칙을 만들지 말고 이미지나 CSS 주소를 두 번 요청해 응답 헤더를 비교합니다. 같은 엣지 위치에서 첫 요청은 MISS, 이후 요청은 HIT가 될 수 있습니다. Age는 캐시에 저장된 시간을 보여줍니다.

curl -I https://example.com/wp-content/uploads/sample.webp

Cloudflare는 DNS 전용 레코드와 다른 도메인에서 불러오는 광고·분석 스크립트를 캐시하지 않습니다. 사이트 전체 점수만 보지 말고 개발자 도구의 Network에서 내 도메인의 정적 파일이 실제로 HIT가 되는지 확인하세요. 이미지 용량 자체가 크다면 워드프레스 이미지 최적화 순서도 먼저 적용합니다.

4단계: HTML 캐시는 제외 조건부터 설계

HTML 페이지를 캐시하면 원본 부하는 줄지만 로그인 사용자나 장바구니 정보가 다른 방문자에게 보이는 사고가 생길 수 있습니다. Cache Rules에서 캐시 허용 규칙보다 다음 우회 조건을 먼저 만들고 규칙 순서를 확인하세요.

• /wp-admin/과 /wp-login.php
• 미리보기·검색·REST·관리 AJAX처럼 매번 달라지는 요청
• 워드프레스 로그인 쿠키가 있는 요청
• WooCommerce 장바구니·결제·내 계정 경로와 관련 쿠키
• 회원 등급이나 지역에 따라 내용이 달라지는 페이지

페이지 캐시 플러그인과 Cloudflare HTML 캐시를 동시에 켜면 오래된 화면의 위치를 찾기 어려워집니다. 캐시 플러그인 중복 방지 점검에 따라 한 계층씩 적용하고, 로그인·로그아웃 상태를 별도 브라우저에서 비교하세요.

글 수정 후 캐시 갱신과 원복

Cloudflare WordPress 플러그인의 Automatic Cache Management는 글·페이지·첨부파일·댓글 변경과 테마 변경 때 관련 URL을 자동 삭제합니다. 수동 삭제가 필요하면 전체 삭제보다 변경한 URL만 지우는 방식을 우선하세요. 전체 삭제는 많은 요청을 동시에 원본으로 돌려 일시적인 부하를 만들 수 있습니다.

1. 문제가 시작된 시각과 직전에 켠 기능을 기록합니다.
2. Rocket Loader, HTML 캐시 규칙 등 마지막 변경 하나를 끕니다.
3. 문제가 난 URL만 캐시에서 삭제합니다.
4. 로그인·글 저장·모바일 메뉴를 다시 검사합니다.
5. 계속 실패하면 프록시를 우회하기 전에 원본 직접 접속과 방화벽을 확인합니다.
6. DNS 변경은 전파 시간이 있으므로 최후의 복구 단계로 사용합니다.

Cloudflare 적용 뒤 TTFB가 줄지 않는다면 HTML이 DYNAMIC인 기본 상태인지 먼저 확인하세요. 원본 생성 시간이 느리면 CDN만으로 해결되지 않으므로 워드프레스 TTFB 20분 진단으로 PHP·DB·외부 API를 나눠 점검합니다.

TIP

속도 점수보다 캐시 적중과 원본 요청 감소를 먼저 기록하세요. 같은 정적 파일을 동일 조건에서 두 번 요청해 MISS → HIT 변화와 Age를 확인하면 CDN이 실제로 동작하는지 점수 변동과 분리해서 판단할 수 있습니다.

자주 묻는 질문

Cloudflare를 연결하면 HTML도 자동 캐시되나요?

기본 CDN은 HTML과 JSON을 캐시하지 않습니다. Cache Rules나 APO처럼 HTML을 캐시하는 별도 기능이 필요하며, 로그인 쿠키와 개인화 경로를 제외해야 합니다.

수정한 이미지가 예전 상태로 보이면 어떻게 하나요?

브라우저·워드프레스 캐시·Cloudflare 캐시 중 어느 계층인지 확인한 뒤 해당 파일 URL만 삭제하세요. 같은 파일명 대신 새 파일명이나 버전 문자열을 사용하면 오래된 캐시 충돌을 줄일 수 있습니다.

공식 자료

• Cloudflare 캐시 시작 안내
• CF-Cache-Status 응답 설명
• Full (strict) SSL/TLS 조건
• WordPress 자동 캐시 관리

마무리

Cloudflare 워드프레스 설정은 네임서버 교체보다 검증 순서가 중요합니다. DNS와 원본 인증서를 보관하고 정적 파일 캐시부터 확인한 뒤, HTML 캐시는 제외 경로와 쿠키를 설계해 적용하세요. 변경을 한 번에 하나씩 진행하고 URL 단위로 캐시를 갱신하면 속도 개선과 기능 오류를 함께 관리할 수 있습니다.