Cloudflare 속도 제한 설정 가이드: 5분 만에 CC 공격 방어, 무료 플랜도 가능

새벽 3시. 서버 모니터링 알림에 잠에서 깼습니다. CPU 사용률은 100%까지 치솟았고, 웹사이트는 완전히 열리지 않았습니다. 로그를 확인해 보니 수십 개 IP가 인터페이스를 미친 듯이 호출하고 있었습니다. 초당 수백 개 요청이 쏟아지는, 전형적인 CC 공격이었습니다.

급하게 IP를 차단했지만 곧바로 새 IP가 들어왔습니다. 하나씩 막는 방식으로는 도저히 감당할 수 없었습니다. 두 시간쯤 허둥대고 나서야 Cloudflare에 방어 기능이 있을 거라는 생각이 났습니다. 대시보드를 열어 Rate Limiting을 보니, 무료 플랜에서도 쓸 수 있었습니다. 규칙 하나를 만들어 단일 IP가 1분에 최대 20개 요청만 보내도록 제한하고, 초과하면 10분 동안 차단했습니다. 5분 만에 설정을 끝냈고 공격 트래픽은 밖에서 막혔습니다.

CC 공격 방어는 생각만큼 복잡하지 않습니다. 핵심은 속도 제한 규칙을 미리 설정해 두는 것입니다. 이 글에서는 Cloudflare 속도 제한 기능을 어떻게 쓰는지, 무료 플랜에서는 어디까지 가능한지, 임계값은 얼마로 잡아야 하는지, 상황별 설정은 어떻게 다른지, 그리고 자주 빠지는 함정은 무엇인지 정리합니다.

CC 공격이란 무엇이고, 속도 제한은 왜 이를 막을 수 있나

먼저 CC 공격이 무엇인지부터 짚어보겠습니다. CC는 Challenge Collapsar의 약자로, 쉽게 말해 정상 사용자처럼 보이는 대량 방문을 흉내 내 웹사이트에 몰아붙이고 서버 자원을 소진시키는 공격입니다.
이게 그냥 DDoS 아닌가 싶을 수 있습니다. 하지만 실제로는 꽤 다릅니다. 전통적인 DDoS 공격은 비교적 거칠고, 대량의 쓰레기 패킷을 직접 보내기 때문에 특징이 뚜렷합니다. Cloudflare의 자동 DDoS 방어로 대부분 막을 수 있습니다. 반면 CC 공격은 더 교묘합니다. 정상적인 HTTP 요청을 보내 실제 사람이 방문하는 것처럼 보이기 때문에 전통적인 DDoS 방어가 식별하지 못할 수 있습니다.
예를 들어 정상 사용자가 사이트를 방문하면 1분에 몇 페이지를 클릭하고 5-10개 요청을 보내는 정도입니다. 그런데 CC 공격에서는 단일 IP가 30초 안에 1000개가 넘는 요청을 보낼 수 있습니다. 명백히 비정상입니다. 게다가 공격자는 여러 대의 장비나 프록시 IP를 함께 사용해 공격하기 때문에 트래픽이 매우 분산되고, 그래서 더 막기 어렵습니다.
속도 제한은 바로 이 특징을 겨냥해 설계된 기능입니다. 원리는 단순합니다. 각 IP, 세션, API 키 등의 요청 빈도를 모니터링하다가 설정한 임계값을 넘으면 조치를 취합니다. CAPTCHA를 띄워 실제 사람인지 증명하게 할 수도 있고, 일정 시간 직접 차단할 수도 있습니다.
제가 겪었던 공격을 예로 들면, 공격자의 IP는 초당 200-300개의 요청을 보냈고, 제가 설정한 임계값은 분당 20개였습니다. 그러면 공격 트래픽은 1-2초 안에 제한을 트리거하고 이후 요청은 모두 밖에서 차단됩니다. 정상 사용자는 이 제한을 전혀 트리거하지 않으므로 사용자 경험에도 영향이 없습니다.
흥미로운 데이터도 있습니다. Alibaba Cloud WAF의 모범 사례 문서에는 전형적인 CC 공격에서 단일 좀비 머신이 30초 안에 1000회 이상의 요청을 보낼 수 있고, 정상 사용자는 보통 분당 10회를 넘지 않는다고 나옵니다.

