Cloudflare WAF 설정을 하려고 보면 어떤 규칙부터 만들어야 하는지 막막할 수 있는데요. 저는 무료 플랜에서 워드프레스 로그인 주소 /wp-login.php에는 속도 제한을 걸고, .env·.git·wp-config.php 같은 민감 경로 탐색은 사용자 지정 규칙으로 차단했습니다.
설정만 하고 끝낸 것도 아닙니다. 실제 테스트 주소로 접속해 Cloudflare 차단 화면이 뜨는지 보고, 보안 이벤트에 제가 만든 규칙과 요청 경로까지 기록되는 것도 직접 확인했습니다.
처음에는 저도 ‘무료 플랜에서 이걸 어디까지 할 수 있지? 괜히 건드렸다가 제 로그인까지 막히는 것 아닌가?’ 싶었는데요.
막상 하나씩 해보니 중요한 건 기능을 많이 켜는 것이 아니라, 워드프레스에서 실제로 공격받기 쉬운 곳만 좁게 잡고 짧게 차단한 뒤 제대로 작동하는지 확인하는 것이었습니다.
혹시 Cloudflare 기본 DDos 보호 상태부터 아직 확인하지 않으셨다면 워드프레스 디도스 공격 대비 Cloudflare 무료 기본 보안 설정부터 먼저 확인해 보셔요. DNS 프록시·SSL/TLS·기본 보호 상태를 확인한 뒤 이어오시면 이번 설정이 훨씬 이해하기 쉽습니다.
지금 Cloudflare를 열 수 있다면 대상 도메인 → 보안 → 보안 규칙까지만 먼저 들어가 보셔요. 기존 규칙이 있는지부터 확인하고 시작하면 됩니다.

Cloudflare 무료 플랜에서 제가 사용한 규칙은 2가지입니다
제가 실제로 추가한 것은 두 가지였습니다.
- 속도 제한 규칙 — /wp-login.php 반복 요청 제한
- 사용자 지정 WAF 규칙 — .env·.git·wp-config.php 계열 탐색 차단
현재 Cloudflare 공식 기준으로 Free 플랜에서는 속도 제한 규칙 1개를 사용할 수 있고, 요청을 세는 기간과 차단 기간은 각각 10초입니다. Cloudflare Rate Limiting Rules 공식 안내에서도 현재 플랜별 조건을 확인할 수 있습니다. 사용자 지정 규칙은 5개까지 사용할 수 있습니다.
무료라고 아무것도 못 하는 수준은 아니더라고요. 다만 슬롯이 많지는 않으니 아무 규칙이나 채우기보다 실제 워드프레스에서 의미 있는 곳에 쓰는 게 좋을거 같습니다.
1. /wp-login.php 로그인 공격에 속도 제한 걸기
먼저 보안 → 보안 규칙 → 속도 제한 규칙으로 들어갔습니다.
워드프레스 로그인 주소인 /wp-login.php는 실제 사용자가 로그인할 때도 쓰는 정상 주소입니다. 그래서 아예 막는 것이 아니라, 같은 IP에서 짧은 시간에 반복 요청이 들어올 때만 잠깐 차단하는 방식으로 잡았습니다.
제가 적용한 값은 아래와 같습니다.
- 규칙 이름: WordPress 로그인 보호
- URI 경로: /wp-login.php
- 조건: 같음
- 동일한 특징: IP
- 요청: 5회
- 측정 기간: 10초
- 동작: 차단
- 차단 기간: 10초


여기서 5회 / 10초는 Cloudflare가 모든 워드프레스에 권장하는 고정값이 아닙니다. 제 사이트에서 너무 강하게 막지 않으면서 먼저 시험해 보기 위해 제가 선택한 시작값입니다.
사이트에 여러 사람이 같은 공인 IP를 공유하거나 로그인 요청이 많은 환경이라면 기준은 달라질 수 있습니다.
그리고 Rate Limiting은 ‘정확히 6번째 요청부터 무조건 막힌다’는 식으로 이해하면 안 됩니다. Cloudflare 공식 안내에도 카운터 반영에 약간의 지연이 있을 수 있다고 되어 있습니다.
즉, 정밀하게 요청 숫자를 끊는 기능이라기보다 반복적인 과다 요청을 줄이는 보호 장치로 생각하시면 이해하기 쉽습니다.

