클라우드플레어 도메인 연결, DNS와 SSL 설정 순서

클라우드플레어 도메인 연결을 하려는데 네임서버, DNS, SSL이 한꺼번에 나와 멈칫했다면 먼저 작업 순서를 나누면 됩니다. 기존 사이트와 이메일을 살린 채 차근차근 확인하는 흐름으로 정리했어요.

도메인 연결 전 준비사항과 설정 방식 구분

클라우드플레어 도메인 연결은 도메인 소유권이나 웹호스팅 계약을 바꾸는 일이 아닙니다. 기존 등록업체에서 산 도메인을 그대로 두고, DNS 설정을 관리하는 주체만 Cloudflare로 옮기는 작업에 가깝습니다.

먼저 내 상황이 기존 도메인 연결인지, 새 도메인 등록인지, 등록기관 이전인지 나눠야 합니다. 도메인 구매 방법을 찾는 단계라면 새 등록이고, 업체 자체를 옮기려면 기관 이전 절차를 봐야 합니다. 이미 보유한 주소를 연결하려면 기존 등록업체 확인부터 하면 됩니다.

도메인 등록업체 계정
현재 네임서버
원본 서버의 IPv4·IPv6 주소
루트 및 서브도메인 목록
MX·TXT 등 이메일 레코드
기존 리디렉션 및 SSL 적용 상태

저는 현재 사이트가 열리는 값과 이메일 관련 값을 따로 적어두고 시작하는 편입니다. 도메인 등록 화면에서 급하게 바꾸다 보면 이전 값을 잊기 쉽고, 그때부터 원인 찾기가 어려워집니다.

계정 생성과 사이트 추가 절차

처음에는 대시보드 용어가 낯설지만 순서는 단순합니다. 2026년 7월 20일 기준, 기본적인 클라우드플레어 도메인 연결과 일반 DNS·CDN 시작은 무료 플랜에서도 가능하지만, 세부 기능은 요금제 비교 화면에서 다시 확인하는 게 좋습니다.

이메일 주소로 계정을 생성하고 인증합니다.
대시보드에서 사이트 추가 메뉴를 선택합니다.
example.com 형식으로 루트 도메인을 입력합니다.
DNS 자동 스캔이 끝날 때까지 기다립니다.
필요한 기능과 비용을 비교해 요금제를 선택합니다.
Cloudflare가 배정한 네임서버 2개를 확인합니다.

사이트 추가는 도메인 등록이나 등록기관 이전을 뜻하지 않습니다. 이 단계에서는 권한 검증이 끝나기 전이라 기존 사이트가 바로 멈추지는 않습니다. 사이트 추가를 마친 뒤 DNS 레코드를 확인하고, 마지막에 네임서버를 바꾸는 흐름으로 진행하면 됩니다.

자동으로 가져온 DNS 레코드 점검

Cloudflare는 사이트 추가 과정에서 기존 값을 자동 스캔해 레코드 가져오기를 시도합니다. 다만 자동으로 보였다고 해서 모든 DNS 설정이 정확하다고 보면 안 됩니다. 레코드 관리는 기존 등록업체 화면과 Cloudflare 화면을 나란히 두고 대조하는 방식이 가장 안전했습니다.

점검 대상	기존 DNS에서 확인할 값	Cloudflare에서 확인할 값	불일치 시 조치
루트 도메인	A 또는 AAAA 값	같은 원본 서버 IP	현재 호스팅 값으로 수정
`www`	CNAME 또는 A 값	동일한 대상	잘못된 호스트 이름 수정
기타 서브도메인	blog, shop, app 등	필요 항목 존재 여부	누락 항목 추가
메일	MX 우선순위와 대상	MX와 관련 TXT	메일 제공업체 값 복사
소유권 인증	TXT 인증값	동일한 TXT 값	서비스별 인증값 재입력
외부 서비스 연결	CNAME, TXT, A 값	서비스 지정값	중복 항목 정리

