Cloudflare Precursor Monitor 설정: API의 Challenge 영향을 따로 확인하기

Monitor가 멈추는 것은 무엇인가요?

Cloudflare는 2026년 10월 19일 Monitor 모드 추가를 발표했습니다. 고객이 bot score를 바꾸지 않고 Precursor를 시험할 수 있도록 한 변경이며, 별도 미래 시행일은 제시하지 않았습니다. 상태 선택과 Interstitial 표시를 분리했다는 점이 이번 설정의 핵심입니다. 근거: Monitor 모드 추가 공지

Status	Precursor 동작	읽을 때 주의할 점
Off	Precursor 실행 안 함	사이트의 다른 보안 기능까지 꺼지는 것은 아님
Monitor	신호를 수집하지만 그 신호로 bot score·Challenge clearance를 변경하지 않음	별도로 표시되는 Interstitial 확인 필요
Arm	Precursor 신호가 bot score·Challenge clearance에 영향을 줄 수 있음	문서의 Armed 모드에 해당

여기서 ‘변경하지 않는다’의 주어는 Monitor에서 수집한 Precursor 신호입니다. 사이트 전체의 bot score가 항상 같거나 다른 규칙의 Challenge까지 없어지는 것으로 확대해석하면 안 됩니다. 모드의 정의는 Precursor 공식 가이드에서 확인할 수 있습니다.

Challenge clearance는 방문자가 Challenge 검증을 통과한 상태와 관련됩니다. Monitor 신호가 이 상태를 바꾸지 않는다는 설명과, 방문자가 별도 Interstitial을 통과하며 clearance를 받는 것은 구분해야 합니다. 근거: clearance의 의미와 Monitor·Armed 차이

대상 zone과 현재 설정부터 기록하세요

문서상 경로는 대상 zone의 Security → Settings입니다. Bot traffic 또는 Precursor로 찾아 Status를 확인하고, 설정 아이콘에서 Show Interstitial과 Interstitial Rules를 검토합니다. Off 상태에서는 이 Interstitial 설정을 사용할 수 없다고 안내합니다. 근거: 설정 시작 절차

이 글에서는 실제 계정 메뉴와 플랜별 제공 범위를 확인하지 않았습니다. 항목이 보이지 않으면 자신의 zone·관리 권한·계약상 제공 여부를 먼저 확인하세요. 모든 플랜에 같은 메뉴가 제공된다고 가정하지 않습니다.

설정하기 전에 다음 네 항목을 한 묶음으로 남기면 문제 발생 시 되돌릴 대상을 찾기 쉽습니다.

• zone과 요청 호스트: 웹 페이지와 API가 같은 zone·호스트를 쓰는지
• 현재 Status: Off·Monitor·Arm 중 무엇인지
• Show Interstitial 기본값과 요청별 규칙: 조건·동작·활성 상태
• 변경 전 요청 결과: 브라우저·서버 간 API의 상태 코드와 응답 유형

이미 API 오류가 발생 중이라면 먼저 현재 조합을 보존하세요. 여러 보안 설정을 한 번에 바꾸면 어떤 변경이 응답에 영향을 줬는지 분리하기 어렵습니다.

Show Interstitial과 경로별 규칙의 두 가지 패턴

공식 문서는 브라우저·API 혼합 서비스에 아래 두 방식을 제시합니다. 둘 다 Monitor와 Arm에서 사용할 수 있는 Interstitial 설정 패턴입니다. API 경로에서 해당 표시를 끄는 것을 WAF·인증·접근 제어 전체 해제로 바꾸어 적용하지 마세요. 근거: API와 함께 사용하는 방법

패턴	Show Interstitial 기본값	Interstitial Rules의 역할	확인할 요청
필요한 브라우저 경로에만 표시	Off	예: /checkout에 표시 요구	선택한 브라우저 경로와 일반 페이지·API가 의도대로 구분되는지
기본 표시 후 API를 분리	On	API 호스트 또는 경로에서 표시 끄기	실제 API URL이 예외 조건에 들어가는지

두 패턴 중 하나를 선택한 뒤 대상 요청을 좁혀 시험하세요. 기본값이 Off여도 개별 규칙이 표시를 요구할 수 있습니다. 반대로 기본값이 On이면 API 예외가 빠진 요청을 놓치기 쉽습니다.

예를 들어 API를 /api/ 아래에서 운영한다면 다음 주소를 구분해 점검할 수 있습니다. 이는 경계 확인용 예시 목록이며 Cloudflare 규칙 표현식이나 실제 적용 결과가 아닙니다.