이 차이는 꽤 큽니다.
여기까지 들으면 한 가지 걱정이 생길 수 있습니다. 정상 사용자가 빠르게 조작하면 어떻게 할까요? 예를 들어 API 엔드포인트에서 데이터를 빠르게 새로고침한다면요. 이 문제는 실제로 존재합니다. 그래서 임계값 설정이 중요합니다. 뒤에서 상황별로 얼마를 설정하면 좋은지 자세히 이야기하겠습니다.

무료 플랜도 가능하다! Cloudflare 속도 제한 기능 전체 해설

이 부분은 꼭 강조하고 싶습니다. 많은 사람, 예전의 저를 포함해 많은 사람이 속도 제한을 유료 기능이라고 생각합니다. 하지만 2022년 10월부터 Cloudflare는 속도 제한을 모든 사용자에게 무료로 개방했습니다. Free, Pro, Business 플랜이 모두 포함됩니다.
이전에는 어땠을까요? 2022년 전에는 속도 제한 기능을 사용하려면 트래픽 기준으로 비용을 내야 했고, 요청 100만 건당 5달러가 부과되었습니다. 트래픽이 큰 사이트라면 이 비용은 꽤 부담스러웠습니다. 저도 그 이유로 오랫동안 켜지 못했습니다.
하지만 지금은 전혀 걱정하지 않아도 됩니다. Cloudflare는 공식 블로그에서 속도 제한 규칙이 모든 플랜에 포함되며 추가 요금이 없다고 명확히 발표했습니다. 무료 플랜 사용자는 속도 제한 규칙을 1개 만들 수 있고, Pro와 Business 사용자는 더 많은 규칙을 만들 수 있습니다.
규칙이 1개뿐이면 충분할까요? 솔직히 말하면 중소형 사이트에는 규칙 1개로도 정말 충분한 경우가 많습니다. 핵심은 이 규칙을 가장 공격받기 쉬운 곳에 쓰는 것입니다. 보통 로그인 엔드포인트, 회원가입 엔드포인트, 핵심 API 엔드포인트입니다.
제 작은 프로젝트들도 모두 규칙 1개만 설정해 로그인 엔드포인트를 보호하고 있습니다. 거의 1년 가까이 운영했지만 기본적으로 큰 문제는 없었습니다. 가끔 작은 규모의 스캔 공격이 들어와도 대부분 차단되었습니다.
물론 비즈니스가 복잡하고 보호할 엔드포인트가 여러 개라면 Pro나 Business 플랜 업그레이드가 필요할 수 있습니다. Pro 플랜은 월 20달러로 규칙 10개를 만들 수 있고, Business 플랜은 월 200달러로 규칙 15개를 만들 수 있습니다. 그래도 개인 사이트와 중소기업에는 무료 플랜의 규칙 1개만으로도 대부분의 문제를 해결하는 경우가 많습니다.
또 하나 기억할 점이 있습니다. 무료 플랜의 속도 제한 규칙은 1개뿐이지만, Cloudflare의 기본 DDoS 방어는 모든 플랜에 포함되며 트래픽 제한도 없습니다. 그래서 명확한 DDoS 공격은 자동으로 차단됩니다. 속도 제한은 더 은밀한 CC 공격과 인터페이스 남용을 겨냥하는 기능입니다.
무료 플랜 vs 유료 플랜의 주요 차이:

