워드프레스 Cloudflare 연결: DNS·HTTPS·캐시 점검 순서
Cloudflare를 워드프레스 앞에 연결할 때는 DNS, 원본 서버의 HTTPS, 캐시 범위를 따로 확인해야 합니다. CDN 연결만으로 모든 페이지가 캐시되거나 속도와 검색 순위가 일정하게 개선되는 것은 아닙니다. 이 글은 연결 전 준비와 적용 후 점검 순서를 설명하며, 특정 사이트의 성능 개선 실험 결과를 제시하는 글은 아닙니다.
목차
현재 DNS와 복원 방법부터 기록하세요
도메인 관리 계정, 기존 네임서버, 웹사이트의 A·AAAA·CNAME 레코드와 메일 관련 MX·TXT 레코드를 기록합니다. Cloudflare가 찾아낸 레코드 목록이 완전하다고 가정하지 말고 기존 설정과 대조하세요. 사이트 파일·DB 백업과 DNS 설정 기록은 서로 다른 복구 자료입니다.
전체 네임서버를 Cloudflare로 바꾸는 일반적인 연결 방식이라면 계정에 사이트를 추가한 후 안내받은 네임서버를 도메인 등록기관에 적용합니다. DNSSEC를 사용하는 경우에도 기존 설정과 전환 절차를 확인하세요. 연결 완료 표시는 대시보드와 실제 DNS 응답으로 확인하며, 문제가 생겼다고 무조건 하루를 기다리지는 않습니다.
웹 트래픽과 메일 레코드를 구분합니다
프록시를 사용할 웹 레코드가 원본 서버를 정확히 가리키는지 확인합니다. 메일 등 다른 서비스에 필요한 레코드를 웹사이트 설정과 함께 일괄 변경하지 마세요. 루트 도메인과 www의 기존 연결 및 대표 주소도 기록합니다. 실제 연결 절차는 Cloudflare 사이트 추가 안내를 기준으로 확인하세요.
Full (strict)에는 원본 인증서가 필요합니다
Cloudflare를 프록시로 사용하면 방문자와 Cloudflare 사이, Cloudflare와 원본 서버 사이를 나누어 봐야 합니다. Full (strict)는 원본의 인증서도 검증합니다. 원본은 HTTPS를 제공하고, 만료되지 않았으며 호스트 이름이 맞는 신뢰 가능한 인증서를 제시해야 합니다. Cloudflare Origin CA 인증서를 사용할 때는 브라우저의 직접 접속 신뢰와 구분하세요.
원본에 HTTPS가 없는데 Full을 선택하면 된다는 설명은 잘못입니다. 원본의 HTTPS와 인증서를 먼저 준비하세요. Flexible 모드와 원본의 HTTPS 강제 이동이 충돌하면 리디렉션 반복이 생길 수 있습니다. 설정 이름만 바꾸기보다 각 연결 구간과 이동 규칙을 확인합니다. Full (strict) 조건과 리디렉션 반복 점검을 참고하세요.
기본 캐시와 추가 규칙을 구분하세요
Cloudflare는 기본적으로 HTML과 JSON을 캐시하지 않습니다. 이미지·CSS·JS 등도 파일 확장자와 응답 헤더, 캐시 규칙에 따라 동작이 달라집니다. HTML 캐시를 추가하려면 로그인 사용자, 관리자, 장바구니, 문의 처리처럼 사용자별 결과가 나오는 경로와 쿠키를 별도로 검토해야 합니다.
공개 글을 수정한 뒤 예전 화면이 보이면 브라우저·워드프레스·CDN 중 어느 캐시인지 확인하세요. 가능한 경우 해당 URL을 무효화하고 다시 요청합니다. 정해진 날짜마다 모든 캐시를 비우거나 캐시 비율을 무조건 80% 이상으로 맞출 필요는 없습니다. 기본 캐시 동작과 캐시 시작 안내에 조건이 정리되어 있습니다.
관리자 접속 문제 때문에 보안 규칙 전체를 건너뛰지 마세요
로그인이나 저장이 차단되면 발생 시간과 요청 URL, 응답 코드, 보안 이벤트에서 일치하는 차단 기록을 확인합니다. 원인이 특정 규칙으로 좁혀졌을 때 필요한 경로와 조건만 조정하고 다시 시험하세요. 관리자 경로 전체에 모든 보안 규칙을 건너뛰도록 설정하는 방법은 일반적인 해결책으로 권하지 않습니다.
화면이 깨지면 실패한 CSS·JS 요청, 혼합 콘텐츠와 최근 추가한 최적화 설정을 확인합니다. 한 번에 여러 플러그인과 보안 기능을 끄면 원인을 구분하기 어려워집니다. HSTS도 원본과 하위 도메인의 HTTPS 및 복구 계획을 확인한 뒤 별도 판단할 설정입니다.
연결 후 직접 확인할 항목
- 내 도메인의 공개 페이지와 정적 파일 응답을 확인합니다. 다른 회사 도메인의 진단 URL을 열어 내 사이트의 연결 여부를 판단하지 않습니다.
- 루트와 www, HTTP와 HTTPS가 의도한 대표 주소로 이동하는지 확인합니다.
- 로그인·로그아웃 상태에서 홈, 글, 문의폼과 사용하는 도구를 시험합니다.
- 글을 수정한 뒤 공개 화면이 갱신되는지, 다른 사용자의 화면이 섞여 나오지 않는지 확인합니다.
- 같은 URL·기기·네트워크 조건에서 전후 성능을 여러 번 측정합니다. 점수 상승 폭이나 수익 증가를 미리 정해두지 않습니다.
문제가 생겼을 때 프록시를 끄는 것만으로 모든 변경이 복원되지는 않습니다. 원본의 접근 정책과 인증서에 따라 직접 접속이 실패할 수도 있습니다. 바꾼 항목과 되돌릴 순서를 기록하세요. 워드프레스 운영 가이드에서 백업·테스트·복원 흐름을, 방문 측정 가이드에서 변경 이후 지표 해석을 확인할 수 있습니다.