심층 학습 가이드
Cloudflare 도메인 연결 완벽 가이드
심층 학습 가이드

Cloudflare 도메인 연결 완벽 가이드

Cloudflare 자체 구매 · 타사 도메인 네임서버 연결 · 도메인 완전 이전까지 — DNS 원리, SSL/TLS 4모드, 프록시 상태, 등록기관별 NS 변경, 트러블슈팅을 논문 수준으로 정리한 교재형 레퍼런스

학습 유형
논문형 심층 레퍼런스
핵심 주제
Cloudflare 도메인 연결 3가지 방법
완료 목표
HTTPS + DNS + 메일 + CDN 정상 운영
난이도
입문 → 중급
예상 학습 시간
60 – 90분 (전체 정독 기준)
준비물
도메인 1개 + 호스팅 서버 + 등록기관 로그인 정보

1장. 서론 — Cloudflare는 무엇이고, 왜 쓰는가

Cloudflare의 이중 역할

Cloudflare 도메인 연결 3가지 방법

이미지 설명: Cloudflare 도메인 연결은 직접 구매, 네임서버 변경, 도메인 이전 세 경로로 나뉩니다. Cloudflare는 전 세계 330개 이상의 데이터센터를 운영하는 글로벌 네트워크 인프라 기업입니다. 웹사이트에 대해 크게 두 가지 역할을 수행합니다.

첫째, DNS 제공자(DNS Provider) 로서 도메인 이름을 IP 주소로 변환하는 권한 있는 네임서버를 운영합니다. 둘째, 리버스 프록시(Reverse Proxy) 로서 사용자와 원본 서버 사이에 위치하여 트래픽을 중계하면서 CDN 캐싱, DDoS 방어, WAF(Web Application Firewall), SSL 종료 등 보안·성능 기능을 적용합니다.

도메인을 Cloudflare에 "연결한다"는 것은 이 두 가지 역할 중 하나 또는 둘 다를 활성화하는 것을 의미합니다.

무료 플랜(Free Plan)만으로 받는 혜택

Cloudflare의 Free 플랜은 비용 없이 다음 기능을 제공합니다.

글로벌 CDN을 통한 정적 콘텐츠 캐싱 및 가속, 무료 SSL/TLS 인증서(Universal SSL) 자동 발급, 기본 DDoS 공격 방어(L3/L4/L7), 무제한 DNS 호스팅(쿼리 수 제한 없음), 기본적인 웹 분석(Analytics), 그리고 Page Rules를 통한 URL 패턴별 트래픽 제어가 포함됩니다. Pro($20/월), Business($200/월), Enterprise(맞춤 가격)로 업그레이드하면 고급 WAF 커스텀 룰셋, 봇 관리, 이미지·모바일 최적화, 100% SLA 등을 추가로 이용할 수 있지만, 대부분의 개인·소규모 서비스는 Free 플랜으로도 충분합니다.

Cloudflare Registrar의 차별점

Cloudflare Registrar는 도메인 등록 서비스를 도매가(at-cost) 에 제공합니다. 즉, Cloudflare 자체의 마크업이 전혀 없고, ICANN 수수료와 레지스트리 비용만 청구합니다. .com 도메인 기준 연간 약 $10.11(ICANN $0.18 포함) 수준이며, 결정적으로 갱신 비용도 동일합니다. 타사 등록기관에서 흔히 보이는 "첫 해 990원 → 갱신 시 22,000원"과 같은 가격 점프가 없습니다.

추가로 WHOIS 개인정보 보호가 기본 무료 적용되며, DNSSEC 원클릭 활성화를 지원합니다. 348개 이상의 TLD를 지원하지만, IDN(국제화 도메인, 유니코드)과 프리미엄 도메인은 현재 미지원입니다.

세 가지 연결 방법 개관

도메인을 Cloudflare에 연결하는 방법은 크게 세 가지입니다.

방법 A — Cloudflare에서 직접 도메인을 구매합니다. 등록과 동시에 DNS·CDN·보안이 자동 활성화되므로 가장 간단합니다. 방법 B — 타사(Iteasy, 가비아, 호스팅케이알 등)에서 구매한 도메인의 네임서버만 Cloudflare로 변경합니다. 등록기관은 유지하되 DNS 관리·보안·CDN 기능을 Cloudflare에 위임하는, 가장 보편적인 방식입니다. 방법 C — 타사 도메인의 등록 자체를 Cloudflare Registrar로 이전(Transfer)합니다. 장기 운영 시 비용 절감과 관리 일원화가 장점이지만, 절차가 가장 복잡합니다.

이하 각 장에서 세 가지 방법을 상세히 다루며, 이후 DNS 레코드, SSL, 프록시 설정을 공통 주제로 정리합니다.


2장. 핵심 개념 — DNS · 네임서버 · 프록시 · CNAME Flattening

DNS(Domain Name System)의 작동 원리

네임서버 변경과 DNS 질의 흐름

이미지 설명: 네임서버를 Cloudflare로 바꾸면 권한 있는 DNS 응답 위치가 바뀌고 트래픽 관리가 시작됩니다. DNS는 인터넷의 전화번호부입니다. 사용자가 브라우저에 www.example.com을 입력하면, DNS 시스템이 이 문자열을 서버의 실제 IP 주소(예: 192.0.2.1)로 변환합니다. 이 과정은 계층적 질의 구조로 이루어집니다.

