Cloudflare 오류 1020 / 1015: 액세스 거부 및 요청 제한

이 오류의 의미와 확인 방법

• 요청한 웹사이트 또는 리소스 대신 Cloudflare 브랜드 오류 페이지가 표시됩니다.
• 페이지에 Error 1020: Access denied 또는 Error 1015: You are being rate limited가 명시적으로 표시됩니다.
• 응답에는 일반적으로 Cloudflare Ray ID, 대략적인 시간, 영향을 받은 호스트 이름이 포함됩니다.
• 오류 1020은 특정 IP 주소, 경로, 요청 패턴 또는 보안 규칙 조건에 영향을 줄 수 있으며, 다른 방문자는 계속 연결될 수 있습니다.
• 오류 1015는 요청 활동이 줄어들면 해소될 수 있지만, 요청이 급증할 때 다시 발생하거나 NAT, proxy 또는 corporate gateway를 통해 하나의 public IP를 공유하는 사용자에게 영향을 줄 수 있습니다.
• origin application이 요청을 처리하기 전에 Cloudflare edge에서 요청이 중단되었을 수 있습니다. 비슷하게 보이는 모든 장애의 원인이 같다고 가정하지 말고 오류를 origin log와 비교하세요.

가능성이 높은 순서의 주요 원인

가장 가능성 높은 원인

1. Cloudflare firewall, WAF 또는 보안 규칙이 요청과 일치했습니다(1020). 규칙은 source IP, 국가, URI 경로, HTTP method, header, user agent 또는 기타 요청 속성을 평가할 수 있습니다.
2. 설정된 rate-limit threshold를 초과했습니다(1015). 반복적인 페이지 로드, API polling, crawler, 병렬 다운로드, 로그인 시도 또는 하나의 공유 주소를 사용하는 여러 사용자가 정책을 트리거할 수 있습니다.
3. 보안 정책의 범위가 의도보다 넓습니다. 관리 경로 또는 악성 트래픽을 대상으로 만든 규칙이 정상 방문자, monitoring service, 사내 네트워크 또는 API client에도 적용될 수 있습니다.
4. 공유되었거나 비정상적인 source-IP 패턴이 일치를 유발했습니다. VPN, proxy, carrier NAT 및 corporate gateway로 인해 서로 관련 없는 사용자가 하나의 주소에서 접속하는 것처럼 보일 수 있습니다.
5. 최근 Cloudflare 설정 변경으로 차단이 발생했습니다. firewall, WAF, bot 또는 rate-limit 설정을 변경한 직후 오류가 시작되었다면 특히 가능성이 높습니다.

이러한 오류만으로 origin server가 다운되었다는 증거가 되지는 않습니다. 차단된 요청은 origin에 도달하지 않았을 수 있으며, 별도의 origin 문제는 다른 응답을 생성할 수 있습니다.

해결 방법

방문자인 경우

1. 전체 오류 페이지를 기록하세요. 1020인지 1015인지, Ray ID, 타임스탬프, time zone, 호스트 이름, 실패한 URL 또는 작업을 기록합니다. 비밀번호, token 또는 기타 민감한 요청 데이터는 공유하지 마세요.
2. 빠른 재시도를 중지하세요. 오류가 1015라면 다시 시도하기 전에 기다리세요. 반복적인 새로 고침, 여러 탭에서의 동시 요청, 자동화된 재시도는 rate limit을 연장하거나 반복해서 트리거할 수 있습니다.
3. 피할 수 있는 요청 발생원을 일시 중지하세요. 같은 사이트에 반복적으로 요청하는 download manager, 과도한 browser extension, script, API polling, crawler 또는 기타 도구를 중지합니다. 적절한 경우 VPN이나 proxy 없이 일반 browser 요청을 한 번 시도할 수 있지만, 권한 없이 access control을 우회해서는 안 됩니다.
4. 문제가 제한적인지 사이트 전체의 문제인지 확인하세요. 특정 경로, account 작업 또는 네트워크만 차단되고 다른 페이지는 작동할 수 있습니다. 다른 네트워크에서 요청이 성공했다고 해서 모든 사용자에게 사이트가 정상이라고 증명되는 것은 아닙니다.
5. 웹사이트 운영자에게 문의하세요. 오류 번호, Ray ID, 타임스탬프, 영향을 받은 URL, 수행 중이던 작업에 대한 설명을 제공하세요. public IP address는 운영자가 요청하고 공유해도 적절한 경우에만 보내세요.