• /api/health: 의도한 API 하위 경로에 해당하는지
• /api: 끝의 슬래시가 없는 경로도 API라면 조건에 포함되는지
• /apiculture: API가 아닌 유사 접두사까지 예외에 들어가지 않는지
• api.example.com/health: 별도 호스트를 쓰는 API도 포함되는지

호스트·경로 조건을 문장으로 먼저 적고 계정의 실제 규칙과 대조하면, ‘API 예외를 만들었다’는 기억과 실제 일치 범위 사이의 차이를 찾는 데 도움이 됩니다.

브라우저와 API를 같은 성공 기준으로 보지 마세요

새 브라우저 세션, 검증을 마친 세션, 서버 간 요청은 서로 다른 조건입니다. 아래 표는 테스트 설계용이며 측정값이 아닙니다. 변경 전·후에 같은 URL과 메서드를 사용하고, 쿠키 전달 여부를 함께 기록하세요.

시험 요청	유지할 조건	확인할 결과
새 세션의 브라우저 페이지	확장 기능·브라우저·진입 URL	Interstitial 표시와 목적 페이지 도달 여부
검증 후 같은 브라우저의 API 호출	세션과 쿠키 전달 조건	예상 응답 형식·필수 데이터·앱 처리 결과
쿠키를 보내지 않는 브라우저 API 호출	실제 요청에서 쿠키가 빠졌는지 확인	동일 API에서 응답 유형이 달라지는지
curl·서버 간 작업 등 비브라우저 API	호스트·경로·메서드·앱 인증 조건	상태 코드·Content-Type·Challenge 응답 여부

브라우저에서 잘 보인다는 이유만으로 서버 간 호출도 통과한다고 판단하지 마세요. 반대로 쿠키 없는 요청이 실패했다면 그 요청이 실제 운영 클라이언트의 조건을 대표하는지도 확인해야 합니다.

기존 브라우저 세션의 쿠키를 서버 작업에 복사하는 방식으로 시험 조건을 맞추지는 마세요. cf_clearance는 발급받은 방문자·기기에 결합되므로 다른 머신에서 재사용하는 인증 수단으로 취급할 수 없습니다. 근거: clearance 쿠키의 결합 조건

API가 HTML을 받았다면 Challenge 헤더를 확인하세요

Cloudflare Challenge Page 응답에는 cf-mitigated: challenge가 붙고 Content-Type은 text/html입니다. JSON을 기대하는 API가 이런 응답을 받으면 JSON 파싱 오류가 먼저 보일 수 있습니다. 상태 코드 하나만으로 Challenge 여부를 판정하지 않는 것이 좋습니다. 근거: Challenge Page 응답 식별 문서

다음 명령은 Bash 또는 zsh에서 쓸 수 있는 확인 예시입니다. api.example.com/health는 자리표시자이므로, 자신이 관리하고 GET 호출을 시험할 수 있는 무해한 URL로 바꾸세요. 응답 본문은 버리고 선택한 헤더만 출력합니다. 5초·15초 제한은 예시의 연결·전체 대기 상한입니다.

set -o pipefail
curl -q --silent --show-error --connect-timeout 5 --max-time 15 \
  --dump-header - --output /dev/null \
  'https://api.example.com/health' |
awk '/^HTTP\// || tolower($1) == "content-type:" ||
     tolower($1) == "cf-mitigated:" || tolower($1) == "cf-ray:" {
  sub(/\r$/, ""); print
}'

-q는 기본 curl 설정 파일을 읽지 않도록 한 선택입니다. 명령에는 쿠키·앱 인증 정보를 추가하지 않았으며 리다이렉트도 자동으로 따라가지 않습니다. 최초 응답이 리다이렉트라면 실제 도착 URL의 설정을 따로 확인하세요. 헤더 출력·본문 처리·시간 제한은 curl 공식 매뉴얼을 기준으로 구성했습니다.

이 명령의 종료 코드가 0이어도 API 업무 처리가 성공했다는 뜻은 아닙니다. HTTP 상태·예상 응답 형식을 따로 확인하고, 실제 앱에서는 필수 데이터와 처리 결과까지 검증하세요. 이 글에서는 명령의 문법을 점검했으며 실제 Cloudflare zone에 요청한 출력은 제시하지 않습니다.

cf-mitigated: challenge는 Challenge를 식별하는 표식이지 Precursor만의 원인 표식은 아닙니다. WAF·Bot Management·Rate limiting도 Challenge를 유발할 수 있으므로 일치한 규칙과 현재 Precursor 설정을 함께 대조해야 합니다. 근거: Challenge를 발생시키는 기능과 API 호환성

