1014 CNAME Cross-User Banned (Cloudflare) 해결

Problem

Cloudflare가 Error 1014: CNAME Cross-User Banned를 반환합니다. DNS는 올바르고, 타깃 호스트명은 해석되고, 죽은 것도 없는데 사이트가 뜨지 않습니다. 깨진 레코드도, 도달 불가한 오리진도 아닙니다. Cloudflare가 여러분의 CNAME을 의도적으로 거부하는 것입니다. 그 CNAME이 다른 누군가의 Cloudflare 계정에 사는 호스트명을 가리키기 때문입니다.

Symptoms

• Cloudflare 브랜드 오류 페이지에 Error 1014와 “CNAME Cross-User Banned”가 표시됩니다.
• 다른 도메인(그것도 Cloudflare에 있는)을 가리키는 CNAME을 추가하는 순간 나타납니다 — 대개 SaaS 플랫폼, 호스팅 제공자, 파트너의 호스트명입니다.
• CNAME 타깃은 그 자체로 잘 해석됩니다; 계정 간 홉만 막힙니다.
• 간헐적이지 않고 전면적·일관적입니다 — 모든 요청이 똑같이 실패합니다.
• 레코드를 추가하려 할 때 DNS UI에서 경고로 뜨기도, 방문자가 사이트에 접속하는 요청 시점에 뜨기도 합니다.

What This Error Actually Means

Cloudflare는 여러분의 존과 타깃의 존 모두 앞에 섭니다. 여러분의 CNAME이 이미 다른 계정을 위해 Cloudflare가 프록시 중인 호스트명을 가리키면, 엣지는 두 존이 서로 다른 고객의 것임을 알아채고 — 기본값으로 그 링크를 차단합니다. 그것이 Error 1014입니다.

이유는 버그가 아니라 보안입니다. Cloudflare가 아무 존이나 다른 Cloudflare 프록시 호스트명에 CNAME으로 올라타게 두면, 한 고객이 도메인을 다른 고객의 설정에 가리켜 그 엣지 구성을 물려받을 수 있습니다 — 피싱, 사칭, 소유하지도 않은 인프라에 올라타는 깔끔한 경로입니다. 그래서 계정 간 CNAME에 대한 Cloudflare의 기본 답은 거부입니다. 타깃을 소유한 계정이 명시적으로 허용하지 않는 한.

이것이 1014를 혼동되는 DNS 오류들과 갈라놓습니다. 1016은 진짜 해석 실패입니다 — Cloudflare가 오리진 호스트명을 IP로 전혀 바꾸지 못합니다. 1000은 순환입니다 — 레코드가 실제 오리진 대신 Cloudflare anycast IP를 가리킵니다. 1014에서는 해석이 성공합니다. 타깃은 도달 가능하고, DNS는 유효하고, 기술적으로 전부 됩니다. 엣지가 정책상 막는 것입니다: 타깃의 허가 없이는 여러분 계정의 CNAME을 다른 계정의 프록시된 호스트명에 올리지 않습니다.

앞으로 나아갈 길은 셋뿐입니다: 그 허가를 받거나(타깃이 Cloudflare for SaaS를 켜고 여러분 호스트명을 추가), 계정 간 홉을 없애거나(IP를 가리킴), 타깃을 Cloudflare 뒤에서 빼내는 것. 재시도·캐시 비우기·레코드 재저장은 아무것도 바꾸지 못합니다 — 이 차단은 결함이 아니라 결정입니다.

Top 3 Causes

