Cloudflare를 붙일 때 가장 먼저 결정할 것은 기능 수가 아니라 어떤 호스트의 HTTP·HTTPS 요청을 Cloudflare 프록시로 보낼 것인지입니다. 도메인을 관리하며 원본 서버를 확인할 수 있는 독자를 대상으로 설정과 검증 기준을 설명합니다.
요청 경로를 먼저 확인합니다
등록기관에서 네임서버를 Cloudflare가 지정한 값으로 바꾸면 Cloudflare가 권한 DNS 역할을 맡습니다. 그다음 A·AAAA·CNAME 레코드의 프록시 상태가 실제 웹 요청 경로를 결정합니다. 네임서버 위임과 주황색 구름(Proxied)은 같은 설정이 아닙니다.
Cloudflare의 전체 영역 설정 안내는 네임서버 교체 전에 apex, www, 메일, 검증용 레코드를 먼저 검토하라고 안내합니다. 기존 DNS 목록을 복사하지 않은 채 네임서버부터 바꾸면 누락된 레코드 때문에 웹이나 메일이 끊길 수 있습니다.
Proxied와 DNS Only를 서비스별로 구분합니다
Cloudflare의 프록시 상태 문서에 따르면 프록시할 수 있는 기본 레코드는 IP 주소 해석에 쓰이는 A·AAAA·CNAME입니다. MX·TXT는 프록시 대상이 아니며, 메일 전용 호스트나 소유권 검증 레코드도 DNS Only가 기준입니다.
- Proxied — 웹사이트의 apex·
www·웹 앱: 방문자 요청을 Cloudflare를 거쳐 원본으로 전달합니다. - 호환성을 확인한 뒤 Proxied — HTTP·HTTPS API: 고정 원본 IP 검사나 특수 헤더 의존 여부를 먼저 확인합니다.
- DNS Only — MX, 메일 전용 A·AAAA, SPF·DKIM·DMARC TXT: SMTP는 일반 Cloudflare HTTP 프록시 대상이 아닙니다.
- 공급자 안내에 따름, 보통 DNS Only — 서비스 소유권 확인용 CNAME·TXT: 프록시가 검증 대상 값을 가릴 수 있습니다.
- DNS Only 또는 별도 제품 검토 — HTTP가 아닌 임의 TCP·UDP 서비스: 일반 프록시는 지원 포트와 프로토콜 범위가 정해져 있습니다.
같은 이름에 A·AAAA 레코드가 여러 개 있고 하나라도 Proxied이면 Cloudflare는 그 이름의 레코드를 모두 프록시로 취급할 수 있습니다. 레코드를 한 줄씩 보지 말고 호스트 이름 단위로 확인해야 하는 이유입니다.
네임서버를 바꾸기 전에 복사할 항목
변경 창을 잡기 전에 기존 DNS 화면을 내보내거나 캡처하고 다음 값을 대조합니다.
- apex와
www의 A·AAAA·CNAME 대상 - MX 우선순위와 메일 전용 호스트 주소
- SPF·DKIM·DMARC와 검색·광고·SaaS 소유권 검증 TXT/CNAME
- 원본 서버가 받아들이는 호스트 이름과 80·443 포트
- 기존 DNSSEC의 DS 레코드 상태
Cloudflare 전체 영역 설정에서는 기존 DNSSEC가 활성화된 경우 네임서버를 교체하기 전에 등록기관의 DNSSEC를 해제하고, 영역이 활성화된 뒤 Cloudflare에서 다시 구성하는 절차를 안내합니다. 등록기관 화면의 네임서버 두 개가 Cloudflare 대시보드에 표시된 값과 정확히 같은지도 확인합니다.
DNS, TLS, 캐시·보안 순서로 점검합니다
1. DNS 레코드를 먼저 확인합니다
기존 공급자의 레코드를 Cloudflare로 옮기고 apex·www가 올바른 원본을 가리키는지 확인합니다. 웹 트래픽 레코드만 우선 Proxied로 전환하고 메일·검증 레코드는 DNS Only로 둡니다. 변경 직후에는 로컬 캐시 때문에 이전 응답이 남을 수 있으므로 공용 리졸버를 지정해 조회합니다.
2. 네임서버 위임 완료 여부를 확인합니다
등록기관에서 Cloudflare가 지정한 두 네임서버로 교체합니다. 대시보드의 영역 상태가 Active인지 확인하고 dig NS 결과도 같은 두 이름을 반환해야 다음 단계로 진행합니다.
3. 원본 HTTPS가 준비되면 Full (strict)를 사용합니다
Cloudflare의 Full (strict) 기준은 원본이 443에서 HTTPS를 받고, 인증서가 만료되지 않았으며, 공개 CA 또는 Cloudflare Origin CA가 발급했고, 요청 호스트 이름과 일치해야 한다고 설명합니다. 이 조건을 먼저 충족한 뒤 Full (strict)를 선택합니다. 조건이 맞지 않으면 526 오류가 날 수 있습니다.
4. 캐시와 WAF는 좁은 규칙부터 적용합니다
프록시 연결이 정상인지 확인한 다음 캐시와 보안 규칙을 추가합니다. 로그인·관리·결제·사용자별 응답처럼 내용이 달라지는 경로는 HTML 전체 캐시에서 제외합니다. WAF 규칙도 전체 차단부터 시작하지 말고 이벤트 로그를 보면서 경로·메서드·조건을 좁힙니다.
DNS와 HTTP 두 층의 판정 기준
다음 명령은 example.com을 실제 호스트 이름으로 바꿔 실행합니다.
dig NS example.com @1.1.1.1
dig A example.com @1.1.1.1
curl -sS -D - -o /dev/null https://example.com/
curl -sS https://example.com/cdn-cgi/trace
판정 기준은 서로 대신할 수 없습니다.
dig NS: 등록기관의 위임 결과입니다. Cloudflare가 지정한 권한 네임서버가 반환되어야 합니다.dig A또는dig AAAA: Proxied 호스트는 원본 주소 대신 Cloudflare 네트워크 주소가 보이는 것이 정상입니다. DNS Only 호스트는 원본 주소가 보입니다.curl -D -: 기대한 2xx·3xx 상태와cf-ray응답 헤더가 있으면 해당 HTTP 요청이 Cloudflare를 거친 근거가 됩니다./cdn-cgi/trace: Cloudflare가 관리하는 진단 엔드포인트입니다. 응답의h가 요청 호스트와 맞고colo가 있으면 어느 Cloudflare 데이터센터가 요청을 처리했는지 확인할 수 있습니다. 자세한 필드는 공식 endpoint 안내에서 확인합니다.cf-cache-status: 공식 캐시 응답 문서의 HIT·MISS·BYPASS·DYNAMIC 등은 그 응답의 캐시 판단입니다.cf-ray가 있는데 HIT가 아니라고 해서 프록시 실패로 판정하면 안 됩니다.
실패할 때 증상에서 역순으로 점검합니다
- 도메인 자체가 해석되지 않음:
dig NS로 위임을 확인하고, 등록기관에 예전 네임서버가 섞여 있지 않은지와 이전 DS 레코드가 남아 있지 않은지 봅니다. - NS는 맞지만 호스트가 해석되지 않음: Cloudflare DNS의 apex·
wwwA·AAAA·CNAME 이름과 대상, 오타, 중복 레코드를 확인합니다. - DNS는 되지만 HTTPS 실패:
curl -v로 HTTP 상태와 TLS 오류를 기록합니다. 526이면 원본 인증서의 유효기간·발급자·호스트 이름을 확인합니다. 525면 원본과 Cloudflare 사이 TLS 협상을 먼저 봅니다. - 521·522·523·524: Cloudflare의 5xx 오류 분류에 맞춰 원본 프로세스, 80·443 리스닝, 방화벽의 Cloudflare IP 허용, 원본 경로와 응답 시간을 확인합니다. 오류 코드와 발생 시각·시간대, URL,
cf-ray를 함께 기록합니다. - 접속은 되지만 오래된 내용:
cf-cache-status와age를 확인하고 캐시 규칙, 원본의Cache-Control, 쿠키, 개발 모드, purge 이력을 순서대로 봅니다. 무조건 전체 캐시 삭제부터 하면 원인 증거가 사라집니다.
설정을 마쳤다는 판단은 대시보드의 주황색 구름 하나로 끝나지 않습니다. 권한 DNS 위임, 호스트별 프록시 선택, 원본 TLS, 실제 HTTP 헤더를 각각 확인하고 결과를 기록해야 다음 변경에서도 같은 기준으로 복구할 수 있습니다.