관찰 결과에 따라 다음 확인을 나누세요

관찰한 상태	다음 확인
Monitor인데 API에 Challenge 응답	Show Interstitial 기본값·요청별 규칙과 실제 일치 요청 확인
API 예외를 넣었지만 일부 URL만 계속 Challenge	호스트·슬래시 경계·별도 경로와 다른 Challenge 규칙 확인
HTML이지만 Challenge 표식이 없음	로그인 리다이렉트·원본 오류 등 다른 응답 경로 조사
일반 API 응답이지만 앱 처리가 실패	앱 인증·응답 스키마·업무 처리 결과 조사
연결 자체가 실패해 HTTP 응답이 없음	DNS·TLS·네트워크 오류를 HTTP Challenge와 분리

브라우저 API에서 쿠키를 포함하도록 바꿀 때도, 쿠키가 실제로 전달되고 유효한지 확인해야 합니다. 쿠키 전달 옵션을 켰다는 사실만으로 검증된 세션이 생기거나 서버 간 클라이언트가 브라우저가 되지는 않습니다.

문제가 생기면 모드와 표시 규칙을 함께 복원하세요

아래는 테스트 zone에서 사용할 편집부 점검 순서입니다. 실제 운영 변경이나 원복 성공을 재현한 기록은 아닙니다.

1. 변경한 Status·Show Interstitial·요청별 규칙을 변경 전 기록과 대조합니다.
2. 문제와 연결된 변경을 복원하고, 다른 담당자가 같은 시간에 바꾼 설정이 있는지 확인합니다.
3. 동일한 브라우저·API 조건으로 다시 요청해 상태 코드·응답 유형·도달 여부를 비교합니다.
4. 이미 검증된 세션과 새 세션을 구분해 재확인하고, 성공·실패·미확인을 각각 기록합니다.

Monitor로 돌아가는 작업만으로 Show Interstitial이나 경로별 규칙도 원래대로 돌아간다고 생각하면 안 됩니다. API 호출만 복구됐더라도 민감한 브라우저 경로의 검증이 의도대로 유지되는지 함께 확인하세요.

브라우저·API 비교 및 설정 복원 기록 양식 다운로드. 쿠키·토큰 원문과 실제 사용자 본문 대신 요청 시각·경로·규칙·응답 유형을 기록하는 빈 양식입니다. 운영 기록을 외부로 내보낼 때는 Cloudflare Logpush IP 마스킹 안내를 참고할 수 있습니다. 로그 전송 전 가공과 HTTP Challenge 설정은 별도 작업입니다.

자주 묻는 질문

Monitor면 방문자에게 Challenge가 전혀 나오지 않나요?

아닙니다. Monitor는 Precursor 탐지 신호의 bot score·Challenge clearance 변경을 멈춥니다. Show Interstitial·요청별 규칙과 다른 보안 기능에서 발생하는 Challenge는 별도로 확인해야 합니다.

브라우저 페이지와 API 경로의 설정을 다르게 할 수 있나요?

Interstitial Rules로 사이트 기본 표시 동작을 요청별로 조정할 수 있습니다. 필요한 브라우저 경로만 표시하거나 기본 표시를 켠 뒤 API 호스트·경로에서 끄는 패턴을 검토하고, 실제 URL의 일치 범위를 확인하세요.

Monitor와 Arm은 bot score에 어떤 차이를 만드나요?

Monitor의 Precursor 신호는 bot score와 Challenge clearance를 바꾸지 않습니다. Arm에서는 영향을 줄 수 있습니다. 다른 신호와 정책까지 고정되는 것은 아니므로 모드 전환 하나로 전체 점수 변화를 단정하지 마세요.

확인 범위와 업데이트 기록

2026년 10월 21일 Monitor 발표·Precursor 설정·Challenge 응답 식별·clearance·curl 공식 자료를 대조했습니다. 실제 계정의 제공 플랜·설정 화면·브라우저 및 API 응답·복원 결과는 미검증입니다. 표와 경로 목록은 시험 설계이며 실제 성공·실패 로그가 아닙니다.

모드 동작·Interstitial 규칙·제공 조건이 바뀌거나 테스트 zone의 검증 기록을 확보하면 갱신합니다. 10월 19일은 Monitor 모드 추가 발표일로 구분하며 Precursor 자체의 최초 출시일로 사용하지 않습니다.