사용자의 DNS 리졸버(보통 ISP나 1.1.1.1, 8.8.8.8 같은 퍼블릭 리졸버)가 루트 네임서버(Root NS)에 질의하면, 루트 NS는 .com TLD 네임서버를 안내합니다. TLD NS는 다시 example.com의 권한 있는 네임서버(Authoritative NS)를 안내하고, 이 권한 NS가 최종 IP 주소를 응답합니다. Cloudflare에 도메인을 연결한다는 것은, 이 마지막 단계의 "권한 있는 네임서버"를 Cloudflare 서버로 바꾸는 것입니다.

네임서버(Nameserver)란

네임서버는 특정 도메인의 DNS 레코드를 저장하고 외부 질의에 응답하는 전문 서버입니다. 도메인을 등록하면 기본적으로 등록기관의 네임서버가 지정되지만, 이를 Cloudflare의 네임서버(예: alice.ns.cloudflare.com, bob.ns.cloudflare.com)로 변경하면 해당 도메인에 대한 모든 DNS 질의를 Cloudflare가 처리합니다. 이것이 Cloudflare의 Full Setup(전체 설정) 의 핵심이며, 방법 B와 방법 C 모두 이 과정을 포함합니다.

각 도메인마다 Cloudflare가 할당하는 네임서버 이름이 다를 수 있으므로, 대시보드에 표시된 값을 정확히 복사해야 합니다.

주요 DNS 레코드 유형 요약

A 레코드 — 도메인을 IPv4 주소에 매핑합니다. 예: example.com → 192.0.2.1

AAAA 레코드 — A 레코드의 IPv6 버전입니다. 예: example.com → 2001:db8::1

CNAME 레코드 — 도메인을 다른 도메인으로 매핑하는 별칭(alias)입니다. 예: www.example.com → example.com. CNAME은 항상 다른 도메인을 가리켜야 하며, IP를 직접 지정할 수 없습니다.

MX 레코드 — 이메일 수신을 위한 메일 서버를 지정합니다. 우선순위(priority) 값을 포함합니다.

TXT 레코드 — 도메인 소유권 검증, SPF, DKIM, DMARC 등 텍스트 기반 정보를 저장합니다.

NS 레코드 — 도메인의 권한 있는 네임서버를 지정합니다.

프록시(Proxy)의 개념

Cloudflare의 프록시 기능은 사용자의 HTTP/HTTPS 요청이 원본 서버에 직접 도달하지 않고, Cloudflare 네트워크를 경유하도록 만듭니다. 프록시가 활성화되면 도메인의 실제 서버 IP가 숨겨지고 Cloudflare의 Anycast IP가 대신 노출됩니다. 이를 통해 CDN 캐싱, DDoS 방어, SSL 종료, WAF, HTTP/2·HTTP/3, Brotli 압축 등이 자동 적용됩니다.

프록시는 A, AAAA, CNAME 레코드에만 적용할 수 있습니다. MX, TXT, SRV 등은 프록시 대상이 아닙니다.

CNAME Flattening

일반 DNS 표준(RFC)에서는 Zone Apex(루트 도메인, 예: example.com)에 CNAME 레코드를 설정할 수 없습니다. CNAME은 해당 이름에 다른 레코드가 공존할 수 없는데, 루트 도메인에는 SOA, NS 레코드가 반드시 존재하기 때문입니다.

Cloudflare는 CNAME Flattening 기술로 이 제한을 우회합니다. 루트 도메인에 CNAME을 설정하면, Cloudflare가 내부적으로 해당 CNAME 대상을 재귀적으로 해석하여 최종 IP 주소를 A/AAAA 레코드 형태로 응답합니다. DNS 표준을 위반하지 않으면서도 루트 도메인을 Netlify, Vercel, Cloudflare Pages 등 외부 플랫폼의 도메인으로 연결할 수 있어 매우 유용합니다.


3장. 방법 A — Cloudflare에서 직접 도메인 구매

이 방법을 선택하는 상황

신규 도메인이 필요하고, Cloudflare 생태계(Pages, Workers, R2 등)를 적극 활용할 계획이며, 도매가 갱신 혜택을 원할 때 최적입니다. 등록과 동시에 DNS·CDN·SSL이 즉시 활성화되므로 추가 설정이 최소화됩니다.

단, Cloudflare Registrar에 등록된 도메인의 네임서버는 Cloudflare NS로만 고정됩니다. 외부 네임서버로 변경이 불가능하며, 변경하려면 도메인을 다른 등록기관으로 이전해야 합니다. 또한 .kr 등 일부 ccTLD는 Cloudflare Registrar에서 구매가 불가하므로, 한국 도메인이 필요하면 방법 B를 사용해야 합니다.

지원 TLD

Cloudflare Registrar는 .com, .net, .org, .io, .dev, .app, .co, .me, .xyz, .ai 등 348개 이상의 TLD를 지원합니다. 전체 목록은 Cloudflare TLD 정책 페이지에서 확인할 수 있습니다. IDN(유니코드 도메인)과 프리미엄 도메인은 미지원입니다.

단계별 구매 절차

Step 1 — Cloudflare 계정 생성 및 로그인

Cloudflare 대시보드에 접속합니다. 계정이 없으면 이메일 또는 Google 계정으로 가입합니다. 이메일 인증을 반드시 완료해야 도메인 등록이 가능합니다.

Step 2 — 도메인 검색

대시보드 좌측 메뉴에서 Domain Registration → Register Domains를 클릭합니다. 검색창에 원하는 도메인 이름(예: mysite)을 입력하고 Search를 클릭합니다. 검색 결과에 등록 가능한 도메인 목록과 TLD별 연간 가격이 표시됩니다. 원하는 도메인이 목록에 없으면 이미 등록된 것입니다.

Step 3 — 구매 및 기간 선택

