Cloudflare 커스텀 도메인 | 네임서버와 SSL Full Strict

registrar vs 네임서버

등록 기관은 도메인을 산 회사다. 네임서버는 그 도메인의 DNS 질문에 누가 답할지를 가리킨다. 두 층이 같다 보면, 등록 기관 화면에서 A 레코드를 고쳤는데 사이트가 안 바뀌는 일이 난다. 권한 DNS가 이미 Cloudflare면, 레코드는 Cloudflare DNS에만 있다.

도메인마다 할당된 네임서버 두 개가 붙는다. 이 이름은 존 Overview에 있고, 임의로 바꾸지 못한다. 등록 기관의 관리 화면에서 기존 네임서버를 지우고 Cloudflare가 보여 준 이름을 그대로 넣는다. 철자가 하나라도 다르면 위임이 실패한다. 등록 기관을 모르면 ICANN Lookup으로 찾는다.

Cloudflare Registrar로 산 도메인은 이미 Cloudflare가 권한 DNS라서 이 위임 절차를 건너뛴다. 다른 등록 기관에 두고 네임서버만 Cloudflare로 바꾸는 구성이 풀 셋업의 본체다.

DNSSEC가 이전 제공자에 켜져 있으면, 네임서버를 바꾸기 전에 등록 기관에서 DNSSEC를 끈다. 켜 둔 채로 네임서버만 바꾸면 도메인이 안 열릴 수 있다. DS 레코드는 DNS 제공자가 아니라 등록 기관(부모 존)에 산다. 이전 제공자의 DS가 남으면 해석기는 SERVFAIL을 돌려주고, 존은 Pending Nameserver Update에 머물 수 있다. Active가 된 뒤에 Cloudflare에서 DNSSEC를 다시 켠다.

핵심 포인트: 풀 셋업의 첫 관문은 레코드 내용보다, 등록 기관에 적힌 네임서버가 Overview의 할당값과 문자 단위로 같은지와, 옛 DS가 남아 있지 않은지다.

풀 셋업

Cloudflare 계정에 에이펙스 도메인(예: example.com)을 온보딩하면, 기존 DNS를 스캔하거나 손으로 레코드를 넣는다. 스캔이 모든 레코드를 찾는다고 보장하지 않는다. 존 에이펙스, www, 메일 레코드를 특히 다시 본다.

위임 확인은 최대 24시간을 기다리는 경우가 많다. Active 메일이 오고, 대시보드 상태가 Active이며, dig ns 도메인 @1.1.1.1에 Cloudflare 네임서버가 보이면 위임이 잡힌 것이다. 부모 존이 아직 옛 네임서버를 가리키면 등록 기관이 변경을 게시하지 않은 상태다.

dig ns는 권한 네임서버 목록을 묻는다. @1.1.1.1은 Cloudflare 공용 해석기다. 등록 기관 화면과 이 출력이 다르면, 아직 전파 중이거나 철자가 틀린 것이다. Set up a primary zone 문서가 이 구간의 1차 출처다.

존이 Pending Nameserver Update에 머물면, 등록 기관의 위임이 Overview 할당과 다르거나, 옛 DS가 남았거나, 예전에 같은 도메인을 지웠다가 다시 넣을 때 Cloudflare가 다른 네임서버 쌍을 준 경우다. 대시보드에 적힌 현재 할당을 등록 기관에 넣는다. Zone stuck in Pending Nameserver Update 문서가 이 실패를 설명한다.

하위 도메인만 CNAME으로 Pages나 원본에 연결하는 경로는 풀 셋업이 아니다. 에이펙스(example.com)를 Pages에 붙이려면 그 도메인이 같은 계정의 Cloudflare 존이어야 하고, 네임서버 위임이 필요하다.

A CNAME MX

에이펙스 레코드는 사이트를 열어 주는 A, AAAA, 또는 CNAME이다. 값은 호스팅이나 Pages, Workers가 요구하는 주소를 따른다. www는 같은 내용이거나 리다이렉트인 경우가 많다. www 레코드가 없으면 주소창에 www를 붙인 방문자가 사이트를 못 찾는다.

