Cloudflare Error 1000 원인과 해결

Problem

Cloudflare가 Error 1000: DNS points to prohibited IP를 반환합니다. 엣지가 요청을 어디로 보낼지 조회했더니 Cloudflare 자신의 IP 중 하나가 나왔고, 자기 자신으로 순환하는 대신 연결을 거부한 것입니다.

Symptoms

• 사이트의 모든 요청이 일부 경로가 아니라 전부 Cloudflare 1000 에러 페이지를 보입니다.
• DNS 레코드를 수정하거나, 오리진을 바꾸거나, 앞단에 프록시를 추가한 직후 시작됐습니다.
• 오리진 호스트명을 DNS 조회하면 실제 서버 IP가 아니라 Cloudflare 주소(흔히 104.x 또는 172.64–172.71.x 대역)가 나옵니다.
• 사이트가 멀쩡했는데, dig가 보여준 값을 복사해 오리진 IP를 “고쳤더니” 즉시 깨졌습니다.

What Error 1000 Actually Means

Cloudflare 엣지는 리버스 프록시입니다: 방문자가 Cloudflare에 연결하면, Cloudflare가 이어서 당신의 오리진에 연결합니다. 이 두 번째 홉이 작동하려면 DNS 레코드의 오리진 주소가 당신의 서버 — Cloudflare가 아닌 실제 호스트여야 합니다. Error 1000은 그 주소가 Cloudflare IP일 때 발생합니다. 엣지가 요청을 자기 자신에게 전달해야 하므로, 자기 꼬리를 쫓는 대신 멈추고 1000을 반환합니다.

거의 모두를 걸리게 하는 함정은 늘 똑같습니다. 오리진 IP를 알고 싶어 dig yourdomain.com을 돌립니다 — 그런데 그 호스트명은 이미 Cloudflare를 통해 프록시되고 있으므로, dig는 당신 서버가 아니라 Cloudflare의 애니캐스트 IP를 돌려줍니다. 그 104.x 주소를 “오리진”이라며 A 레코드에 붙여넣으면, 이제 레코드는 말 그대로 Cloudflare를 Cloudflare로 가리킵니다. 오리진을 드러내야 했던 그 조회는 그 앞에 선 가면만 보여준 셈입니다.

이건 이웃한 에러들과 깔끔히 구분해둘 가치가 있습니다. 에러 페이지가 비슷해 보이지만 해결책은 완전히 다르니까요. Error 1016은 해석 실패 — 엣지가 오리진 호스트명을 어떤 IP로도 바꾸지 못한 것입니다. Error 523은 라우팅 실패 — IP는 해석되지만 아무도 응답하지 않는 것입니다. Error 1000은 둘 다 아닙니다: IP가 완벽히 해석되고 Cloudflare가 그걸 자기 것으로 알아본 것입니다. 주소는 유효하고, 단지 오리진으로는 금지된 것입니다.

Top 3 Causes

1. Cloudflare IP를 가리키는 A 레코드 - 위 함정의 직접적 버전입니다. Cloudflare DNS A 레코드가 실제 오리진 서버 IP 대신 104.x나 172.6x.x 주소를 담고 있습니다. 호스팅이 준 실제 오리진 주소 — SSH로 접속하는 바로 그 주소 — 로 레코드를 설정해 고치세요. Cloudflare가 돌려준 어떤 값도 아닙니다.
2. 또 다른 리버스 프록시를 거치는 이중 프록시 순환 - 레코드가 두 번째 리버스 프록시(proxy_pass를 쓰는 nginx 박스, 또 다른 CDN)를 가리키고, 그게 요청을 다시 Cloudflare로 전달합니다. 요청이 Cloudflare → 프록시 → Cloudflare로 튕깁니다. 프록시 홉을 직접 오리진 주소로 바꾸거나, 리다이렉트 로직을 프록시 패스 대신 오리진 측 HTTP 리다이렉트로 옮기세요.
3. Cloudflare 네트워크 안으로 해석되는 SaaS나 Tunnel 설정 - 레코드가 자기 광고 IP 대역(BYOIP)에서 Cloudflare for SaaS를 돌리는 SaaS 제공업체를 가리키거나, 떠도는 수동 레코드가 Cloudflare Tunnel과 충돌합니다. 어느 쪽이든 타깃이 Cloudflare 안에 떨어집니다. 헤더 엣지 케이스도 이걸 일으킵니다: 들어오는 요청에 CF-Connecting-IP 헤더가 있거나, X-Forwarded-For가 두 개이거나, X-Forwarded-For가 100자를 넘어도 1000이 발생합니다.

Diagnose with DechoNet

• DNS 조회로 오리진 호스트명(또는 A 레코드 원값)이 실제로 어떤 IP로 해석되는지 확인하세요. 그 IP가 Cloudflare 대역 — 104.16.0.0/13, 172.64.0.0/13 등 — 에 있다면 순환을 찾은 것입니다. 레코드가 Cloudflare를 Cloudflare로 되돌려 가리키고 있고, 그게 버그 전부입니다.

Resolution Checklist

• 실제 오리진 IP를 찾으세요 — 프록시된 도메인의 dig가 아니라 호스팅 패널이나 서버의 /etc/hosts에서. 그 조회는 늘 Cloudflare만 보여줍니다.
• Cloudflare DNS 패널에서 A(또는 AAAA) 레코드를 그 실제 오리진 IP로 설정하세요. 안정적인 오리진 IP가 없다면, 수동 레코드 대신 Cloudflare Tunnel을 쓰라는 신호입니다.
• 방금 입력한 값을 DNS 조회로 돌려 Cloudflare 대역에 속하지 않음을 확인하세요.
• 경로에 두 번째 리버스 프록시가 있다면 순환을 제거하세요 — Cloudflare를 진짜 오리진으로 곧장 가리키거나, 프록시 홉을 오리진 측 HTTP 리다이렉트로 바꾸세요.
• SaaS 호스팅 호스트명이라면 자기 DNS 수정을 멈추고, 커스텀 호스트명이 그쪽 Cloudflare for SaaS 설정에 프로비저닝됐는지 제공업체에 문의하세요.
• 재테스트하세요. 레코드가 엣지가 실제로 도달할 수 있는 비(非)Cloudflare 주소를 가리키는 순간 1000 페이지는 사라집니다.

When to Escalate

• 레코드가 이미 정상적인 비Cloudflare 오리진을 가리키는데도 1000이 뜬다면, 헤더 주입 원인(앞단 프록시가 추가한 CF-Connecting-IP나 중복 X-Forwarded-For)을 상위에서 찾아 그 계층을 관리하는 쪽에 에스컬레이션하세요.
• 호스트명이 SaaS 제공업체의 Cloudflare for SaaS 배포로 해석된다면 해결은 전적으로 그쪽 몫입니다 — 정확한 호스트명과 1000 에러를 들고 그들의 지원팀에 에스컬레이션하세요. 당신의 DNS 패널에서 어떤 변경도 BYOIP 순환을 풀 수 없습니다.