원하는 도메인 옆 Purchase 버튼을 클릭합니다. Payment option 드롭다운에서 등록 기간(1년 ~ 최대 10년)을 선택합니다. 만료일과 가격이 자동 업데이트됩니다. 기본적으로 자동 갱신(Auto-renew)이 켜져 있으며, 등록 후 언제든 해제할 수 있습니다.

Step 4 — 연락처 정보 입력

Registrant, Admin, Technical, Billing 연락처를 입력합니다. 현재 ASCII 문자만 지원하므로 한글이 아닌 영문으로 작성합니다. 필수 항목은 First/Last Name(각 2글자 이상), 이메일, 전화번호(국가코드 선택 + 숫자), 주소, 도시, 주/도, 국가, 우편번호입니다. Cloudflare는 WHOIS에서 이 정보를 기본적으로 자동 비공개(redaction) 처리합니다.

Step 5 — 결제 및 완료

결제 방법(신용카드 또는 PayPal)을 입력합니다. 기존 결제 프로필이 있으면 자동 입력됩니다. Domain Registration Agreement, Self-serve Subscription Agreement, Privacy Policy를 검토한 뒤 Complete purchase를 클릭합니다. 등록 완료까지 약 30초 소요되며, 완료 후 도메인 관리 페이지로 이동합니다. 확인 이메일이 발송됩니다.

구매 직후 필수 설정

도메인 구매만으로는 웹사이트가 연결되지 않습니다. Cloudflare DNS 관리 페이지에서 다음 레코드를 추가해야 합니다.

웹사이트용 A 레코드(Name: @, Content: 서버 IPv4) 또는 AAAA 레코드(IPv6), www 서브도메인용 CNAME 레코드(Name: www, Target: example.com), 이메일 사용 시 MX 레코드TXT 레코드(SPF/DKIM/DMARC)를 설정합니다. SSL/TLS 암호화 모드는 Full (Strict) 를 선택합니다. 상세 설정 방법은 6장과 7장에서 다룹니다.


4장. 방법 B — 타사 도메인을 Cloudflare에 연결 (네임서버 변경)

이 방법을 선택하는 상황

이미 Iteasy, 가비아, 호스팅케이알, Cafe24, Namecheap, GoDaddy 등에서 도메인을 보유하고 있고, 등록기관을 바꾸지 않으면서 Cloudflare의 CDN·DNS·보안 기능을 활용하고 싶을 때 선택합니다. 가장 보편적이고 위험 부담이 적은 방법입니다.

.kr 등 Cloudflare Registrar에서 구매·이전이 불가한 TLD도 이 방법으로 연결할 수 있습니다.

장단점

장점은 등록기관 변경 불필요(기존 계약·결제 유지), Cloudflare 미지원 TLD도 연결 가능, 무료 플랜으로 CDN·SSL·DDoS 방어 즉시 적용, 롤백이 쉬움(NS를 원래대로 변경하면 복구) 등입니다.

단점은 도메인 갱신·소유권 관리는 원래 등록기관에서 별도로 해야 하며, NS 전파에 최대 24~48시간 소요될 수 있고, 기존 등록기관의 DNS 부가서비스(Iteasy 웹 DNS, 가비아 DNS 관리 등)가 비활성화된다는 점입니다.

단계별 연결 절차

Step 1 — Cloudflare 대시보드 로그인

https://dash.cloudflare.com에서 로그인합니다.

Step 2 — 도메인 추가(Onboard)

대시보드에서 Domains 페이지로 이동 → "Onboard a domain" 클릭 → 보유한 도메인의 Apex 도메인(예: example.com, 서브도메인 아님)을 입력 → DNS 레코드 추가 방식 선택 → Continue 클릭합니다.

Step 3 — 플랜 선택

Free(무료) / Pro($20/월) / Business($200/월) / Enterprise(맞춤) 중 선택합니다. 개인·소규모는 Free로 충분합니다.

Step 4 — DNS 레코드 검토 (가장 중요한 단계)

Cloudflare가 기존 DNS 설정을 자동 스캔하여 발견된 레코드를 표시합니다. 이 자동 스캔은 100% 완벽하지 않습니다. 반드시 기존 등록기관/DNS 호스트의 레코드 목록과 대조하여 누락 여부를 확인해야 합니다.

특히 다음 세 가지를 반드시 확인합니다.

첫째, Zone Apex 레코드example.com에 대한 A 또는 AAAA 레코드가 올바른 서버 IP를 가리키는지 확인합니다. 둘째, 서브도메인 레코드 — 최소한 www에 대한 레코드가 있는지, 기타 사용 중인 서브도메인(blog, api, mail 등)이 모두 포함되었는지 확인합니다. 셋째, 이메일 레코드 — MX, SPF(TXT), DKIM(TXT), DMARC(TXT) 레코드가 빠짐없이 존재하는지 확인합니다.

하나라도 누락되면 네임서버 변경 후 해당 서비스가 즉시 중단됩니다. 누락 레코드는 Add Record 버튼으로 수동 추가합니다.

Step 5 — Cloudflare 네임서버 확인

검토 완료 후 Cloudflare가 해당 도메인에 할당한 두 개의 네임서버 주소를 표시합니다. 예시:

alice.ns.cloudflare.com
bob.ns.cloudflare.com

이 값을 정확히 복사합니다. 도메인마다 할당되는 NS 이름이 다를 수 있으므로, 화면에 표시된 정확한 값을 사용해야 합니다.

Step 6 — 등록기관에서 네임서버 변경