메일 레코드는 프록시를 켜지 않는다. MX, 메일용 A, SPF, DKIM, DMARC TXT는 DNS only(회색 구름)다. 프록시를 켜면 메일 경로가 깨질 수 있다. 정확한 값은 메일 제공자가 준다. SPF는 어느 서버가 그 도메인으로 메일을 보낼 수 있는지 선언하는 TXT다. DKIM은 서명 키를 가리키는 TXT다. DMARC는 그 둘을 어떻게 강제할지 _dmarc에 적는다. 세 TXT를 주황 구름으로 바꾸면 메일 제공자의 확인이 에지를 보고 실패할 수 있다.

A는 IPv4, AAAA는 IPv6다. CNAME은 다른 호스트 이름을 가리킨다. 에이펙스에 CNAME을 쓸 수 있는지는 존과 제공자에 따라 다르다. Pages 에이펙스는 같은 계정의 Cloudflare 존과 네임서버 위임이 필요하다. 하위 도메인만이면 외부 DNS에 CNAME을 *.pages.dev로 넣는 경로가 있다. 대시보드 Custom domains 연결 없이 CNAME만 넣으면 522가 날 수 있다.

CAA 레코드가 Let's Encrypt, Google Trust Services, SSL.com 발급을 막으면 Pages 인증서가 안 나온다. 막는 CAA가 있으면 Cloudflare 문서가 적는 issue 값을 허용 목록에 넣는다.

프록시 없이 원본 IP가 바뀌는 호스트는 A 레코드가 금방 낡는다. 동적 DNS나 프록시 뒤의 안정된 호스트명이 필요하다. 서드파티 도메인 확인용 CNAME은 보통 회색 구름이다. 주황 구름으로 바꾸면 확인 서버가 Cloudflare 에지를 보고 실패한다.

주황 구름

각 A, AAAA, CNAME에는 프록시 토글이 있다. Proxied(주황 구름)이면 웹 트래픽이 Cloudflare 네트워크를 지난다. 캐시, DDoS 방어, Universal SSL 같은 에지 기능이 여기 붙는다. 방문자가 보는 IP는 Cloudflare 애니캐스트이고, 원본 IP는 DNS 조회만으로는 바로 안 나온다.

DNS only(회색 구름)이면 Cloudflare는 레코드 값만 돌려주고 트래픽을 프록시하지 않는다. 서드파티 도메인 확인용 CNAME, 메일, 원본에 직접 TLS를 맡겨야 하는 경우가 여기 해당한다.

프록시를 켠 뒤에 Origin CA 인증서만 원본에 두면, 방문자가 원본 IP로 직접 붙을 때 브라우저가 그 인증서를 신뢰하지 않는다. Origin CA는 Cloudflare와 원본 사이를 암호화할 때 쓰며, 브라우저용 공개 CA가 아니다. 프록시를 끄거나 Cloudflare를 일시 중지하면 방문자에게 인증서 경고가 난다.

워커와 커스텀 도메인, 터널(cloudflared)은 별 계층이다. 터널이 끊기면 1033이 난다. 1033은 네임서버 실수가 아니라, 건강한 cloudflared가 에지에 없는 상태다. 터널 호스트의 1033은 cloudflared가 Inactive, Down, Degraded인지 대시보드와 cloudflared tunnel list로 가른다. 502이면서 origin에 닿지 않는다는 문구는 터널은 살아 있고 로컬 서비스가 죽은 상태라 1033과 다르다.

주황 구름이면 에지가 TLS를 종료한다. 방문자 인증서는 Universal SSL이다. 원본으로 다시 붙는 구간의 암호는 SSL/TLS 모드가 정한다. 회색 구름이면 이 종료가 없다. 방문자는 레코드 값의 IP로 바로 간다. 메일이 회색이어야 하는 이유는 MX가 에지가 아니라 메일 서버를 가리켜야 해서다. 웹이 주황인 이유는 캐시와 DDoS와 인증서가 에지에 붙어서다. 한 토글이 두 층의 길을 가른다.