중복 항목은 같은 이름에 서로 다른 값이 들어간 경우가 많습니다. 특히 루트 도메인과 www에서 오래된 서버 주소가 남아 있으면 충돌 해결을 먼저 해야 합니다.

네임서버를 바꾼 뒤에 고치려면 접속 결과가 지역마다 다르게 보일 수 있습니다. 그래서 레코드 관리는 네임서버 변경 전 단계에서 끝낸다는 생각으로 확인했습니다.

A·AAAA·CNAME 레코드로 웹사이트 주소 설정

클라우드플레어 도메인 연결에서 웹사이트 주소는 A, AAAA, CNAME 레코드로 잡습니다. 핵심은 호스팅 업체가 준 원본 서버 IP와 대상 호스트를 정확한 칸에 넣는 것입니다.

루트 도메인의 A·AAAA 레코드

루트 도메인은 보통 이름 칸에 @를 넣고 A 레코드에 IPv4 주소 매핑을 합니다. 원본 서버의 IPv4 주소가 바뀌었다면 예전 값을 남기지 않습니다. 호스팅 업체가 IPv6를 제공할 때만 AAAA 레코드로 IPv6 주소 매핑을 추가합니다.

접속 주소	레코드 유형	이름 예시	대상 값 예시	용도
루트 A	A	`@`	`192.0.2.10`	IPv4 주소 매핑
루트 AAAA	AAAA	`@`	`2001:db8::10`	IPv6 주소 매핑
`www` CNAME	CNAME	`www`	`example.com`	www 서브도메인 연결
별도 서브도메인 CNAME	CNAME	`blog`	`host.example.net`	외부 서비스 연결

www 및 서브도메인의 CNAME 레코드

www 서브도메인은 CNAME 레코드로 example.com이나 서비스 제공업체가 준 호스트 이름에 연결하는 경우가 많습니다. CNAME 대상에는 https://나 경로를 넣지 않습니다. 같은 이름에 A와 CNAME 레코드를 동시에 만들면 레코드 관리가 꼬일 수 있으니 하나로 정리합니다. 에이펙스 주소에 CNAME이 필요할 때는 Cloudflare의 CNAME 플래트닝 동작을 함께 확인합니다.

등록업체에서 네임서버 변경하기

네임서버 변경은 Cloudflare의 DNS 레코드 화면에서 NS 레코드를 추가하는 일이 아닙니다. 가비아 연동이든 다른 업체든, 기존 등록업체 확인 후 도메인 관리 화면에서 권한 네임서버 자체를 교체해야 합니다.

Cloudflare에 표시된 네임서버 2개를 기록합니다.
기존 등록업체의 도메인 관리 화면에 로그인합니다.
네임서버 또는 DNS 서버 변경 메뉴를 엽니다.
기존 값을 Cloudflare 배정값으로 각각 교체합니다.
변경 내용을 저장하고 추가 인증 절차를 완료합니다.
Cloudflare 대시보드에서 재확인 기능을 실행합니다.

클라우드플레어 도메인 연결에서 권한 검증은 이 네임서버 변경이 맞게 저장됐는지 보는 단계입니다. 잘못된 네임서버 철자, 끝의 점 처리, 기존 값 잔존 여부를 확인하세요. 변경 직후에는 예전 DNS 영역을 바로 지우지 않는 편이 좋습니다.

DNS 전파와 영역 활성화 확인

DNS 전파는 모든 곳에서 동시에 끝나는 작업이 아닙니다. 등록업체, 통신사, 브라우저, 운영체제 캐시가 각각 다른 시점에 갱신되기 때문에 전파 시간이 다르게 느껴질 수 있습니다.

등록업체에 저장된 네임서버 2개
Cloudflare의 보류 또는 활성 표시
루트 도메인의 응답 주소
www와 주요 서브도메인의 응답
서로 다른 네트워크에서의 접속 결과