기존 도메인 등록기관의 관리 페이지에 로그인하여, 기존 네임서버를 삭제하고 Cloudflare NS 두 개를 입력합니다. 등록기관별 구체적 절차는 9장에서 다룹니다.

Step 7 — Active 전환 대기

네임서버 변경 후 Cloudflare 대시보드로 돌아오면 도메인 상태가 "Pending" 으로 표시됩니다. DNS 전파에는 보통 수 분 ~ 최대 24시간이 소요됩니다. 활성화 완료 시 Cloudflare가 이메일을 발송하며, 상태가 "Active" 로 변경됩니다.

24시간 이상 Pending이면 NS가 올바르게 변경되었는지, DNSSEC가 비활성화되어 있는지 확인합니다.

Step 8 — 후속 설정

Active 전환 후 SSL/TLS 모드(7장), 프록시 상태(8장), Always Use HTTPS, HSTS 등을 설정합니다.


5장. 방법 C — 타사 도메인을 Cloudflare로 완전 이전 (Transfer)

이 방법을 선택하는 상황

도메인의 등록(소유) 자체를 기존 등록기관에서 Cloudflare Registrar로 옮기는 방법입니다. 이전 완료 후에는 도메인 등록, 갱신, DNS 관리가 모두 Cloudflare에서 이루어집니다. 장기 운영 시 도매가 갱신으로 비용을 절감하고, 여러 도메인을 한 곳에서 통합 관리할 수 있습니다.

이전 전 자격 요건 (ICANN 규정)

다음 조건을 모두 충족해야 이전이 가능합니다.

도메인이 최초 등록 후 60일 이상 경과해야 합니다. 최근 60일 이내에 다른 등록기관으로 이전한 적이 없어야 합니다. 최근 60일 이내에 WHOIS 등록자 이름, 조직명, 이메일을 변경하지 않았어야 합니다(일부 등록기관은 변경 시 60일 이전 잠금을 자동 적용합니다). 도메인이 만료되지 않았으며 등록기관 계정이 활성 상태여야 합니다. Cloudflare가 해당 TLD를 지원해야 합니다. 프리미엄 도메인 또는 IDN은 이전 불가합니다.

이전 비용

Cloudflare는 별도 이전 수수료를 부과하지 않습니다. 대부분의 gTLD(.com, .net, .org 등) 이전 시 현재 만료일로부터 1년 연장 비용이 자동 포함됩니다(ICANN 요구사항). 이 연장 비용도 도매가가 적용됩니다. 일부 ccTLD(예: .uk)는 이전 수수료와 연장 비용 모두 없습니다.

단계별 이전 절차

사전 준비 — 반드시 이전 시작 전에 완료

기존 등록기관의 로그인 정보를 확인합니다. 현재 DNS 설정 전체를 스크린샷 또는 스프레드시트로 백업합니다. WHOIS 개인정보 보호가 활성화된 경우, 일부 등록기관에서는 이를 비활성화해야 이전이 가능합니다(대부분은 그대로 진행 가능). DNSSEC가 활성화되어 있다면 반드시 비활성화합니다. DNSSEC는 네임서버와 연결된 암호화 서명(DS 레코드)을 사용하므로, NS가 변경되면 서명 불일치로 DNS 해석이 완전히 실패합니다. 비활성화 후 최소 24시간 전파를 기다려야 안전합니다.

Step 1 — Cloudflare에 도메인 추가 및 NS 변경

방법 B(4장)의 절차와 동일합니다. Cloudflare에 도메인을 추가하고, 기존 등록기관에서 NS를 Cloudflare로 변경합니다. 도메인 상태가 "Active" 가 될 때까지 기다립니다. Active가 되지 않으면 이전을 진행할 수 없습니다.

Step 2 — 기존 등록기관에서 도메인 잠금 해제

대부분의 등록기관은 무단 이전 방지를 위해 기본적으로 도메인 잠금(Registrar Lock / Transfer Lock) 을 적용합니다. WHOIS에서 clientTransferProhibited 상태로 표시됩니다. 기존 등록기관의 도메인 관리 페이지에서 이 잠금을 해제합니다.

Step 3 — 인증 코드(Auth Code / EPP Code) 요청

기존 등록기관에서 도메인 이전용 인증 코드를 발급받습니다. EPP 코드, Auth-Info 코드, 승인 코드, Transfer Code 등으로도 불립니다. 인증 코드는 유효 기간이 제한되어 있으므로, 이전을 실행할 준비가 되었을 때 발급받습니다. 보통 등록기관의 도메인 관리 > 이전(Transfer) 메뉴에서 발급하거나, 고객지원에 요청합니다.

Step 4 — Cloudflare에서 이전 시작

대시보드에서 Domain Registration → Transfer Domains 페이지로 이동합니다. 이전 가능한 도메인 목록에서 대상 도메인을 선택합니다. 이전 가격(1년 연장 비용 포함)을 확인하고, 발급받은 인증 코드를 입력합니다. 결제 방법이 등록되어 있지 않으면 이 단계에서 추가합니다.

Step 5 — 연락처 정보 확인 및 이전 확정

등록 연락처 정보를 입력하거나 확인합니다. ICANN 규정상 정확한 정보를 제공해야 하며, 부정확한 정보는 도메인 정지 사유가 될 수 있습니다. Confirm transfer를 클릭하여 이전을 확정합니다.

Step 6 — 양측 승인 및 완료 대기

Cloudflare가 이전 요청을 시작하고, 등록자에게 승인 양식(FOA) 이메일을 발송합니다. 기존 등록기관에서도 이전 확인 이메일이 옵니다. 이메일의 승인 링크를 클릭하면 즉시 처리되고, 아무 조치도 하지 않으면 최대 5일 후 자동으로 이전됩니다(일부 TLD는 최대 10일). 대시보드의 Transfer Domains 페이지에서 실시간 상태를 확인할 수 있습니다.