• 규칙 수: Free 1개, Pro 10개, Business 15개
• 고급 특성: 유료 플랜은 Bot Score, JA3 지문 같은 더 복잡한 매칭 조건을 사용할 수 있습니다
• 응답 시간: 유료 플랜은 고트래픽 상황에서 더 빠르게 반응합니다
  속도 제한을 처음 접하는 분이라면 먼저 무료 플랜으로 시험해 보는 것을 권합니다. 가장 중요한 엔드포인트를 보호하는 규칙 하나를 설정하고, 한동안 효과를 지켜보세요. 정말 더 많은 규칙이 필요하다는 판단이 서면 그때 업그레이드해도 늦지 않습니다.

임계값은 어떻게 정할까? 상황별 설정 추천

이 문제는 저도 처음에 꽤 골치가 아팠습니다. 처음 설정할 때 ‘Requests per period’ 입력칸을 보며 10으로 할지 100으로 할지 고민했습니다. 너무 낮게 잡으면 정상 사용자를 막을까 걱정되고, 너무 높게 잡으면 공격을 못 막을까 걱정되었습니다.
이후 Cloudflare 공식 문서와 여러 대형 서비스의 모범 사례를 찾아보고, 제 실제 테스트까지 더해 상황별 추천 임계값을 정리했습니다. 다만 아래 값은 참고값입니다. 반드시 본인 사이트의 실제 트래픽 특성에 맞춰 조정해야 합니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

로그인/회원가입 엔드포인트(가장 공격받기 쉬움)

로그인 엔드포인트는 집중 공격 지점입니다. 무차별 대입과 크리덴셜 스터핑에 자주 사용됩니다. 이런 엔드포인트는 정상 사용자의 접근 빈도는 낮지만, 공격이 시작되면 트래픽이 크게 늘어난다는 특징이 있습니다.
추천 설정(3단계 점진식):
Cloudflare 공식 권장은 3단계 규칙입니다. 공격은 막으면서 정상 사용자를 덜 오탐할 수 있습니다.

• 1단계: 분당 요청 4회 → JavaScript 챌린지 트리거
• 2단계: 10분당 요청 10회 → CAPTCHA 트리거
• 3단계: 시간당 요청 20회 → 1일 직접 차단
  하지만 무료 플랜에는 규칙이 1개뿐이므로 단순화해야 합니다. 제가 쓰는 설정은 다음과 같습니다.
• 단일 규칙 설정: 60초당 요청 20회 → 10분 차단
  이 임계값은 어떻게 정했을까요? 제 사이트 로그를 살펴보니 정상 사용자가 로그인할 때 비밀번호를 틀려 재시도해도 보통 1분에 5회를 넘지 않았습니다. 공격 스크립트는 거의 항상 1분에 수백, 수천 번을 시도합니다. 그래서 20회/분이라는 임계값은 대부분의 공격을 막으면서도 정상 사용자를 오탐하지 않습니다.
  사이트의 보안 요구가 특히 높다면 더 엄격하게 둘 수 있습니다.
• 엄격 모드: 60초당 요청 10회 → 1시간 차단

API 엔드포인트(비즈니스 특성에 맞게 조정)

API 엔드포인트는 상황이 더 복잡합니다. API 유형에 따라 접근 빈도가 크게 달라집니다.
일반 조회 API:

• 추천 설정: 10초당 요청 30회 → JavaScript 챌린지
  이 임계값은 초당 3개 요청에 해당하며, 대부분의 정상 프론트엔드 애플리케이션에는 충분합니다. 사용자가 빠르게 새로고침하더라도 바로 차단되지는 않습니다.
  계산 집약 API(이미지 처리, 데이터 분석 등):
• 추천 설정: 60초당 요청 10회 → 제한
  이런 API는 서버 자원을 많이 소비하므로 임계값을 낮게 잡아야 합니다. 분당 10회는 정상 사용에는 충분하지만, 악의적 호출로 자원을 고갈시키는 일을 효과적으로 막을 수 있습니다.
  공개 API(외부에 제공하는 서비스):