Full vs Full strict

암호화 모드는 방문자-Cloudflare, Cloudflare-원본 두 구간을 나눈다. Off는 둘 다 평문이다. Flexible는 방문자까지는 HTTPS일 수 있고, 원본에는 HTTP로 붙는다. 원본이 HTTP를 HTTPS로 되돌리면 ERR_TOO_MANY_REDIRECTS 루프가 돈다. Flexible에서 원본의 HTTPS 강제와 Always Use HTTPS가 겹치면 같은 루프가 난다.

Full은 방문자 요청이 HTTPS이면 원본에도 HTTPS로 붙는다. 원본 인증서가 자체 서명이어도 통과하는 경우가 많다. Full (strict)는 Full에 더해 원본 인증서가 만료되지 않았고, 공개 CA 또는 Cloudflare Origin CA가 발급했으며, CN 또는 SAN이 호스트와 맞는지를 검사한다. 원본은 443에서 HTTPS를 받아야 한다.

새 존의 기본은 Automatic SSL/TLS인 경우가 늘어 있다. 추천기가 더 안전한 모드로 올리되, 인증서가 만료됐다고 해서 Full (strict)를 더 약한 모드로 내리지는 않는다. 수동으로 Custom을 고르면 Off, Flexible, Full, Full (strict), Strict (SSL-Only Origin Pull)을 직접 고른다.

Pages처럼 원본이 Cloudflare 네트워크 안에 있으면, 전통적인 「내 서버에 Origin CA를 심는」 절차와 결이 다르다. 그래도 존 전체에 Flexible이 켜져 있고 원본(또는 다른 호스트)이 HTTPS로 되돌리면 루프는 같은 방식으로 난다.

525는 Full 또는 Full (strict)에서 원본과 SSL 핸드셰이크가 실패할 때 난다. 원본에 인증서가 없거나 443이 닫혀 있거나, 암호 스위트가 안 맞거나 SNI가 없는 경우가 원인이다. 526은 Full (strict)에서 원본 인증서를 검증하지 못할 때 난다. 만료, 호스트 불일치, 자체 서명을 Trust Store에 안 넣은 상태가 여기 해당한다. 급한 우회는 Full로 낮추는 것이나, 원인은 원본 인증서를 맞추는 쪽이다.

Always Use HTTPS와 HSTS는 방문자 HTTP를 HTTPS로 고정한다. 원본이 HTTPS를 다시 HTTP로 돌리면 루프가 난다. 리다이렉트 규칙 두 개가 서로를 가리켜도 같은 증상이 난다.

NXDOMAIN

DNS_PROBE_FINISHED_NXDOMAIN은 그 이름에 대한 레코드가 없다는 뜻이다. 네임서버만 바꾸고 DNS 레코드를 비운 채로 활성화하면 방문자가 이 화면을 본다. 위임은 끝났는데 존이 비어 있는 상태다.

스캔이 에이펙스와 www를 놓치면 같은 증상이 난다. www만 있고 @가 없으면 example.com이 NXDOMAIN이다. 반대면 www만 실패한다. 메일 TXT가 없어도 웹은 열리지만, 수신 메일은 다른 실패다.

Pending Nameserver Update와 NXDOMAIN은 다르다. Pending은 부모 존이 아직 Cloudflare를 가리키지 않는 쪽이다. NXDOMAIN은 위임은 됐는데 레코드가 없는 쪽이다. dig ns에 Cloudflare가 보이는데 A가 없으면 후자다.

Pages

Pages 커스텀 도메인은 대시보드의 Custom domains에서 도메인을 연결한 뒤에 DNS가 잡힌다. 존 밖에서 CNAME만 프로젝트.pages.dev로 수동으로 넣으면 연결이 안 되고 522가 날 수 있다. 에이펙스(example.com)를 Pages에 붙이려면 그 도메인이 같은 계정의 Cloudflare 존이어야 하고, 네임서버 위임이 필요하다. 하위 도메인만이면 외부 DNS에 CNAME을 *.pages.dev로 넣는 경로가 있다.