이전 상태는 "Transfer in progress"(요청 제출됨) → "Pending approval"(기존 등록기관 검토 중) → 완료 순으로 변경됩니다. "Transfer rejected" 가 표시되면 잠금 해제 여부, 인증 코드, 자격 요건을 다시 확인한 뒤 Retry를 클릭합니다.

Step 7 — 이전 후 확인

이전 완료 후 웹사이트 접속, 이메일 수신, SSL 인증서 상태를 반드시 테스트합니다. DNSSEC가 필요하면 Cloudflare 대시보드에서 원클릭으로 재활성화합니다.

웹사이트 빌더 도메인의 특수 사례

Shopify, Wix, Squarespace 등이 도메인 등록기관 역할도 겸하는 경우, 해당 플랫폼에서 네임서버 변경을 허용하지 않는 경우가 많습니다. Cloudflare는 이전 전에 NS가 Cloudflare를 가리켜야 하므로 직접 이전이 불가합니다.

해결 방법은 2단계 이전입니다. 먼저 해당 플랫폼에서 Namecheap 등 일반 등록기관으로 이전한 뒤, 60일 대기 후 Cloudflare로 이전합니다. 중간 등록기관에서 NS를 Cloudflare로 변경하면 대기 기간 동안에도 Cloudflare의 CDN/보안 기능을 즉시 사용할 수 있습니다.


6장. DNS 레코드 설정 상세 가이드

A 레코드 — 루트 도메인을 서버에 연결

DNS 레코드와 서비스 라우팅 지도

이미지 설명: A, CNAME, MX, TXT 레코드가 각각 웹, 별칭, 이메일, 검증 정보를 담당하는 구조입니다. Cloudflare 대시보드 → 해당 도메인 → DNS → Records → Add Record 클릭

필드
TypeA
Name@ (루트 도메인)
IPv4 address호스팅 서버 IP (예: 203.0.113.50)
Proxy statusProxied (주황색 구름)
TTLAuto

서버가 여러 개인 경우, 동일한 Name(@)에 여러 A 레코드를 추가하면 DNS 라운드로빈 로드밸런싱이 적용됩니다.

AAAA 레코드 — IPv6 지원

A 레코드와 동일하되 Type을 AAAA로, 주소에 IPv6를 입력합니다. A와 AAAA를 함께 설정하면 IPv4/IPv6 듀얼스택을 지원하여 접근성이 향상됩니다.

CNAME 레코드 — 별칭 연결

가장 흔한 사용 사례는 www 서브도메인을 루트 도메인으로 연결하는 것입니다.

필드
TypeCNAME
Namewww
Targetexample.com
Proxy statusProxied

플랫폼별 CNAME 대상 예시:

Cloudflare Pages — 프로젝트의 Custom Domains 설정에서 자동 구성됩니다. Netlify — apex-loadbalancer.netlify.com(루트) 또는 your-site.netlify.app(www). Vercel — cname.vercel-dns.com 또는 A 레코드에 76.76.21.21. GitHub Pages — your-username.github.io.

루트 도메인에 CNAME을 설정해야 하는 경우(플랫폼이 IP 대신 도메인을 제공하는 경우), Cloudflare의 CNAME Flattening이 자동으로 처리합니다.

MX 레코드 — 이메일 수신

필드값 (Google Workspace 예시)
TypeMX
Name@
Mail serveraspmx.l.google.com
Priority1
TTLAuto

우선순위가 다른 백업 MX도 추가합니다(예: alt1.aspmx.l.google.com, Priority 5). MX 레코드는 프록시 불가이며 항상 DNS only 상태입니다.

TXT 레코드 — SPF, DKIM, DMARC

SPF — 어떤 서버/서비스가 내 도메인으로 메일을 보낼 수 있는지 선언합니다.

TypeNameContent
TXT@"v=spf1 include:_spf.google.com ~all"

DKIM — 이메일의 암호화 서명을 검증합니다. 이메일 서비스 제공업체가 제공하는 선택기(selector)와 키 값을 TXT로 추가합니다.

TypeNameContent
TXTgoogle._domainkey"v=DKIM1; k=rsa; p=MIIBIj..."

DMARC — SPF와 DKIM 검증 실패 시 수신 서버의 처리 방침을 지정합니다.

TypeNameContent
TXT_dmarc"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

이메일을 전혀 사용하지 않는 도메인에도 스푸핑 방지를 위해 제한적 레코드를 설정하는 것이 권장됩니다. SPF에 "v=spf1 -all", DMARC에 "v=DMARC1; p=reject"를 설정하면, 해당 도메인에서 발송되는 모든 이메일을 거부하도록 수신 서버에 지시합니다.

레코드별 프록시 권장 상태 요약

레코드용도권장 프록시 상태
A / AAAA (웹)사이트 접속Proxied (주황색)
CNAME (www)별칭/호스팅 연결Proxied (주황색)
A (mail)메일 서버DNS only (회색)
MX메일 수신DNS only (자동)
TXT (SPF/DKIM/DMARC)메일 인증DNS only (자동)
SRV특수 서비스DNS only (자동)

7장. SSL/TLS 인증서 설정

네 가지 암호화 모드 상세 비교

SSL 모드와 프록시 상태 비교표

이미지 설명: 웹 트래픽은 주황색 프록시, 메일과 비HTTP 서비스는 DNS Only로 분리해야 장애를 줄일 수 있습니다. Cloudflare 대시보드 → 해당 도메인 → SSL/TLS → Overview에서 설정합니다.