대시보드가 보류 상태라면 권한 검증이 아직 끝나지 않았다는 뜻입니다. 활성 상태가 되면 영역 활성화가 완료된 것입니다. 연결 상태 확인을 반복하기보다 네임서버가 Cloudflare 배정값과 일치하는지 먼저 봅니다.

적용 지연이 있어도 DNS 설정을 계속 바꾸면 원인을 더 찾기 어려워집니다. 전파 시간 동안 기존 DNS 설정을 일정 시간 유지하고, 영역 활성화 상태와 실제 접속 결과를 나눠서 확인하는 게 좋았습니다.

프록시 상태와 CDN 적용 기준

프록시 상태는 웹 요청을 Cloudflare를 거치게 할지 정하는 값입니다. 주황색 구름은 프록시 사용 상태라 CDN 활성화와 보안 기능을 적용할 수 있고, 회색 구름은 DNS 전용으로 응답만 제공합니다.

모든 레코드를 같은 방식으로 바꾸면 문제가 생깁니다. 웹 트래픽을 받는 A, AAAA, CNAME은 프록시 사용을 검토하고, 메일이나 인증용 값은 DNS 전용으로 두는 식으로 나눴습니다.

서비스 또는 레코드	권장 프록시 상태	적용 기능	주의점
루트 웹사이트	주황색 구름	CDN 활성화, 캐시 설정	원본 접속 확인 후 적용
`www`	주황색 구름	프록시 사용, HTTPS 관리	루트와 이동 규칙 일치
정적 파일 서브도메인	상황별 선택	캐시 설정	파일 갱신 흐름 확인
API	상황별 선택	보안 규칙 적용	응답 지연과 허용 목록 확인
메일 서버	회색 구름	DNS 전용	MX 대상은 프록시 사용 안 함
외부 소유권 인증	회색 구름	DNS 전용	TXT와 인증용 CNAME 유지

자동 TTL은 프록시된 레코드에서 Cloudflare가 TTL 값 관리를 맡는 상태입니다. 프록시 사용 시 원본 서버 주소 대신 Cloudflare 응답이 보일 수 있습니다. 연결 상태 확인 전에는 과한 캐시 설정을 피하고, 먼저 기본 접속이 안정적인지 보는 편이 낫습니다.

SSL/TLS 모드 선택과 HTTPS 적용

SSL/TLS 설정은 방문자와 Cloudflare, Cloudflare와 원본 서버 사이의 암호화 모드를 정하는 과정입니다. Flexible SSL, Full SSL, Full Strict SSL은 원본 구간 처리 방식이 다릅니다.

암호화 모드	방문자 구간	원본 서버 구간	원본 인증서 요구사항	권장 상황
Flexible	HTTPS 가능	HTTP	필수 아님	원본 HTTPS가 없을 때 임시 확인
Full	HTTPS	HTTPS	검증은 느슨함	원본에 인증서는 있으나 검증 문제가 있을 때
Full Strict	HTTPS	HTTPS	유효한 인증서 필요	원본 인증서가 정상일 때 우선 선택

원본 서버에 유효한 인증서가 있다면 Full Strict SSL을 우선으로 봅니다. 이 모드는 원본 인증서의 이름과 유효기간까지 확인합니다. 엣지 인증서와 유니버설 SSL 발급이 끝나기 전에는 HTTPS가 바로 안정화되지 않을 수 있으니 인증서 발급 대기 상태도 함께 봐야 합니다.

엣지 인증서 및 유니버설 SSL 발급 상태 확인
원본 서버 인증서의 도메인과 유효기간 확인
적절한 암호화 모드 선택
정상 접속 후 항상 HTTPS 사용 활성화

HTTPS 리디렉션은 여러 곳에서 동시에 켜면 반복 이동이 생길 수 있습니다. 저는 원본 서버 설정, Cloudflare의 항상 HTTPS 사용, 별도 리디렉션 규칙 중 어디에서 처리할지 하나씩 확인한 뒤 적용합니다.