• 추천 설정: API 과금 모델과 리소스 감당 능력에 맞춰 결정
  무료 API를 제공한다면 시간당 100회로 설정할 수 있습니다. 유료 API라면 요금제 등급에 따라 서로 다른 제한을 둘 수 있습니다.
  Google Cloud Armor에는 참고할 만한 사례가 있습니다. API에 20분당 요청 2000회를 설정하고, 초과 시 트래픽의 20%를 제한하라고 권장합니다. 이런 점진식 제한 방식도 참고할 만합니다.

일반 웹페이지(콘텐츠 크롤링 방지)

일반 웹페이지의 접근 빈도는 API보다 낮지만, 악의적인 콘텐츠 크롤링은 여전히 막아야 합니다.
추천 설정:

• 일반 페이지: 30초당 요청 100회 → JavaScript 챌린지
• 특수 페이지(검색, 다운로드 등): 60초당 요청 50회 → CAPTCHA
  왜 일반 페이지의 임계값을 이렇게 높게 잡을까요? 정상 사용자가 웹페이지를 볼 때 여러 링크를 빠르게 클릭할 수 있고, CSS, JS, 이미지 같은 리소스까지 더하면 한 페이지에서 십여 개의 요청이 생길 수 있기 때문입니다. 그래서 30초 100회는 정상 탐색에서는 잘 트리거되지 않습니다.
  하지만 크롤러에게 30초 100회는 여전히 너무 빠른 속도입니다. 쉽게 걸러낼 수 있습니다.
  특히 주의: 홈페이지에는 너무 엄격한 제한을 걸지 마세요. 저는 예전에 홈페이지에 강한 속도 제한을 걸었다가 Google과 Bing 크롤러까지 막아 SEO 순위가 바로 떨어진 적이 있습니다. 이후 급히 홈페이지 규칙을 삭제하고 나서야 회복되었습니다.

실제 사례 참고

Alibaba Cloud WAF의 모범 사례 문서에는 중소형 사이트를 위한 예방 설정 예시가 있습니다.

• 단일 IP가 30초 안에 1000회 넘게 접근하면 → 10시간 차단
  이 설정은 비교적 느슨해서 최후 방어선으로 쓰기 좋습니다. 얼마로 잡아야 할지 확신이 없다면 이것을 출발점으로 삼고 실제 로그에 따라 조정할 수 있습니다.
  또 하나의 팁이 있습니다. 규칙을 설정한 뒤 처음부터 ‘Block’ 액션을 쓰지 말고, 먼저 ‘Managed Challenge’를 사용해 보세요. 임계값이 조금 낮더라도 실제 사용자는 CAPTCHA를 통과해 계속 접근할 수 있어 완전히 막히지 않습니다. 한동안 운영해 오탐이 없다고 확인되면 그때 ‘Block’으로 바꾸면 됩니다.

5분 설정 튜토리얼(단계별)

이론을 충분히 이야기했으니 이제 실전으로 들어가겠습니다. 속도 제한 규칙을 어떻게 설정하는지 단계별로 보여드리겠습니다. 정말 간단하고 5분이면 끝납니다.

1단계: Rate Limiting 규칙 페이지로 이동

Cloudflare 대시보드에 로그인하고 설정할 도메인을 선택한 뒤 다음 경로로 이동합니다.
Security → WAF → Rate limiting rules
들어가면 이전에 설정한 적이 없는 경우 ‘Create rule’ 버튼이 보입니다. 무료 플랜 사용자는 여기서 ‘0/1 rules’가 표시되는데, 아직 규칙 1개를 만들 수 있다는 뜻입니다.

2단계: 기본 정보 입력

‘Create rule’을 누르면 설정 페이지가 열립니다. 먼저 맨 위 기본 정보를 입력합니다.
Rule name(규칙 이름):
‘Login-Rate-Limit’나 ‘API-Protection’처럼 의미 있는 이름을 권장합니다. 나중에 규칙이 여러 개 생기면 찾기 쉽습니다.