Pages 커스텀 도메인을 연결한 뒤 DNS를 다른 원본으로 바꿨다가 다시 Pages로 돌리면, 다시 Active가 될 때까지 에러가 난다. 잠시 트래픽만 돌리려면 DNS를 빼기보다 Origin 규칙이나 리다이렉트 규칙이 덜 위험하다. Pages custom domains 문서가 이 구간의 1차 출처다.

정적 내보내기나 Cloudflare Pages에 같은 저장소를 연결하면, 빌드 산출물이 *.pages.dev에 먼저 뜬다. 커스텀 도메인은 Pages 프로젝트의 Custom domains에서 붙인다. Vercel 쪽 도메인 연결을 끊기 전에 Cloudflare에서 인증서와 DNS가 Active인지 본다. 양쪽이 동시에 같은 에이펙스를 가리키면 전파 구간에 캐시와 인증서가 엇갈린다. 이 절은 호스팅 이전의 DNS와 SSL 순서만 적는다. 특정 사이트의 내부 컷오버 점검표 전체가 아니다.

DNSSEC와 DS

DNSSEC가 이전 제공자에 켜져 있으면, 네임서버를 바꾸기 전에 등록 기관에서 DNSSEC를 끈다. DS 레코드는 DNS 제공자가 아니라 등록 기관(부모 존)에 산다. 이전 제공자의 DS가 남으면 해석기는 SERVFAIL을 돌려주고, 존은 Pending Nameserver Update에 머물 수 있다. 위임이 끝난 것처럼 보여도 사이트가 안 열리는 이유가 여기 있다. Active가 된 뒤에 Cloudflare에서 DNSSEC를 다시 켠다.

등록 기관 화면의 네임서버와 Overview 할당이 문자 단위로 같은지와, 옛 DS가 남아 있지 않은지가 풀 셋업의 첫 관문이다. 철자가 하나라도 다르면 위임이 실패한다. 예전에 같은 도메인을 지웠다가 다시 넣으면 Cloudflare가 다른 네임서버 쌍을 줄 수 있다. 대시보드에 적힌 현재 할당을 등록 기관에 넣는다. Zone stuck in Pending Nameserver Update 문서가 이 실패를 설명한다.

dig ns 도메인 @1.1.1.1에 Cloudflare 네임서버가 보이면 위임이 잡힌 것이다. 부모 존이 아직 옛 네임서버를 가리키면 등록 기관이 변경을 게시하지 않은 상태다. 위임 확인은 최대 24시간을 기다리는 경우가 많다. Active 메일과 대시보드 상태 Active가 같이 온다. Cloudflare Registrar로 산 도메인은 이미 Cloudflare가 권한 DNS라서 이 위임 절차를 건너뛴다.

스캔이 모든 레코드를 찾는다고 보장하지 않는다. 존 에이펙스, www, 메일 레코드를 특히 다시 본다. 네임서버만 바꾸고 DNS 레코드를 비운 채로 활성화하면 DNS_PROBE_FINISHED_NXDOMAIN이다. 위임은 끝났는데 존이 비어 있는 상태다. www만 있고 @가 없으면 example.com이 NXDOMAIN이다. 반대면 www만 실패한다. Pending과 NXDOMAIN은 다르다. Pending은 부모 존이 아직 Cloudflare를 가리키지 않는 쪽이다.

525와 526

525는 Full 또는 Full (strict)에서 원본과 SSL 핸드셰이크가 실패할 때 난다. 원본에 인증서가 없거나 443이 닫혀 있거나, 암호 스위트가 안 맞거나 SNI가 없는 경우가 원인이다. 526은 Full (strict)에서 원본 인증서를 검증하지 못할 때 난다. 만료, 호스트 불일치, 자체 서명을 Trust Store에 안 넣은 상태가 여기 해당한다. 급한 우회는 Full로 낮추는 것이나, 원인은 원본 인증서를 맞추는 쪽이다.