모드방문자 ↔ CFCF ↔ 원본원본 인증서 검증권장도
OffHTTPHTTP❌ 절대 비권장
FlexibleHTTPSHTTP❌ 비권장 (루프 위험)
FullHTTPSHTTPS안 함 (자체서명 OK)△ 조건부 사용
Full (Strict)HTTPSHTTPS (유효 CA 필요)✅ 항상 권장

Flexible 모드를 사용하면 안 되는 이유: 원본 서버가 HTTP → HTTPS 리다이렉트를 강제하는 경우(대부분의 현대 서버 설정), Cloudflare는 원본에 HTTP로 연결 → 원본이 HTTPS로 리다이렉트 → Cloudflare가 다시 HTTP로 연결 → 무한 반복(ERR_TOO_MANY_REDIRECTS)이 발생합니다.

원본 서버에 SSL이 없는 경우: Origin CA 인증서

원본 서버에 Let's Encrypt 등의 공인 인증서가 없어서 Full (Strict)를 사용할 수 없다면, Cloudflare의 Origin CA 인증서를 무료로 발급받아 서버에 설치합니다.

SSL/TLS → Origin Server → Create Certificate에서 RSA 또는 ECC 키 타입을 선택하고, 적용할 호스트네임을 지정한 뒤 발급합니다. 유효 기간은 최대 15년까지 설정 가능합니다. 이 인증서는 Cloudflare 프록시를 통한 연결에서만 유효하며(Cloudflare가 CA로서 서명), 브라우저가 직접 원본에 접속하면 신뢰하지 않습니다. 따라서 프록시 활성화 상태에서만 사용해야 합니다.

Universal SSL

Cloudflare에 도메인을 추가하고 Active 상태가 되면, Universal SSL 인증서가 자동으로 발급됩니다. 이 인증서는 방문자 ↔ Cloudflare 에지 서버 구간의 HTTPS를 담당합니다. 별도 비용 없이 무료이며, 루트 도메인과 와일드카드 1단계 서브도메인(*.example.com)을 커버합니다. 발급에는 네임서버 변경 후 최대 24시간이 소요될 수 있습니다.

Always Use HTTPS & HSTS

Always Use HTTPSSSL/TLS → Edge Certificates에서 토글을 켜면, 모든 HTTP 요청이 자동으로 HTTPS로 301 리다이렉트됩니다.

HSTS(HTTP Strict Transport Security) — 같은 페이지에서 설정합니다. 브라우저에게 "이 도메인은 앞으로 지정 기간 동안 반드시 HTTPS로만 접속하라"고 지시하는 응답 헤더를 추가합니다. max-age, includeSubDomains, preload 옵션을 설정할 수 있습니다. HSTS를 활성화하면 HTTPS를 해제하기 어려워지므로, SSL 설정이 안정적으로 동작하는 것을 확인한 뒤 활성화하세요.


8장. 프록시 상태 — Orange Cloud vs Gray Cloud

Proxied (주황색 구름) — 언제 사용하는가

DNS 레코드의 프록시 토글을 Proxied로 설정하면 주황색 구름 아이콘이 표시됩니다. 해당 레코드에 대한 모든 HTTP/HTTPS 트래픽이 Cloudflare 네트워크를 경유합니다.

이를 통해 적용되는 기능: 원본 서버 IP 숨김(DDoS 직접 공격 방지), CDN 캐싱(전 세계 에지에서 정적 자산 제공), DDoS L3/L4/L7 방어, WAF 규칙 적용, SSL/TLS 종료, HTTP/2·HTTP/3·Brotli 압축 자동 적용, 실시간 분석(Analytics).

웹사이트용 A, AAAA, CNAME 레코드는 원칙적으로 Proxied로 설정합니다.

DNS Only (회색 구름) — 언제 사용하는가

프록시를 DNS Only로 설정하면 회색 구름이 표시됩니다. Cloudflare는 DNS 응답만 제공하고 트래픽을 프록시하지 않습니다. 원본 서버의 실제 IP가 DNS 질의에 그대로 노출됩니다.

다음 경우에 DNS Only를 사용합니다: 이메일 서버(MX가 가리키는 mail A 레코드 등) — 프록시를 켜면 SMTP 트래픽이 차단됩니다. FTP, SSH, 게임 서버 등 비HTTP 프로토콜. 외부 서비스의 도메인 소유권 검증용 CNAME. 다른 CDN과 병행 사용하는 경우(프록시 충돌 방지).

MX, TXT, SRV 등은 프록시 설정 자체가 불가능하며 항상 DNS Only로 동작합니다.

한 줄 원칙

"웹은 주황, 메일/비HTTP는 회색" — 이 원칙만 지켜도 Cloudflare 관련 장애의 80% 이상을 예방할 수 있습니다.

9장. 등록기관별 네임서버 변경 실전 가이드

모든 등록기관의 공통 흐름은 동일합니다: (1) 도메인 관리 페이지 진입 → (2) 네임서버 설정 메뉴 찾기 → (3) 기존 NS 삭제 → (4) Cloudflare NS 2개 입력 → (5) 저장 후 전파 대기.

Iteasy (아이티이지)

https://iteasy.co.kr 로그인 → 마이페이지도메인 → 보유도메인 목록에서 대상 도메인 체크 → 네임서버 변경 클릭 → 기존 NS(ns1.ksdom.kr, ns2.ksdom.kr)를 삭제하고 Cloudflare NS 2개 입력 → 저장.

