Error 1010 브라우저 시그니처 차단 (Cloudflare)

문제

페이지가 “Access denied — The owner of this website has banned your access based on your browser’s signature.” 문구와 함께 Error 1010을 반환합니다. HTTP 상태는 403입니다.

증상

• 차단이 즉각적입니다 — 챌린지도, CAPTCHA도 없이 Cloudflare가 하드 1010 페이지를 바로 서빙합니다.
• IP를 바꿔도 따라옵니다. 네트워크나 VPN 출구를 바꿔도 소용없습니다. 밴이 IP에 걸린 게 아니니까요.
• 자동화 클라이언트가 가장 심하게 맞습니다: 헤드리스 브라우저, 스크레이퍼, 기본 user-agent를 쓰는 HTTP 라이브러리, 보안 테스트 프록시.
• 가끔 진짜 브라우저도 헤더를 수정하는 확장이나 프라이버시 도구를 깐 뒤 걸립니다.

Error 1010의 실제 의미

Cloudflare의 1xxx 오류는 엣지 계층의 자체 판정이고, 각각 다른 이유로 막습니다. 어느 것인지 정확히 짚는 게 중요합니다. 해법이 서로 옮겨 붙지 않으니까요:

• 1010 — 브라우저 시그니처로 차단. Cloudflare의 Browser Integrity Check가 요청 헤더, user-agent, 기타 클라이언트 지문을 보고 당신 클라이언트가 진짜 브라우저가 아니라고 판단합니다.
• 1020 — 소유자가 작성한 커스텀 WAF/방화벽 규칙으로 차단(특정 경로·헤더·조건).
• 1015 — 레이트 리밋: 시간창 안 요청이 너무 많음, 일시적, 보통 Retry-After 동반.
• 1009 — IP가 소유자가 막은 지역으로 매핑되어 국가/지역이 밴됨.
• 1006 / 1007 / 1008 — 당신의 특정 IP 주소가 밴됨.

1010은 이 중 별종입니다. IP를 완전히 무시하고 클라이언트가 어떻게 생겼는지로 판단합니다. 그래서 VPN을 갈아타도 소용없고, 깨끗한 가정용 IP라도 요청 헤더가 자동화처럼 읽히면 막힙니다. 판정은 요청이 어디서 왔느냐가 아니라 HTTP 요청의 형태에 관한 것입니다.

여기서 두 가지가 따라옵니다. 첫째, 이건 Cloudflare가 당신을 평가한 게 아니라 사이트 소유자의 규칙입니다 — 고객 설정이라 Cloudflare 지원이 못 풉니다. 둘째, 자동화 클라이언트를 위장해서 “고치는” 건 누군가 일부러 켠 차단을 회피하는 것이지 정당한 수리가 아닙니다.

DechoNet으로 진단

• IP 점검으로 당신 주소가 어떻게 분류되는지 봅니다 — VPN·프록시·데이터센터 출구로 읽히는지. 1010이 엄밀히 IP 기반은 아니지만, 이런 분류는 Cloudflare가 불신하는 시그니처와 상관관계가 있습니다.
• HTTP 점검으로 실패 응답이 Cloudflare가 서빙한 403 + 1010이 맞는지, 오리진의 비슷한 403이나 잘못 읽은 다른 1xxx 코드가 아닌지 확인합니다.

해결 체크리스트

• 페이지의 정확한 번호를 확인한다. 1010·1020·1015·1009는 비슷해 보여도 해법이 다르다 — “access denied”가 아니라 코드를 읽어라.
• 방문자라면: 확장을 끈 깨끗한 표준 브라우저에서, 프라이버시/헤더 도구를 다 끄고 재시도한다. 그러면 열린다면 그 도구 중 하나가 시그니처를 다시 쓰고 있던 것이다.
• 방문자인데 여전히 막힌다면: 규칙은 소유자 쪽에 있다. WHOIS/RDAP 조회로 연락처를 찾아 정당한 브라우저가 막히고 있다고 알린다.
• 사이트를 소유한다면: Cloudflare 대시보드를 본다 — Browser Integrity Check, Bot Fight Mode, 관리형 WAF 규칙이 1010의 흔한 출처다. Security Events에서 차단을 규칙과 맞춰 보고, 허용하려던 트래픽을 allowlist한다.
• 소유하지 않은 사이트에 정당한 자동화를 돌린다면: 브라우저 위장을 그만두고 소유자에게 승인된 경로를 요청한다 — API 키, allowlist된 user-agent, IP allowlist.

에스컬레이션 시점

• 사이트를 소유하는데 어느 설정이 1010을 발동하는지 못 찾겠다면, 오류 페이지의 Ray ID가 Security Events의 특정 이벤트에 그 차단을 묶어 줍니다 — 검사를 광범위하게 끄기 전에 이걸로 정확한 규칙을 추적하세요.
• 진짜 사용자가 대량으로 막힌다면, IP를 하나씩 화이트리스트하지 말고 Browser Integrity Check나 문제의 WAF 규칙을 완화하세요. 사람을 잡는 시그니처 기반 차단은 대개 그 사이트의 실제 방문자층에 너무 공격적입니다.