3단계: 매칭 조건(Expression) 설정

이 단계는 Cloudflare에 어떤 요청을 이 규칙으로 모니터링할지 알려주는 부분입니다.
로그인 엔드포인트를 보호하려면 다음처럼 설정할 수 있습니다.

Field: URI Path
Operator: equals
Value: /api/login

이는 /api/login 경로로 접근하는 요청만 모니터링한다는 뜻입니다.
전체 API를 보호하려면 contains 매칭을 사용할 수 있습니다.

Field: URI Path
Operator: contains
Value: /api/

이렇게 하면 /api/로 시작하는 모든 경로가 모니터링됩니다.
조건을 더 추가할 수도 있습니다. 예를 들어 특정 User-Agent(예: 자체 모니터링 스크립트)를 제외하고 싶다면 ‘And’를 눌러 추가 조건을 넣습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

Field: User Agent
Operator: does not equal
Value: MyMonitorBot

4단계: 속도 제한 파라미터 설정(핵심)

가장 중요한 부분입니다. 언제 제한을 트리거할지를 결정합니다.
Characteristics(카운팅 특성):
요청을 무엇으로 식별하고 카운트할지 선택합니다. 가장 자주 쓰는 옵션은 다음과 같습니다.

• IP Address: 방문자의 IP 주소 기준으로 카운트합니다(CC 공격 방어에 권장되는 첫 선택)
• Session: Cookie의 세션 ID 기준으로 카운트합니다(로그인 사용자에게 적합)
• Headers: HTTP 헤더 기준으로 카운트합니다(API Key 등 API 보호에 적합)
  로그인 엔드포인트 방어라면 IP Address를 선택하면 됩니다.
  Period(시간 창):
  드롭다운에서 10초, 30초, 60초 같은 시간 창을 선택합니다.
  저는 보통 60초, 즉 1분을 선택합니다. 시간이 너무 짧으면(예: 10초) 오탐이 쉬워지고, 너무 길면(예: 10분) 방어 효과가 떨어질 수 있습니다.
  Requests per period(요청 임계값):
  앞에서 말한 임계값입니다. 이 시간 창 안에서 허용할 요청 수를 의미합니다.
  앞의 권장값에 따르면 로그인 엔드포인트는 20, API 엔드포인트는 30으로 설정할 수 있습니다.
  Duration(차단 시간):
  제한이 트리거된 뒤 얼마나 오래 차단할지 정합니다. 선택지는 1분부터 24시간까지 다양합니다.
  저는 보통 10분을 선택합니다. 너무 짧으면 공격자가 곧바로 다시 오고, 너무 길면 정상 사용자 오탐 시 피해가 커질 수 있습니다.
  로그인 엔드포인트 보호를 위한 전체 예시는 다음과 같습니다.
• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes
  의미는 이렇습니다. IP 주소 기준으로 집계해, 같은 IP가 1분 안에 로그인 엔드포인트를 20회 넘게 호출하면 해당 IP를 10분 차단합니다.

5단계: 응답 액션(Action) 선택

제한이 트리거되면 이 요청들을 어떻게 처리할까요? 몇 가지 선택지가 있습니다.
Managed Challenge(관리형 챌린지) - 우선 권장:
Cloudflare가 자동으로 실제 사람인지 봇인지 판단합니다. 실제 사용자는 검증 페이지를 볼 수도 있고, 경우에 따라 거의 바로 통과하기도 합니다. 봇은 차단됩니다. 사용자 경험이 가장 좋고, 오탐이 생겨도 영향이 가장 작습니다.
Block(직접 차단):
403 오류를 직접 반환하고 접근을 거부합니다. 방어 효과는 가장 좋지만 오탐이 생기면 꽤 번거롭습니다. 규칙이 문제없다고 확인한 뒤 사용하는 것을 권장합니다.
Legacy CAPTCHA(전통 CAPTCHA):
CAPTCHA를 띄우고 사용자가 올바르게 입력해야 계속 접근할 수 있습니다. 경험은 보통이지만 실제 사람과 봇을 효과적으로 구분할 수 있습니다.
JS Challenge(JavaScript 챌린지):
클라이언트에 JavaScript 코드를 보내 실행하게 하고 실제 브라우저인지 확인합니다. 크롤러에는 효과적이고 정상 사용자에게는 거의 감지되지 않습니다.
처음에는 Managed Challenge를 사용하고, 한동안 운영해 문제가 없다고 확인한 뒤 Block으로 바꿔 방어 강도를 높이는 것을 권장합니다.