이메일과 서브도메인 중단 방지 설정

네임서버를 바꾸면 Cloudflare DNS 설정에 없는 값은 더 이상 조회되지 않을 수 있습니다. 웹사이트는 열리는데 메일 수신 오류가 나는 경우도 이 단계에서 많이 생깁니다.

MX 대상과 우선순위
메일 서버용 A 또는 CNAME
SPF TXT 값
DKIM 선택자와 TXT 값
DMARC 정책 TXT 값
외부 서비스 인증용 TXT 값

레코드	주요 역할	확인할 값	프록시 기준
MX	메일 수신 서버 지정	대상과 우선순위	DNS 전용
메일 호스트	메일 서버 주소 연결	A 또는 CNAME 대상	DNS 전용
SPF	발신 서버 확인	SPF 설정 TXT	DNS 전용
DKIM	메일 서명 확인	DKIM 설정 선택자와 TXT 값	DNS 전용
DMARC	메일 정책 전달	DMARC 설정 TXT	DNS 전용

이메일 라우팅을 쓸 때도 기존 메일 서비스와 충돌하지 않는지 봐야 합니다. www 서브도메인, 쇼핑몰, 관리자 페이지, API처럼 실제로 쓰는 호스트 이름을 서비스 목록과 대조하면 빠진 값을 줄일 수 있습니다.

접속·SSL·리디렉션 오류 해결

클라우드플레어 도메인 연결 후 오류가 나오면 설정을 한꺼번에 바꾸지 말고 DNS, 원본 서버, SSL, 이동 규칙 순서로 좁혀야 합니다. 접속 불가 해결은 증상별로 첫 확인 지점이 다릅니다.

DNS 및 원본 서버 연결 오류

NXDOMAIN 오류나 DNS_PROBE_FINISHED_NXDOMAIN, DNS 주소 찾을 수 없음 메시지가 보이면 네임서버와 A·AAAA·CNAME 존재 여부부터 봅니다. 오류 521은 원본 연결 거부, 오류 522는 원본 연결 시간 초과와 관련될 수 있어 서버 상태, 포트, 원본 서버 IP, Cloudflare 요청 허용 여부를 점검합니다.

SSL 및 HTTPS 이동 오류

오류 525와 오류 526은 SSL 핸드셰이크 오류나 인증서 검증 문제를 의심해야 합니다. 원본 인증서, 암호화 모드, 인증서 이름과 유효기간을 확인합니다. 리디렉션 반복은 원본 서버 설정, HTTPS 리디렉션, 리디렉트 규칙, 기존 페이지 규칙을 하나씩 분리해 봅니다.

증상 또는 코드	주요 확인 영역	먼저 확인할 항목	권장 조치
NXDOMAIN	DNS	네임서버와 레코드 존재	누락 레코드 추가
DNS 주소 조회 실패	DNS 전파	루트와 www 응답	전파 상태와 캐시 확인
521	원본 서버	서버 응답과 포트	원본 접속 허용 확인
522	네트워크	응답 시간과 방화벽	호스팅 상태 점검
525	SSL 연결	원본 HTTPS 동작	암호화 모드 재확인
526	인증서 검증	도메인 이름과 유효기간	Full Strict SSL 조건 점검
리디렉션 반복	이동 규칙	중복 HTTPS 이동	규칙을 하나씩 분리

명령어와 DNS 도구를 이용한 최종 점검

대시보드의 활성 표시만 보고 끝내기보다 실제 응답까지 봐야 합니다. 연결 상태 확인은 여러 방법을 섞으면 전파 시간 문제와 설정 오류를 구분하기 좋습니다.

등록업체의 권한 네임서버를 확인합니다.
dig 명령어로 NS 레코드와 A 또는 CNAME 응답을 조회합니다.
nslookup 조회로 다른 DNS 확인자의 응답을 비교합니다.
DNS 체커와 전파 확인 도구에서 여러 지역의 결과를 확인합니다.
루트, www, HTTPS, 이메일과 주요 서브도메인을 실제로 점검합니다.

