Cloudflare 무료 플랜은 개인 사이트나 소규모 서비스에 실질적인 값을 준다. 문제는 대부분의 설정 가이드가 순서를 안 알려준다는 것이다. 순서를 틀리면 속도는 빨라지는데 방문자 통계가 전부 같은 IP로 찍히고, 무차별 로그인 시도를 막아주던 차단 도구가 조용히 무력화된다.
그래서 이 글은 기능 나열이 아니라 작업 순서로 간다.
무료 플랜으로 되는 것과 안 되는 것
기대치를 먼저 정직하게 잡는다.
되는 것 — 전 세계 CDN 캐시, 무료 SSL 인증서, 기본 방화벽 규칙, DDoS 완화, Brotli 압축, HTTP/3, 무제한 대역폭.
안 되는 것 — 이미지 자동 최적화(Polish), 고급 캐시 규칙 다수, 이미지 리사이징, 상세한 방화벽 규칙 수, 실시간 로그.
즉 “파일을 가깝게 배달하는 것”은 무료로 되고, “파일 자체를 가볍게 만드는 것”은 대체로 유료다. 이미지 최적화는 WebP 변환처럼 서버 쪽에서 직접 해두는 편이 낫다.
순서 1: 네임서버 연결과 프록시 켜기
Cloudflare에 도메인을 등록하면 네임서버를 변경하라고 안내한다. 도메인 등록업체에서 네임서버를 Cloudflare 것으로 바꾸면 몇 분에서 수 시간 뒤 활성화된다.
바꾸기 전에 기존 DNS 레코드가 모두 옮겨졌는지 확인한다. Cloudflare가 자동으로 가져오지만 누락되는 경우가 있다. 특히 메일 관련 레코드(MX, SPF, DKIM)가 빠지면 메일이 안 온다. 전환 전에 기존 DNS 설정을 캡처해두는 것을 권한다.
그다음이 구름 아이콘이다.
- 회색 구름 — DNS만 관리한다. Cloudflare를 거치지 않으므로 CDN도 보호도 없다.
- 주황 구름 — 트래픽이 Cloudflare를 거친다. 여기서부터 CDN과 SSL, 방화벽이 동작한다.
웹 서비스용 A/AAAA/CNAME 레코드만 주황으로 켠다. 메일 서버 레코드는 회색으로 둔다. 메일은 프록시 대상이 아니다.
순서 2: 원본 IP 복구 설정 ⚠️
이 절을 앞쪽에 둔 이유가 있다. 프록시를 켠 직후 바로 해야 하는 작업이기 때문이다.
프록시를 켜면 방문자의 요청이 Cloudflare를 거쳐 서버로 온다. 그래서 서버가 보는 접속 IP는 방문자가 아니라 Cloudflare의 IP다. 결과는 이렇다.
- 방문자 통계의 IP가 전부 같은 대역으로 찍힌다. 중복 방문자 제거가 망가진다
- fail2ban 같은 차단 도구가 무차별 시도를 한 IP로 인식한다. 심하면 Cloudflare IP를 차단해 사이트 전체가 안 열린다
- 지역별 접속 통계가 무의미해진다
진짜 IP는 CF-Connecting-IP 헤더에 담겨 온다. 웹 서버가 이 헤더를 신뢰하도록 설정하면 된다. nginx라면 이런 형태다.
# Cloudflare IP 대역에서 온 요청에 한해 CF-Connecting-IP 를 진짜 IP 로 인정
set_real_ip_from 173.245.48.0/20;
# ... Cloudflare 공식 IP 목록의 나머지 대역도 모두 추가
real_ip_header CF-Connecting-IP;
set_real_ip_from으로 대역을 제한하는 것이 중요하다. 이 제한 없이 헤더를 신뢰하면 아무나 헤더를 위조해 IP를 속일 수 있다. Cloudflare가 공식 IP 목록을 공개하므로 그것을 그대로 넣는다.
아파치는 mod_remoteip, 애플리케이션 단이라면 프레임워크의 신뢰 프록시 설정으로 같은 일을 한다.
순서 3: 캐시 규칙
기본 상태로도 이미지·CSS·JS 같은 정적 파일은 캐시된다. 여기서 두 가지를 손본다.
정적 파일 캐시 기간 늘리기 — 브라우저 캐시 TTL을 길게 잡으면 재방문자의 로딩이 빨라진다. 파일 이름에 해시가 붙는 빌드 시스템을 쓴다면 길게 잡아도 안전하다.
캐시하면 안 되는 경로 제외하기 — 이게 더 중요하다.
- 관리자 페이지 (
/wp-admin/*,/admin/*) - 로그인·인증 경로
- API 엔드포인트
- 장바구니·주문 등 사용자별로 달라지는 페이지
관리자 페이지를 캐시하면 무슨 일이 벌어지나. 관리자가 로그인한 상태의 페이지가 캐시돼 다른 사람에게 그대로 보일 수 있다. 로그인 세션이 섞이는 사고로 이어질 수 있어, 캐시 규칙을 건드릴 때 가장 먼저 확인해야 할 항목이다.
순서 4: SSL 모드와 압축
SSL 모드는 반드시 확인한다. 설정 위치는 SSL/TLS 개요다.
- Flexible — 방문자↔Cloudflare 구간만 암호화하고 Cloudflare↔서버 구간은 평문이다. 쓰지 말 것. 자물쇠는 보이는데 실제로는 절반이 노출되고, 리다이렉트 무한 루프의 흔한 원인이기도 하다.
- Full — 양쪽 다 암호화하지만 서버 인증서를 검증하지 않는다.
- Full (strict) — 양쪽 암호화 + 인증서 검증. 이게 정답이다.
서버에 유효한 인증서가 없다면 Let’s Encrypt로 발급하거나 Cloudflare가 제공하는 원본 인증서를 설치하고 Full (strict)로 맞춘다.
압축과 부가 기능은 켜두면 대체로 이득이다. Brotli 압축, HTTP/3, 그리고 “Always Use HTTPS”를 켜서 평문 접속을 자동으로 넘긴다.
설정 후 측정
체감이 아니라 숫자로 확인한다.
- 적용 전에 PageSpeed Insights나 WebPageTest로 한 번 재둔다. 이걸 안 해두면 비교 대상이 없다
- 적용 후 같은 도구, 같은 페이지, 같은 조건으로 다시 잰다
- 캐시가 데워지는 시간이 필요하므로 적용 직후가 아니라 하루 뒤에 재는 편이 정확하다
주로 볼 지표는 TTFB(첫 바이트까지 시간)와 LCP다. CDN 효과는 TTFB에서 가장 먼저 드러난다.
⚠️ 무료 플랜의 제공 범위와 설정 화면 구성은 2026년 8월 기준이며 변경될 수 있다. Cloudflare IP 대역 목록도 갱신되므로 공식 페이지에서 최신 목록을 확인할 것.
자주 묻는 질문
무료 플랜으로 충분한가요?
개인 블로그나 소규모 사이트라면 충분합니다. 대역폭 제한이 없고 CDN·SSL·기본 보호가 모두 포함됩니다. 유료가 필요해지는 시점은 이미지 자동 최적화가 필요하거나, 세밀한 캐시·방화벽 규칙을 많이 써야 하거나, 상세 로그가 필요할 때입니다.
워드프레스에도 적용되나요?
적용됩니다. 다만 캐시 제외 경로를 반드시 설정하세요. /wp-admin/, /wp-login.php, 그리고 로그인 쿠키가 있는 요청은 캐시하면 안 됩니다. 로그인 상태의 화면이 캐시돼 다른 방문자에게 보이는 사고를 막기 위해서입니다.
속도가 오히려 느려질 수도 있나요?
있습니다. 접속자가 대부분 국내에 있고 서버도 국내에 있는데 트래픽이 해외 엣지를 경유하면 오히려 지연이 늘 수 있습니다. 또 캐시가 거의 안 되는 동적 페이지 위주 사이트라면 이득이 작습니다. 적용 전후를 같은 도구로 재보고 판단하세요.
Leave a Reply