유의사항: Iteasy의 웹 DNS 부가서비스를 사용 중이었다면, NS 변경 시 해당 서비스가 자동 비활성화됩니다. 이후 DNS 레코드 관리는 모두 Cloudflare 대시보드에서 수행합니다.

가비아 (Gabia)

https://gabia.com 로그인 → 우측 상단 My가비아서비스 관리도메인 통합 관리툴 클릭 → 도메인 정보 변경네임서버 탭 → 대상 도메인 선택 → 1차·2차 NS에 Cloudflare 값 입력 → 저장.

가비아는 1차 ~ 4차까지 NS를 입력할 수 있지만, Cloudflare는 2개만 제공하므로 1차·2차만 입력하고 나머지는 비워둡니다.

호스팅케이알 (HostingKR)

https://hosting.kr 로그인 → 도메인 관리 → 대상 도메인 클릭 → 네임서버 정보 섹션에서 변경 → Cloudflare NS 입력 → 저장.

.kr 도메인도 동일한 절차로 NS를 변경할 수 있습니다.

Cafe24

로그인 → 나의서비스관리도메인관리네임서버 변경"직접입력" 선택 → Cloudflare NS 입력 → 저장.

Cafe24 호스팅을 계속 사용하면서 Cloudflare를 CDN/보안 용도로만 추가하는 경우, Cloudflare DNS에서 A 레코드가 Cafe24 호스팅 서버의 IP를 가리키도록 설정해야 합니다. Cafe24 호스팅 관리 페이지에서 서버 IP를 확인할 수 있습니다.

Namecheap

로그인 → Domain List → 대상 도메인의 ManageNameservers 섹션 → 드롭다운을 "Custom DNS" 로 변경 → Cloudflare NS 입력 → 체크 아이콘 클릭.

GoDaddy

로그인 → My Products → 도메인 옆 DNS 클릭 → NameserversChange"I'll use my own nameservers" 선택 → Cloudflare NS 입력 → Save.

AWS Route 53

AWS 콘솔 → Route 53Registered Domains → 도메인 선택 → Actions"Edit Name Servers" → 기존 NS를 Cloudflare NS로 교체 → Save.

Route 53에서 Hosted Zone을 사용하고 있었다면, Cloudflare로 NS를 변경한 후에는 해당 Hosted Zone의 레코드가 더 이상 사용되지 않습니다. 모든 레코드 관리가 Cloudflare DNS로 이관됩니다.

Porkbun

로그인 → Domain Management → 대상 도메인 → Authoritative NameserversEdit → Cloudflare NS 입력 → Save.

공통 주의사항

NS 변경 전에 기존 DNS 레코드를 반드시 Cloudflare에 먼저 구성해야 합니다. NS가 변경되는 순간부터 DNS 질의가 Cloudflare로 향하므로, 레코드가 없으면 서비스가 즉시 중단됩니다. NS 변경 후에는 기존 등록기관의 DNS 관리 기능(레코드 추가/수정)이 더 이상 동작하지 않습니다. 전파에는 보통 수 분 ~ 최대 48시간이 걸리며, 이 기간 동안 일부 사용자는 구 NS, 일부는 신 NS로 응답을 받을 수 있습니다.


10장. 트러블슈팅 & 주의사항

도메인이 Pending 상태에서 멈춤

Cloudflare 도메인 문제 해결 체크리스트

이미지 설명: Pending, NXDOMAIN, redirect loop, 이메일 중단, 522 오류를 원인별로 빠르게 분류하는 점검표입니다. 증상: Cloudflare에 도메인을 추가하고 NS를 변경했는데 24시간 이상 "Pending Nameserver Update" 상태가 지속됩니다.

원인 및 해결:

첫째, NS가 실제로 변경되었는지 확인합니다. 터미널에서 dig NS example.com +short 또는 nslookup -type=NS example.com 명령으로 현재 NS를 조회합니다. Cloudflare NS가 응답에 포함되지 않으면, 등록기관에서 변경이 제대로 저장되지 않은 것입니다.

둘째, DNSSEC가 비활성화되어 있는지 확인합니다. DNSSEC가 활성화된 상태에서 NS를 변경하면, DS 레코드와 새 NS의 서명이 불일치하여 DNS 전체가 SERVFAIL을 반환합니다. 기존 등록기관에서 DNSSEC(DS 레코드)를 반드시 제거한 뒤 24시간 후에 NS를 변경합니다.

셋째, 48시간 이상 대기해도 변하지 않으면 Cloudflare에서 도메인을 삭제하고 다시 추가합니다.

ERR_TOO_MANY_REDIRECTS (무한 리다이렉트 루프)

증상: 사이트 접속 시 브라우저에 "리다이렉트가 너무 많습니다" 오류가 표시됩니다.

원인: SSL/TLS 모드가 Flexible로 설정되어 있고, 원본 서버가 HTTP → HTTPS 301 리다이렉트를 강제하는 경우 발생합니다. Cloudflare(Flexible)는 원본에 HTTP로 연결 → 원본이 HTTPS로 리다이렉트 → Cloudflare가 다시 HTTP로 연결 → 무한 반복.

해결: SSL/TLS 모드를 Full 또는 Full (Strict) 로 변경합니다. 원본 서버에 SSL 인증서가 없는 경우 Cloudflare Origin CA 인증서를 발급하여 설치한 뒤 Full (Strict)로 설정합니다.

DNS_PROBE_FINISHED_NXDOMAIN

증상: 도메인에 접속하면 "서버의 DNS 주소를 찾을 수 없습니다" 오류가 발생합니다.