1. 다른 Cloudflare 계정이 프록시하는 SaaS·호스팅 호스트명으로의 CNAME - 압도적으로 흔한 경우입니다. app.someplatform.com 같은 곳으로 도메인을 CNAME하라는 안내를 받았는데, 그 플랫폼이 Cloudflare에서 자체 존을 운영하고 두 계정 사이에 아무 관계가 없는 경우입니다. Cloudflare는 계정 간 CNAME을 보고 차단합니다. 제공자가 Cloudflare for SaaS로 여러분 호스트명을 온보딩해야 작동합니다.
2. 파트너·클라이언트의 Cloudflare 프록시 도메인을 가리킴 - 에이전시와 멀티테넌트 설정이 상시로 부딪힙니다: 파트너가 자기 Cloudflare 계정에서 관리하는 호스트명으로 CNAME하는 경우입니다. 서로 신뢰해도 Cloudflare는 그걸 모르므로, 타깃 계정이 명시적으로 허용할 때까지 링크를 막습니다.
3. 최근 Cloudflare로 옮겨온 호스트명을 향한 남은 CNAME - 어제는 타깃이 Cloudflare에 없었기에 레코드가 작동했는데 — 이후 타깃이 DNS를 Cloudflare로 이전했고, 잘 되던 여러분의 CNAME이 갑자기 두 Cloudflare 계정을 넘나들며 1014를 유발합니다. 여러분 쪽은 아무것도 안 바뀌었고, 타깃의 이전이 스위치를 뒤집었습니다.

Diagnose with DechoNet

• DNS 조회로 여러분의 CNAME이 정확히 무엇을 가리키는지, 그 타깃이 Cloudflare 프록시 호스트명인지 확인하세요. 타깃이 Cloudflare 엣지로 깨끗이 해석되면, 1014가 불평하는 계정 간 설정을 확인한 것입니다 — DNS가 멀쩡하다는 게 바로 요점입니다.
• HTTP 검사로 이 실패가 진짜 오리진 장애나 다른 10xx 오류가 아니라 Cloudflare 1014 페이지가 맞는지 확인하세요. 1014는 일반 다운타임과 전혀 다르게 생겼으므로 — 해석은 되고 타깃도 살아 있으니 — 정확한 오류 페이지를 확인해야 존재하지도 않는 오리진 문제를 쫓지 않습니다.

Resolution Checklist

• 타깃이 Cloudflare에 있는지 확인. CNAME 타깃을 DNS 조회로 해석하세요. Cloudflare 엣지에 착지하고 여러분 것이 아닌 계정에 속하면, 그것이 1014를 유발하는 계정 간 홉입니다.
• 타깃 소유자에게 Cloudflare for SaaS 활성화를 요청. 올바른 해결책: 타깃을 소유한 플랫폼·파트너가 Cloudflare for SaaS로 여러분 호스트명을 커스텀 호스트명으로 추가합니다. 계정 간 CNAME을 유지하는 유일한 깔끔한 방법입니다.
• 또는 A/AAAA 레코드로 전환 — 타깃의 안정적 오리진 IP를 통제할 때만. CNAME을 통째로 없애 차단할 계정 간 링크 자체를 제거합니다. IP가 바뀌는 SaaS 플랫폼에는 쓰지 마세요.
• 또는 타깃을 Cloudflare 뒤에서 빼내기. 타깃 도메인의 Cloudflare 계정을 여러분이 소유한다면, 언프록시(회색 구름)하거나 Cloudflare에서 옮기면 계정 간 조건이 사라집니다 — 그 도메인의 Cloudflare 기능을 잃는 대가로.
• Cloudflare 지원에 예외 요청 — 타깃 계정이 요청할 수 있는 경우. 이 경로는 타깃 계정에서만 가능하며 보통 유료 플랜에서 열립니다.
• 변경 후 재검증. 레코드를 다시 해석하고 새로고침하세요 — 1014는 계정 간 링크가 승인되거나 제거될 때만 풀립니다. 재시도로는 안 됩니다.

When to Escalate

• CNAME 타깃이 서드파티 SaaS·호스팅 플랫폼이면 Cloudflare가 아니라 그쪽 지원에 에스컬레이션하세요 — Cloudflare for SaaS를 켜거나 예외를 요청할 수 있는 건 타깃을 소유한 계정뿐이라, 해결책은 전적으로 그쪽에 있습니다.
• 두 존을 모두 소유하는데도 계정 간 CNAME이 작동하지 않으면 타깃 계정에서 Cloudflare 지원 티켓을 여세요; 같은 소유자의 계정 간 링크는 대개 Cloudflare가 호스트명을 화이트리스트에 넣어줘야 하며, 그건 그들만 할 수 있습니다.