Flexible는 방문자까지는 HTTPS일 수 있고, 원본에는 HTTP로 붙는다. 원본이 HTTP를 HTTPS로 되돌리면 ERR_TOO_MANY_REDIRECTS 루프가 돈다. Always Use HTTPS와 원본의 HTTPS 강제가 겹쳐도 같다. 원본이 HTTPS를 다시 HTTP로 돌리거나, 리다이렉트 규칙 두 개가 서로를 가리켜도 같은 증상이 난다. Off는 둘 다 평문이다.

Full은 방문자 요청이 HTTPS이면 원본에도 HTTPS로 붙는다. 원본 인증서가 자체 서명이어도 통과하는 경우가 많다. Full (strict)는 원본 인증서가 만료되지 않았고, 공개 CA 또는 Cloudflare Origin CA가 발급했으며, CN 또는 SAN이 호스트와 맞는지를 검사한다. 원본은 443에서 HTTPS를 받아야 한다. Origin CA는 Cloudflare와 원본 사이를 암호화할 때 쓰며, 브라우저용 공개 CA가 아니다. 프록시를 끄거나 Cloudflare를 일시 중지하면 방문자에게 인증서 경고가 난다.

새 존의 기본은 Automatic SSL/TLS인 경우가 늘어 있다. 추천기가 더 안전한 모드로 올리되, 인증서가 만료됐다고 해서 Full (strict)를 더 약한 모드로 내리지는 않는다. 수동 Custom은 Off, Flexible, Full, Full (strict), Strict (SSL-Only Origin Pull)을 직접 고른다. Pages처럼 원본이 Cloudflare 네트워크 안에 있으면 Origin CA를 심는 절차와 결이 다르다. 그래도 존 전체에 Flexible이 켜져 있고 다른 호스트가 HTTPS로 되돌리면 루프는 같은 방식으로 난다.

1033은 네임서버 실수가 아니라, 건강한 cloudflared가 에지에 없는 상태다. cloudflared tunnel list와 대시보드에서 Inactive, Down, Degraded를 가른다. 502이면서 origin에 닿지 않는다는 문구는 터널은 살아 있고 로컬 서비스가 죽은 상태라 1033과 다르다. Pages에서 CNAME만 프로젝트.pages.dev로 수동으로 넣으면 522가 날 수 있다. Custom domains에서 연결한 뒤에 DNS가 잡힌다. CAA가 Let's Encrypt, Google Trust Services, SSL.com 발급을 막으면 Pages 인증서가 안 나온다.

메일 MX와 SPF, DKIM, DMARC TXT는 회색 구름이다. 프록시를 켜면 메일 경로가 깨질 수 있다. 서드파티 검증용 CNAME도 보통 DNS only다. 주황 구름으로 바꾸면 확인 서버가 Cloudflare 에지를 보고 실패한다. 프록시 없이 원본 IP가 바뀌는 호스트는 A 레코드가 금방 낡는다. 동적 DNS나 프록시 뒤의 안정된 호스트명이 필요하다.

방문자 요청이 에지를 지나는 방식

주황 구름이면 방문자가 보는 IP는 Cloudflare 애니캐스트다. 에지가 TLS를 종료하고, 암호화 모드에 따라 원본에 다시 붙는다. Universal SSL과 캐시, DDoS 방어가 이 구간에 붙는다. 원본 IP는 DNS 조회만으로는 바로 안 나온다. 회색 구름이면 Cloudflare는 레코드 값만 돌려주고 트래픽을 프록시하지 않는다. 메일이 회색 구름이어야 하는 이유와, 웹이 주황 구름인 이유가 이 한 토글에 있다.

에이펙스 A나 CNAME은 사이트를 연다. www가 없으면 주소창에 www를 붙인 방문자가 사이트를 못 찾는다. Pages 커스텀 도메인은 대시보드 연결 없이 CNAME만 넣으면 522가 날 수 있다. 에이펙스를 Pages에 붙이려면 같은 계정의 Cloudflare 존과 네임서버 위임이 필요하다. 하위 도메인만이면 외부 DNS에 CNAME을 .pages.dev로 넣는 경로가 있다. 빌드 산출물은 먼저 .pages.dev에 뜬다. Vercel 쪽 도메인 연결을 끊기 전에 Cloudflare에서 인증서와 DNS가 Active인지 본다. 양쪽이 동시에 같은 에이펙스를 가리키면 전파 구간에 캐시와 인증서가 엇갈린다.