Cloudflare zone을 관리하는 경우

1. 응답 계층을 확인하세요. Cloudflare 브랜드, 오류 번호, Ray ID 및 타임스탬프를 확인합니다. 해당 event를 origin access log와 비교하세요. 대응하는 origin 요청이 없다면 차단은 Cloudflare edge에서 발생했을 가능성이 높습니다.
2. Error 1020의 경우 security event와 일치하는 규칙을 확인하세요. Ray ID, 시간, source IP 및 요청 경로를 사용해 요청을 거부한 firewall rule, WAF 또는 custom rule, access policy 또는 기타 제어 항목을 식별합니다. 모든 보안 제어를 비활성화하지 말고 rule expression을 검토하세요.
3. Error 1015의 경우 rate-limit analytics와 설정을 확인하세요. 일치한 호스트 이름, 경로, method, client identity 및 threshold를 확인합니다. NAT, proxy 또는 corporate gateway를 통해 많은 정상 사용자가 하나의 주소를 공유하는지 확인하세요.
4. 차단된 요청과 허용된 요청을 비교하세요. 경로, query string, method, header, source network 및 요청 빈도를 확인합니다. 이를 통해 false positive와 실제로 과도하거나 악의적인 트래픽을 구분할 수 있습니다.
5. 승인된 범위 내에서 가장 작은 변경을 적용하세요. rule expression의 범위를 좁히고, 의도하지 않은 조건을 수정하거나, 범위를 좁힌 예외를 만들거나, 영향을 받은 endpoint에 대한 rate-limit policy를 조정합니다. 담당 security owner가 다르게 승인하지 않는 한 authentication 및 administrative path에는 더 강력한 제어를 유지하세요.
6. 안전하게 테스트하고 모니터링하세요. 영향을 받은 트래픽을 대표하는 승인된 test request를 사용합니다. 정상적인 액세스가 작동하면서도 의도한 보호 기능이 통제 대상으로 설계된 트래픽에 계속 적용되는지 확인하세요. 변경 후 Cloudflare event와 origin log를 검토합니다.
7. 일치 항목이 명확하지 않으면 근거를 갖춰 에스컬레이션하세요. Ray ID, 타임스탬프와 time zone, rule identifier 또는 policy name, 호스트 이름, 경로, source-network context 및 관련 event 세부 정보를 보관합니다. 각 결과를 기록하지 않은 채 규칙을 반복해서 변경하지 마세요.

예방 및 해결 확인 방법

• 특히 public page, API 및 shared network에 대해서는 firewall과 WAF expression의 범위를 가능한 한 좁게 유지하세요.
• 광범위한 global threshold에 의존하지 말고 path, method, client identity 및 traffic pattern을 적절히 조합해 rate limit 범위를 설정하세요.
• 정상적인 트래픽을 평가할 때 NAT, VPN, proxy 및 corporate egress address를 공유된 identity로 고려하세요.
• 규칙을 배포하거나 변경한 후에는 일반 사용자, monitoring system 및 API client의 트래픽을 포함해 security event를 검토하세요.
• 반복적인 재시도 대신 support team이 Ray ID, 타임스탬프, 호스트 이름 및 영향을 받은 경로를 수집할 수 있는 표준 절차를 마련하세요.
• Cloudflare-edge block과 origin error의 차이를 문서화해 대응 담당자가 먼저 올바른 log를 확인하도록 하세요.
• 범위를 좁혀 승인된 예외를 기록하고 정기적으로 검토하세요. 보호 기능을 약화하는 영구적인 광범위 allowlist는 피하세요.