저는 배포한 뒤 평소처럼 워드프레스 관리자 화면이 정상적으로 열리는지도 확인했습니다. 보안 설정을 했다고 내 정상 사용까지 막히면 곤란하니까요.
여기까지 설정했다면 바로 다음 규칙으로 넘어가기보다 평소 로그인부터 한 번 확인해 보셔요. 정상이라면 첫 번째 보호는 끝입니다.
이제 로그인 페이지와는 다른 종류의 요청을 보겠습니다. 일반 방문자가 찾아갈 이유가 거의 없는 민감 파일 탐색입니다.
2. .env·.git·wp-config.php 민감 파일 탐색 차단
이번에는 보안 → 보안 규칙 → 사용자 지정 규칙으로 들어갔습니다.
로그인 페이지는 정상 사용자가 이용하는 주소라 속도를 제한했지만, .env나 .git 같은 경로는 성격이 다릅니다.
일반 방문자가 제 워드프레스에서 이런 파일을 직접 찾아볼 이유는 거의 없기 때문에 저는 일치하는 요청을 바로 차단하도록 만들었습니다.
규칙 이름은 민감 파일 탐색 차단으로 정했습니다.
제가 실제로 사용한 식은 아래와 같습니다.
(
http.request.uri.path eq "/.env" or
starts_with(http.request.uri.path, "/.env.") or
http.request.uri.path eq "/.git" or
starts_with(http.request.uri.path, "/.git/") or
http.request.uri.path eq "/wp-config.php" or
starts_with(http.request.uri.path, "/wp-config.php.")
)뜻은 어렵지 않습니다.
- /.env 및 /.env.로 시작하는 변형
- /.git 및 /.git/ 아래 경로
- /wp-config.php 및 wp-config.php.로 이어지는 백업 파일 형태
이 요청이 들어오면 Cloudflare 앞단에서 차단하도록 만든 것입니다.

Cloudflare의 Rules 언어는 starts_with() 함수를 지원합니다. 그래서 /.git/config처럼 특정 경로 아래를 찾는 요청이나 .env.local 같은 변형도 한 규칙에서 함께 잡을 수 있습니다.
Free 플랜에서는 Custom Rule을 현재 5개까지 만들 수 있지만, 그렇다고 다섯 개를 억지로 채울 필요는 없습니다. 저는 이 세 종류의 민감 경로를 한 규칙에 묶어 사용했습니다.

설정만 하지 않고 실제 차단되는지도 확인했습니다
보안 규칙은 ‘활성’이라고 적혀 있다고 끝이 아니라고 생각했습니다.
진짜 요청을 잡는지 한 번은 확인해야죠.
그렇다고 실제 /.env 파일을 직접 열어보는 건 조금 찜찜했습니다. 만약 파일이 정말 존재하고 규칙에 문제가 있다면 민감한 내용을 볼 수도 있으니까요.
그래서 실제 파일이 아닐 가능성이 높은 가짜 테스트 주소를 사용했습니다.
/.env.cloudflare-test-20260823우리가 만든 규칙은 /.env.로 시작하는 요청을 잡기 때문에 이 테스트 주소도 차단 대상이 됩니다.
접속해 보니 Cloudflare의 차단 페이지가 바로 나타났습니다.

여기서 한 번 더 확인했습니다.
브라우저에서 차단됐다고 보여주는 것뿐 아니라 Cloudflare가 어떤 규칙으로 무엇을 막았는지 기록도 남았는지 말이죠.
보안 이벤트에서 규칙 이름과 요청 경로까지 확인
Cloudflare의 보안 → Analytics → 이벤트로 들어갔습니다.
Security Events는 Cloudflare의 보안 기능이 차단하거나 조치한 요청을 확인하는 곳입니다.
제가 방금 테스트한 이벤트를 펼쳐보니 다음 내용을 확인할 수 있었습니다.
- 서비스: 사용자 지정 규칙
- 수행한 작업: 차단
- 규칙: 민감 파일 탐색 차단
- 경로: /.env.cloudflare-test-20260823