Pages 커스텀 도메인을 연결한 뒤 DNS를 다른 원본으로 바꿨다가 다시 Pages로 돌리면, 다시 Active가 될 때까지 에러가 난다. 잠시 트래픽만 돌리려면 DNS를 빼기보다 Origin 규칙이나 리다이렉트 규칙이 덜 위험하다. CAA 레코드가 막으면 Pages 인증서가 안 나온다. Let's Encrypt, Google Trust Services, SSL.com issue 값을 허용 목록에 넣는다.

등록 기관은 도메인을 산 회사다. 네임서버는 그 도메인의 DNS 질문에 누가 답할지를 가리킨다. 두 층이 같다 보면, 등록 기관 화면에서 A 레코드를 고쳤는데 사이트가 안 바뀐다. 권한 DNS가 이미 Cloudflare면 레코드는 Cloudflare DNS에만 있다. ICANN Lookup으로 등록 기관을 찾는다. 할당된 네임서버 두 개는 존 Overview에 있고 임의로 바꾸지 못한다.

HSTS와 Always Use HTTPS는 방문자 HTTP를 HTTPS로 고정한다. Flexible 원본이 HTTP인데 원본이 HTTPS로 되돌리면 루프다. Full (strict)에서 원본 인증서가 만료되면 526이다. 핸드셰이크가 실패하면 525다. 터널이 끊기면 1033이다. 네임서버 철자가 틀리거나 옛 DS가 남으면 SERVFAIL 또는 Pending이다. 레코드가 비면 NXDOMAIN이다. 실패 코드가 가리키는 층이 다르다.

Origin CA와 브라우저

Origin CA는 Cloudflare와 원본 사이를 암호화할 때 쓴다. 브라우저용 공개 CA가 아니다. 프록시를 켠 뒤에 Origin CA만 원본에 두면, 방문자가 원본 IP로 직접 붙을 때 브라우저가 그 인증서를 신뢰하지 않는다. 프록시를 끄거나 Cloudflare를 일시 중지하면 방문자에게 인증서 경고가 난다. Full (strict)는 원본 인증서가 공개 CA 또는 Cloudflare Origin CA가 발급했고, 만료되지 않았고, CN 또는 SAN이 호스트와 맞는지를 검사한다. 원본은 443에서 HTTPS를 받아야 한다.

워커와 커스텀 도메인, 터널(cloudflared)은 별 계층이다. 터널이 끊기면 1033이 난다. 1033은 네임서버 실수가 아니라, 건강한 cloudflared가 에지에 없는 상태다. cloudflared tunnel list와 대시보드에서 Inactive, Down, Degraded를 가른다. 502이면서 origin에 닿지 않는다는 문구는 터널은 살아 있고 로컬 서비스가 죽은 상태라 1033과 다르다.

Flexible 리다이렉트 루프

Flexible는 방문자까지는 HTTPS일 수 있고, 원본에는 HTTP로 붙는다. 원본이 HTTP를 HTTPS로 되돌리면 ERR_TOO_MANY_REDIRECTS가 돈다. Always Use HTTPS와 원본의 HTTPS 강제가 겹쳐도 같다. 원본이 HTTPS를 다시 HTTP로 돌리거나, 리다이렉트 규칙 두 개가 서로를 가리켜도 같은 증상이 난다. Off는 둘 다 평문이다. Full은 방문자 요청이 HTTPS이면 원본에도 HTTPS로 붙는다. 원본 인증서가 자체 서명이어도 통과하는 경우가 많다.

새 존의 기본은 Automatic SSL/TLS인 경우가 늘어 있다. 추천기가 더 안전한 모드로 올리되, 인증서가 만료됐다고 해서 Full (strict)를 더 약한 모드로 내리지는 않는다. 수동 Custom은 Off, Flexible, Full, Full (strict), Strict (SSL-Only Origin Pull)을 직접 고른다. Pages처럼 원본이 Cloudflare 네트워크 안에 있으면 Origin CA를 심는 절차와 결이 다르다. 그래도 존 전체에 Flexible이 켜져 있고 다른 호스트가 HTTPS로 되돌리면 루프는 같은 방식으로 난다.