6단계: 저장 및 활성화

설정을 마친 뒤 페이지 하단으로 내려가 ‘Deploy’ 버튼을 누릅니다. 규칙은 대기 없이 즉시 적용됩니다.

7단계: 규칙 동작 확인

설정 후 간단히 테스트해 볼 수 있습니다. curl이나 브라우저로 빠르게 여러 번 접근해 보세요.

for i in {1..30}; do curl https://yourdomain.com/api/login; done

설정이 올바르다면 처음 20회는 정상이고, 21회부터 429 상태 코드가 오거나 챌린지 페이지가 보여야 합니다.
Cloudflare 대시보드의 Security → Events에서 차단 로그를 확인해 규칙이 실제로 작동하는지도 볼 수 있습니다.

전체 설정 예시

/api/auth/login 로그인 엔드포인트를 보호한다고 가정하면 제 전체 설정은 다음과 같습니다.
기본 정보:

• Rule name: Login-Rate-Limit
  매칭 조건:
• URI Path equals /api/auth/login
  속도 제한 파라미터:
• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes
  응답 액션:
• Action: Managed Challenge
  Deploy를 누르면 끝입니다. 전체 과정이 정말 5분이면 충분합니다.

고급 팁과 흔한 함정

속도 제한 규칙 설정은 보기에는 단순하지만, 실제로 써보면 몇 가지 함정이 있습니다. 제가 직접 겪은 함정과 고급 팁을 공유하겠습니다.

함정 1: SEO 크롤러 오탐

앞에서도 이야기했지만 정말 중요해서 다시 강조합니다.
홈페이지나 전체 사이트에 너무 엄격한 속도 제한을 절대 걸지 마세요!
예전에 한 프로젝트에서 편하게 처리하려고 전체 사이트에 규칙 하나를 걸었습니다. 30초 안에 50회 넘게 요청하면 차단하는 규칙이었습니다. 일주일 정도 운영한 뒤 Google Search Console에서 크롤링 오류가 급증했습니다. 자세히 보니 Google 크롤러가 사이트를 방문할 때 CSS, JS, 이미지 등 여러 리소스를 동시에 가져오면서 제한을 쉽게 트리거한 것이었습니다.
이후 로그인과 API 엔드포인트만 보호하고 일반 페이지에는 제한을 두지 않자 문제가 해결되었습니다.
권장:

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

• 로그인, 회원가입, API 같은 민감한 엔드포인트: 엄격하게 제한
• 일반 콘텐츠 페이지: 느슨하게 제한하거나 제한하지 않음
• 홈페이지: 가능한 한 제한하지 않음
  콘텐츠 크롤링을 꼭 막아야 한다면 Cloudflare의 Bot Management 기능(유료)을 사용할 수 있습니다. 이 기능은 Google 같은 선의의 크롤러와 악성 크롤러를 구분해 다르게 처리할 수 있습니다.

함정 2: 공격자가 속도 제한을 우회