이제야 ‘규칙을 만들었다’가 아니라 ‘제가 만든 규칙이 실제 요청을 잡았다’고 말할 수 있었습니다.
개인적으로는 이 과정이 가장 중요했습니다. 설정값을 많이 넣어두는 것보다 하나라도 실제로 작동하는지 확인하는 게 마음도 훨씬 편하더라고요.
xmlrpc.php까지 무조건 막지는 않았습니다
워드프레스 보안 글을 찾아보면 xmlrpc.php도 자주 나오는데요.
저는 이번에는 무조건 막지 않았습니다.
Jetpack이나 외부 WordPress 앱처럼 XML-RPC를 정상적으로 사용하는 기능이 있을 수 있기 때문입니다. 저는 Jetpack을 사용하지 않지만, 그렇다고 모든 사이트에 ‘그냥 차단하세요’라고 쓰는 건 조금 다른 이야기라고 봤습니다.
필요하지 않은 기능인지 먼저 확인하고, 실제 공격성 요청이 반복된다면 그때 별도로 제한해도 늦지 않다고 생각합니다.
보안이라고 무조건 많이 막는 것보다 내 사이트가 쓰는 기능과 안 쓰는 기능을 구분하는 것도 중요한 듯합니다.
Cloudflare WAF 설정, 저는 이 정도부터 시작했습니다
이번에 제가 실제로 적용하고 확인한 것은 아래 두 가지였습니다.
- /wp-login.php 반복 요청 → Rate Limiting
- .env·.git·wp-config.php 탐색 → Custom WAF Rule 차단
그리고 두 규칙 모두 저장됐다는 표시만 보지 않고 정상 관리자 접속과 실제 차단 이벤트까지 확인했습니다.
Cloudflare 무료 플랜을 사용하고 계신다면 규칙을 이것저것 만들기 전에 로그인 보호 하나, 명확한 민감 경로 차단 하나부터 시작해 보셔요. 그리고 바로 실제 사이트가 정상인지, 이벤트는 기록되는지까지 같이 확인하는 걸 권하고 싶습니다.
다음으로 제가 더 확인하고 싶은 것은 Cloudflare를 거치지 않고 원본 서버 IP로 직접 들어갈 수 있는 길이 열려 있는지입니다.
그건 Cloudflare 대시보드 설정만의 문제가 아니라 호스팅 서버 방화벽과도 연결될 수 있어서, 이번 글에 억지로 넣지 않고 별도로 확인해 보려고 합니다.
Cloudflare WAF 설정에서 자주 묻는 질문
Cloudflare 무료 플랜에서도 워드프레스 로그인 공격을 제한할 수 있나요?
네. 현재 Free 플랜은 Rate Limiting Rule 1개를 제공하며 Path와 IP 기준으로 요청 속도를 제한할 수 있습니다. Free 플랜의 측정 기간과 완화 기간은 각각 10초입니다.
wp-login.php는 5회 10초로 설정하면 되나요?
5회 10초는 제가 실제 사이트에서 먼저 시험하기 위해 선택한 값입니다. Cloudflare가 모든 워드프레스 사이트에 권장하는 고정값은 아니므로 정상 로그인 패턴과 사이트 환경을 보고 조절하는 게 좋습니다.
Cloudflare 무료 플랜에서 사용자 지정 WAF 규칙은 몇 개까지 만들 수 있나요?
2026년 9월 확인 기준으로 Free 플랜의 Custom Rules는 최대 5개입니다. 개수를 채우기보다 실제 사이트에 필요한 규칙만 사용하는 편이 좋습니다.
만든 WAF 규칙이 실제로 작동하는지 어디서 확인하나요?
브라우저의 차단 화면뿐 아니라 Cloudflare Security Events에서 조치, 규칙 이름, 요청 경로와 관련 이벤트를 확인할 수 있습니다.
Cloudflare WAF 설정이라고 하면 처음에는 꽤 어렵게 느껴졌는데요.
저도 메뉴 위치를 하나씩 찾아가며 만들었고, 중간에는 무료 플랜이라 선택할 수 없는 옵션도 있었습니다.
그래도 내 사이트에서 실제로 필요한 범위를 좁혀 하나씩 설정하고 확인하니 생각보다 따라갈 만했습니다.
혹시 저처럼 Cloudflare를 쓰고는 있지만 WAF 규칙은 한 번도 건드려보지 않으셨다면요. 무작정 많이 막으려고 하기보다 로그인 보호 하나부터 천천히 확인해 보셔요.
※ Cloudflare의 Free 플랜 제한과 WAF·Rate Limiting·Security Events 기능은 2026년 9월 1일 공식 문서를 다시 확인해 작성했습니다. 플랜과 대시보드 UI는 이후 변경될 수 있습니다.
댓글 남기기