설정값이 맞는데 예전 응답이 보이면 브라우저, 운영체제, 공유기, 통신사 DNS 캐시 삭제 여부를 나눠서 봅니다. 지역별 응답 차이가 남아 있을 때 레코드를 반복 수정하면 영역 진단이 더 어려워질 수 있습니다.

보안·캐시 설정과 서비스별 연결 방법

기본 접속이 확인된 뒤에 보안 설정, 캐시 설정, CDN 활성화를 차례로 적용하는 게 좋습니다. 방화벽 규칙, 웹 애플리케이션 방화벽, 봇 차단, 디도스 방어 같은 기능은 한 번에 켜기보다 사이트 동작을 보면서 조정했습니다.

서비스 또는 기능	주요 설정 위치	필요한 레코드 또는 값	완료 확인 방법
Cloudflare Pages 사용자 지정 도메인	Pages 프로젝트	CNAME 또는 안내된 값	사용자 지정 도메인 상태 확인
티스토리	블로그 도메인 설정	서비스 지정 CNAME	티스토리 연동 상태 확인
워드프레스	호스팅과 워드프레스 설정	A, AAAA, CNAME	워드프레스 연결 후 HTTPS 접속
구글 서치콘솔	소유권 확인	TXT 레코드	검색엔진 소유권 확인 완료
CDN·캐시	캐시 메뉴	프록시 사용 레코드	정적 파일 응답 확인
웹 애플리케이션 방화벽	보안 메뉴	규칙 조건	정상 요청 차단 여부 확인
DNSSEC	DNS 설정과 등록업체	DS 레코드	검증 상태 확인

DNSSEC 설정은 Cloudflare에서 켠 뒤 DS 레코드 정보를 등록업체에 정확히 넣는 순서가 중요합니다. 변경 후에는 사이트 접속, HTTPS, 메일, Cloudflare Pages 사용자 지정 도메인, 검색엔진 인증 상태를 다시 확인합니다.

도메인 구매·연결·등록기관 이전 비용 비교

클라우드플레어 도메인 연결은 보유 도메인의 네임서버를 바꾸는 작업입니다. 새 도메인 등록이나 등록기관 이전과는 목적도 비용 확인 항목도 다릅니다.

방식	등록업체 변경 여부	주요 작업	사이트 영향	비용 확인 항목
기존 도메인 연결	변경 없음	네임서버 변경, DNS 점검	전파 중 응답 차이 가능	Cloudflare 요금제 비교
신규 도메인 구매	새로 선택	도메인 등록, DNS 구성	새 사이트 기준으로 설정	도메인 가격과 연간 갱신 비용
등록기관 이전	변경 있음	이전 잠금 해제, 인증 코드 입력	절차 중 상태 확인 필요	이전 비용과 만료일 관리

최초 등록 가격과 연간 갱신 비용
이전 가능 시점과 잠금 상태
인증 코드 발급 방법
WHOIS 개인정보 보호 범위
만료일과 자동 갱신 결제수단

도메인 가격은 확장자와 업체 정책에 따라 달라집니다. 처음 결제 금액만 보지 말고 다음 해 비용, 자동 갱신, 개인정보 보호 제공 범위까지 같이 확인해야 관리가 편합니다.

클라우드플레어 도메인 연결 마무리 점검

처음에는 네임서버와 DNS, SSL이 한꺼번에 보여 복잡하게 느껴졌지만, 순서를 나누면 할 일이 선명해집니다. 기존 값을 기록하고, 사이트 추가 후 레코드를 대조하고, 마지막에 네임서버를 바꾸면 불안한 지점을 줄일 수 있었습니다. 연결 뒤에는 HTTPS, 이메일, 서브도메인까지 실제로 열어보는 것이 마지막 팁입니다.

About the author