한 지인은 속도 제한을 설정했는데도 CC 공격을 막지 못했습니다. 나중에 보니 공격자가 Cloudflare를 우회해 서버 실제 IP로 직접 공격하고 있었습니다.
왜 이런 일이 생길까요?
Cloudflare는 리버스 프록시입니다. 서버 앞에서 막아 주는 구조입니다. 하지만 공격자가 원본 서버의 실제 IP를 알면 원본 서버에 직접 접근해 Cloudflare를 우회할 수 있습니다.
해결 방법:

1. 서버 방화벽에서 Cloudflare IP만 접근 허용
   Cloudflare는 IPv4와 IPv6 IP 목록을 공식 제공하므로, 이 IP들만 80과 443 포트에 접근하도록 방화벽을 설정할 수 있습니다.
   Linux 서버에서는 다음 스크립트를 사용할 수 있습니다.

# Cloudflare IP 접근만 허용
for i in `curl https://www.cloudflare.com/ips-v4`; do
  ufw allow from $i to any port 443 proto tcp
  ufw allow from $i to any port 80 proto tcp
done

2. 원본 서버 IP를 정기적으로 교체
   원본 IP가 이미 유출되었다면 교체를 고려하세요. 동시에 DNS에 원본 IP를 직접 노출하지 않도록 주의해야 합니다.
3. Cloudflare Authenticated Origin Pulls 사용
   더 고급 방식입니다. 클라이언트가 Cloudflare 인증서를 제공해야 하므로 요청이 실제로 Cloudflare에서 온 것인지 확인할 수 있습니다.

함정 3: 모니터링과 조정을 잊음

규칙 설정은 한 번 해두면 끝나는 일이 아닙니다. 정기적으로 확인하고 조정해야 합니다.
실제로 규칙을 설정한 뒤 방치한 사례를 본 적이 있습니다. 결과는 다음과 같았습니다.

• 임계값이 너무 낮아 정상 사용자가 자주 오탐되었고, 사용자가 고객센터에 문의해도 원인을 몰랐습니다
• 비즈니스가 성장하고 방문량이 늘어 기존 임계값이 맞지 않게 되었습니다
• 공격 패턴이 바뀌었지만 규칙이 업데이트되지 않아 방어 효과가 떨어졌습니다
  권장:
  정기적으로, 예를 들어 매월 Cloudflare의 Security Analytics를 확인하세요.
• 차단된 요청 수를 확인합니다
• 정상 사용자가 제한을 트리거한 명확한 오탐이 있는지 봅니다
• 429 오류율이 비정상적인지 확인합니다
  데이터에 따라 임계값을 조정합니다.
• 429 오류가 거의 없다면 임계값을 낮춰 방어를 강화할 수 있습니다
• 429 오류가 많다면 임계값을 높이거나 규칙을 조정해야 할 수 있습니다

팁 1: 분산 공격 대응

요즘 CC 공격은 점점 더 지능적입니다. 공격자는 대량의 프록시 IP로 공격하고, 각 IP의 요청 빈도는 높지 않게 유지합니다. 그래서 단순한 IP 속도 제한으로는 막기 어렵습니다.
분산 공격에 대응하는 몇 가지 방법:

1. IP 대신 Session/Cookie 기준으로 카운트
   사이트에 세션 메커니즘이 있다면 Session ID로 카운트할 수 있습니다. 공격자가 IP를 바꾸더라도 Session ID가 같으면 그대로 차단됩니다.
   설정할 때 Characteristics는 Cookie를 선택하고 Session Cookie 이름을 지정합니다.
2. User-Agent 필터링 결합
   많은 공격 스크립트의 User-Agent는 비정상적입니다. 예를 들어 ‘Python’, ‘curl’ 같은 도구 특징이 들어 있습니다. 매칭 조건에 User-Agent 필터를 추가할 수 있습니다.
3. Bot Management 사용(유료 기능)
   가장 강력한 방식입니다. Cloudflare가 각 요청에 1-100 점수를 부여하고, 점수가 낮을수록 봇일 가능성이 큽니다. Bot Score < 30인 요청에만 속도 제한을 적용하는 규칙을 만들 수 있습니다.
   다만 이 기능은 Business 또는 Enterprise 플랜이 필요하므로 모두가 쉽게 쓰기는 어렵습니다.