원인: 해당 도메인 또는 서브도메인에 대한 DNS 레코드가 Cloudflare에 존재하지 않거나, NS 전파가 아직 완료되지 않았습니다.

해결: Cloudflare DNS 관리 페이지에서 해당 호스트네임에 A/AAAA/CNAME 레코드가 올바르게 설정되어 있는지 확인합니다. dig A example.com @alice.ns.cloudflare.com으로 Cloudflare NS에 직접 질의하여 레코드 존재 여부를 확인할 수 있습니다.

이메일 수신 불가

증상: NS를 Cloudflare로 변경한 뒤 이메일이 수신되지 않습니다.

원인 1: MX 레코드가 Cloudflare DNS에 누락되었습니다. 자동 스캔에서 MX가 감지되지 않으면 이메일 라우팅이 완전히 끊깁니다.

원인 2: MX 레코드가 가리키는 메일 서버의 A 레코드가 Proxied(주황색 구름) 상태입니다. Cloudflare 프록시는 HTTP/HTTPS만 처리하므로, SMTP(포트 25/465/587) 트래픽이 차단됩니다.

해결: MX 레코드가 올바르게 설정되어 있는지 확인하고, 메일 서버 관련 A 레코드(예: Name이 mail인 A 레코드)는 반드시 DNS Only(회색 구름)로 변경합니다.

522 에러 (Connection Timed Out)

증상: 사이트 접속 시 Cloudflare의 522 오류 페이지가 표시됩니다.

원인: Cloudflare가 원본 서버에 TCP 연결을 시도했으나 응답이 없습니다. 원본 서버의 방화벽이 Cloudflare IP를 차단하고 있거나, 서버가 과부하 또는 다운 상태입니다.

해결: 원본 서버의 방화벽/보안 그룹에 Cloudflare IP 범위를 화이트리스트로 추가합니다. 서버가 정상 작동 중인지, 올바른 포트(80/443)에서 수신 대기 중인지 확인합니다.

도메인 이전(Transfer) 실패

흔한 거부 사유: 도메인 잠금(clientTransferProhibited)이 해제되지 않음, 인증 코드(Auth Code)가 만료되었거나 잘못 입력됨, 등록/이전 후 60일이 경과하지 않음(ICANN 규정), 도메인이 만료됨, WHOIS 등록자 정보가 최근 60일 이내에 변경됨.

대시보드의 Transfer Domains에서 거부 사유를 확인하고, 원인을 해결한 뒤 Retry를 클릭합니다.

Cloudflare 등록 도메인의 NS 변경 불가 (중요 제약)

Cloudflare Registrar에 등록되었거나 이전된 도메인은 Cloudflare 네임서버만 사용 가능합니다. 외부 NS로 변경하는 것이 불가능합니다. 외부 NS를 사용해야 하는 상황(예: 다른 DNS 호스트, 특수한 DNS 구성)이라면, 도메인을 다른 등록기관으로 이전해야 합니다.

이 제약은 방법 A(직접 구매)와 방법 C(이전)에 모두 적용되므로, 이전 전에 반드시 인지해야 합니다. 방법 B(NS 변경만)는 이 제약이 없습니다 — 언제든 NS를 원래 등록기관의 것으로 되돌려 Cloudflare를 해제할 수 있습니다.

서비스 중단 없는 연결을 위한 체크리스트

전환 전 기존 DNS 레코드 전수를 Cloudflare에 구성 완료했는지 확인합니다. 특히 MX, SPF, DKIM, DMARC, 서브도메인을 빠짐없이 확인합니다. 프록시 상태(웹: 주황, 메일: 회색)를 올바르게 설정했는지 확인합니다. DNSSEC가 비활성화되었는지 확인합니다(이전 또는 NS 변경 전). SSL/TLS 모드가 Full (Strict)로 설정되었는지 확인합니다. NS 변경 후 24시간 이내에 웹, 이메일, 서브도메인 모두 접속 테스트합니다.


11장. 방법 비교표 & 의사결정 플로차트

전체 비교표

비교 항목방법 A: 직접 구매방법 B: NS 변경방법 C: 완전 이전
도메인 등록기관Cloudflare기존 유지Cloudflare로 변경
설정 난이도★☆☆ 매우 쉬움★★☆ 보통★★★ 복잡
소요 시간수 분수 분 ~ 24시간최대 10일
비용 구조도매가 (마크업 0)기존 등록기관 요금도매가 + 1년 연장비
CDN/보안 기능즉시 사용Active 후 사용Active 후 사용
DNS 관리CloudflareCloudflareCloudflare
도메인 갱신Cloudflare (도매가)기존 등록기관Cloudflare (도매가)
외부 NS 사용❌ 불가해당 없음❌ 불가
.kr 도메인❌ 미지원✅ 가능⚠️ 제한적
WHOIS 비공개✅ 기본 무료등록기관에 따라 다름✅ 기본 무료
롤백 용이성다른 기관으로 이전 필요NS만 되돌리면 완료다른 기관으로 이전 필요

의사결정 플로차트

"신규 도메인을 구매하려는가?"

→ Yes → Cloudflare Registrar가 해당 TLD를 지원하는가? → Yes → 방법 A → No → 타사에서 구매 후 방법 B

→ No (기존 도메인 보유) → "등록기관을 바꾸고 싶은가?" → No → 방법 B → Yes → 이전 자격 요건 충족? → Yes → 방법 C → No (60일 미경과 등) → 우선 방법 B로 연결 후, 60일 후 방법 C

한 줄 요약

신규면 A, 기존 유지면 B, 장기 통합이면 C. .kr이면 대부분 B가 유일한 현실적 선택지입니다.


참고 링크