정적 사이트를 Vercel에서 Cloudflare Pages로 옮기면 빌드 산출물이 *.pages.dev에 먼저 뜬다. 커스텀 도메인은 Pages 프로젝트의 Custom domains에서 붙인다. Vercel 쪽 도메인 연결을 끊기 전에 Cloudflare에서 인증서와 DNS가 Active인지 본다. 양쪽이 동시에 같은 에이펙스를 가리키면 전파 구간에 캐시와 인증서가 엇갈린다.

실패 코드가 가리키는 층

NXDOMAIN은 위임은 됐는데 그 이름에 레코드가 없는 층이다. SERVFAIL과 Pending Nameserver Update는 부모 존의 네임서버나 옛 DS가 틀린 층이다. 522는 Pages Custom domains 연결 없이 CNAME만 넣었을 때 자주 나는 층이다. 525는 Full 또는 Full (strict)에서 원본 SSL 핸드셰이크가 실패한 층이다. 526은 Full (strict)가 원본 인증서를 거부한 층이다. 1033은 건강한 cloudflared가 에지에 없는 층이다. 502이면서 origin에 닿지 않는다는 문구는 터널은 살아 있고 로컬 서비스가 죽은 층이라 1033과 다르다. 코드만 보고 네임서버를 고치면, 525를 NXDOMAIN처럼 다루게 된다.

Pages 커스텀 도메인을 연결한 뒤 DNS를 다른 원본으로 바꿨다가 다시 Pages로 돌리면, 다시 Active가 될 때까지 에러가 난다. 잠시 트래픽만 돌리려면 DNS를 빼기보다 Origin 규칙이나 리다이렉트 규칙이 덜 위험하다. CAA가 Let's Encrypt, Google Trust Services, SSL.com 발급을 막으면 Pages 인증서가 안 나온다. 막는 CAA가 있으면 문서가 적는 issue 값을 허용 목록에 넣는다.

마무리

앞에서 다룬 Cloudflare 커스텀 도메인 연결의 핵심만 짧게 정리한다.

• 풀 셋업은 등록 기관 네임서버를 Cloudflare 할당값으로 바꾸는 일부터 시작한다.
• DNSSEC의 DS는 등록 기관에 남으므로, 이전 전에 끄지 않으면 SERVFAIL이 난다.
• 메일과 서드파티 검증 레코드는 회색 구름이다.
• 주황 구름은 에지가 TLS를 종료하고, Origin CA는 브라우저용이 아니다.
• Full (strict)는 원본 인증서 검증이며, Flexible은 원본 HTTPS 강제와 루프가 난다.
• 525는 핸드셰이크, 526은 원본 인증서, 1033은 터널이다.
• Pages 커스텀 도메인은 대시보드 연결 없이 CNAME만 넣으면 522가 날 수 있다.

「네임서버 위임과 암호화 모드와 프록시 토글은 한 화면의 세 층이다」 레코드 내용만 맞고 위임이나 DS가 틀리면 사이트는 열리지 않는다.

출처와 링크

• Set up a primary zone (Full setup): https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/
• Zone stuck in Pending Nameserver Update: https://developers.cloudflare.com/dns/zone-setups/troubleshooting/pending-nameservers/
• Encryption modes: https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/
• Full (strict): https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/
• Cloudflare origin CA: https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/
• ERR_TOO_MANY_REDIRECTS: https://developers.cloudflare.com/ssl/troubleshooting/too-many-redirects/
• Error 525: https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-525/
• Error 526: https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-526/
• Pages custom domains: https://developers.cloudflare.com/pages/configuration/custom-domains/
• Error 1033: https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1033/

조사 기준: 2026년 8월. 네임서버 할당, SSL 모드 이름, Pages 연결 절차는 대시보드 갱신에 따라 달라질 수 있다.