1001 DNS Resolution Error (Cloudflare) 해결

문제

방문자가 사이트에 접속하면 Cloudflare가 Error 1001: DNS resolution error로 응답합니다. 이건 오리진 서버가 죽은 것도, 방문자 브라우저 문제도 아닙니다. 요청은 Cloudflare 엣지까지 멀쩡히 도달했습니다 — 그런데 Cloudflare가 요청된 호스트명을 보고 어느 존이 처리해야 하는지 찾다가 빈손으로 돌아온 것입니다. 엣지가 자신이 서빙하지 않는 이름 앞으로 온 요청을 손에 쥐고 있는 상태죠. 그게 오류의 전부입니다: 패킷은 도착했는데, 그 호스트명에는 아무도 살지 않습니다.

증상

• Cloudflare 브랜드 경고 페이지에 Error 1001과 DNS resolution error 라벨이 표시됩니다.
• 도메인 전체가 아니라 특정 호스트명에 영향을 줍니다 — apex는 되는데 서브도메인이 안 되거나 그 반대일 수 있습니다.
• DNS 변경 직후에 자주 나타납니다: 도메인을 Cloudflare에 추가·제거하거나 레코드를 다시 가리킬 때.
• 오리진 서버 로그에는 아무것도 없습니다. 요청이 오리진에 닿은 적이 없으니까요. 엣지에서 죽었습니다.

이 오류의 실제 의미

Cloudflare anycast 네트워크로 가는 모든 요청은 엣지 IP 중 하나에 떨어지고, 엣지는 Host 헤더(또는 SNI)로 그 요청이 어느 고객 존에 속하는지 판단합니다. Error 1001은 그 조회가 실패했을 때 나옵니다: 호스트명이 엣지가 볼 수 있는 어느 Cloudflare 존의 활성 레코드에도 매핑되지 않는 것이죠.

핵심 구분 대상은 1016 Origin DNS Error입니다. 1016은 Cloudflare가 이미 당신을 존에 매칭한 뒤, 오리진의 호스트명(CNAME이 가리키는 백엔드)을 해석하려다 실패한 것 — 두 번째, 하류 조회입니다. 1001은 첫 번째 조회 — “이 요청은 누구 것인가?” — 가 실패한 것입니다. Cloudflare가 오리진을 떠올리기도 전에, 한 단계 앞에서 실패합니다.

주요 원인 3가지

1. DNS 레코드가 Cloudflare를 가리키는데, 그 호스트명을 서빙하는 존이 없다 - 전형적인 경우입니다. 낡은 A/AAAA 레코드(와일드카드, 이전 작업, 잊은 서브도메인이 남긴 경우가 많음)가 Cloudflare anycast IP로 해석되지만, Cloudflare 존 안에는 매칭되는 레코드가 없습니다. 엣지는 요청을 받아도 넘겨줄 곳이 없습니다.
2. 전환 중인 도메인 - 방금 도메인을 Cloudflare에 추가했는데 프로비저닝이 끝나지 않았거나, 방금 제거했는데 네임서버·레코드 변경이 아직 전파되지 않았습니다. 그 구간 동안 요청은 Cloudflare가 (아직, 또는 더는) 관장하지 않는 호스트명을 향해 엣지에 도달합니다.
3. 교차 계정 CNAME - 외부 도메인(Cloudflare에 없거나 다른 계정)이 Cloudflare에서 활성인 호스트명을 가리키는 CNAME을 가지고 있습니다. 요청은 외부 Host 헤더를 달고 엣지에 도착하는데, 그 헤더는 엣지가 서빙하는 어느 존에도 매핑되지 않습니다. (타깃이 Cloudflare for SaaS를 요구하면 구성에 따라 1001 또는 1014로 나타납니다.)

DechoNet으로 진단하기

• DNS 진단은 실패하는 호스트명을 해석해 정확히 무엇을 가리키는지 보여줍니다. A/AAAA 응답이 Cloudflare anycast IP(104.16.x.x / 172.64.x.x 및 인접 대역)인데 페이지가 1001을 던진다면, 레코드가 Cloudflare를 가리키지만 뒤에 존이 없다는 걸 확인한 겁니다. CNAME이라면 타깃을 따라가 보세요 — 매달린(dangling) 타깃이나 교차 계정 타깃이 범인입니다.
• HTTP 진단은 이 오류가 오리진이 아니라 Cloudflare 엣지에서 나왔음을 확인합니다(cf-ray 헤더와 1001 본문 확인). 이로써 실패 지점을 엣지 조회로 못 박고 오리진 측 문제를 배제합니다.

해결 체크리스트

• DNS 진단에서 실패하는 호스트명이 무엇으로 해석되는지 확인합니다. Cloudflare anycast IP인데 1001 페이지가 뜨면, 레코드는 있으나 서빙하는 존이 없다는 뜻입니다.
• Cloudflare 대시보드에서 실패하는 정확한 호스트명에 대한 A·AAAA·CNAME 레코드가 있는지 확인합니다 — apex, www, 각 서브도메인은 별개 레코드입니다. 빠진 것을 실제 오리진 IP나 백엔드를 가리키도록 추가합니다.
• 도메인을 최근에 추가했다면, 존 상태가 Active(Pending 아님)인지, 등록기관 네임서버가 Cloudflare가 배정한 쌍과 일치하는지 확인합니다. Pending 존은 레코드를 서빙하지 못합니다.
• 도메인을 최근에 Cloudflare에서 제거했다면, 모든 A/AAAA 레코드를 Cloudflare IP 대역에서 실제 서버로 다시 가리키고, 캐시가 만료되도록 레코드 TTL만큼 기다립니다.
• 다른 제공자로의 CNAME이라면, 타깃을 끝까지 해석합니다. 다른 Cloudflare 계정의 호스트명에 떨어진다면, 타깃 쪽에 Cloudflare for SaaS가 필요하거나 오리진에 A 레코드를 두어야 합니다.
• 호스트명이 오리진으로 해석되고 1001 페이지가 사라질 때까지 DNS 진단과 HTTP 진단을 다시 실행합니다.

언제 에스컬레이션할까

• 레코드가 정확하고, 존이 Active이고, 네임서버가 일치하는데도 레코드 TTL을 넘겨 1001이 지속되면, Cloudflare에 티켓을 열고 오류 페이지의 cf-ray 값을 첨부하세요 — 그 ID로 지원팀이 엣지에서 어느 조회가 실패했는지 추적합니다.
• 실패하는 호스트명이 당신이 통제하지 않는 SaaS 플랫폼 소속(벤더의 Cloudflare 설정으로 들어가는 CNAME)이라면, 수정은 벤더 쪽입니다 — 그들이 당신의 커스텀 호스트명을 프로비저닝해야 합니다. 정확한 호스트명과 cf-ray를 전달하세요.
• 이전 작업 중 1001이 깜빡깜빡한다면, 그건 오설정이 아니라 전파입니다. 새 레코드가 맞는지 확인하고, 설정을 반복해서 바꾸기보다 옛 TTL이 만료되도록 두세요.