팁 2: 점진식 응답 전략(유료 플랜)

앞에서 Cloudflare 공식 권장 3단계 방어를 언급했습니다. 무료 플랜은 규칙이 1개뿐이지만, 유료 플랜 사용자는 이 전략을 시도해 볼 수 있습니다.
1단계(느슨함):

• 임계값: 높게 설정(예: 30회/분)
• 액션: JS Challenge(거의 감지되지 않음)
  2단계(중간):
• 임계값: 중간(예: 50회/10분)
• 액션: Managed Challenge(검증이 필요할 수 있음)
  3단계(엄격):
• 임계값: 낮게 설정(예: 100회/시간)
• 액션: Block 24시간(차단)
  이렇게 하면 실제 사용자에게 더 많은 기회를 주면서, 집요한 공격자에게는 더 강한 제재를 적용할 수 있습니다.

팁 3: 특정 지역 대상 방어

비즈니스가 주로 중국에 있다면 해외 트래픽에 더 엄격한 제한을 둘 수 있습니다.
Expression에 지리 조건을 추가합니다.

(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")

이렇게 하면 중국 외 IP에만 엄격한 제한을 적용하고, 중국 내 사용자는 영향을 받지 않습니다.
다만 정상 사용자 중 VPN을 쓰는 사람이 있을 수 있고, 이 경우 해외 트래픽으로 분류됩니다. 그래서 직접 Block보다는 Challenge 사용을 권장합니다.

마지막으로

길게 이야기했지만 핵심은 한 문장입니다. 속도 제한 설정은 어렵지 않습니다. 중요한 것은 공격을 당한 뒤가 아니라 미리 설정해 두는 것입니다.
너무 많은 사람이 한밤중에 알림에 깨고 나서야 방어 방법을 찾기 시작합니다. 그 허둥대는 느낌은 정말 좋지 않습니다. 반대로 미리 5분만 들여 규칙을 설정해 두면 훨씬 마음이 편해집니다.
바로 실행할 수 있는 제안은 다음과 같습니다.

1. 지금 바로 규칙 하나를 설정하세요. 사이트가 아직 공격받은 적이 없더라도 괜찮습니다. 일이 터지고 나서 수습하는 것보다 미리 예방하는 편이 낫습니다.
2. 로그인 엔드포인트부터 시작하세요. 무료 규칙이 1개뿐이라면 로그인 또는 회원가입 엔드포인트에 쓰세요. 가장 공격받기 쉬운 곳이고, 가장 보호가 필요한 곳입니다.
3. 설정 후 테스트하세요. curl이나 브라우저로 빠르게 몇 번 새로고침해 규칙이 트리거되는지 확인하세요. 그런 다음 Security Events에서 차단 로그를 확인해 정상 동작하는지 보세요.
4. 정기적으로 점검하고 조정하세요. 매월 한 번 Security Analytics를 확인하도록 알림을 설정하고, 실제 상황에 맞춰 임계값을 조정하세요.
   마지막으로 다시 한 번 강조합니다. 서버 방화벽에서 Cloudflare IP만 접근하도록 허용하는 것을 절대 잊지 마세요. 그렇지 않으면 공격자가 Cloudflare를 우회해 원본 서버를 직접 때릴 수 있고, 규칙을 아무리 많이 설정해도 소용이 없습니다.
   설정 중 문제가 생기면 Cloudflare 공식 문서를 참고하거나 커뮤니티 포럼에 질문해 보세요. 대부분의 문제는 이미 누군가 겪은 적이 있고 해결책도 찾을 수 있습니다.
   이 글이 속도 제한을 순조롭게 설정하고, 웹사이트를 CC 공격에서 멀리 떨어뜨리는 데 도움이 되길 바랍니다.