Feb 7, 2026

마지막 업데이트 Apr 9, 2026

Cloudflare DNS 가이드: 루트와 www, Proxy Mode, Vercel 점검 포인트

Cloudflare DNS 문제는 실제 운영에서는 순수한 “DNS 문제”처럼만 보이지 않는 경우가 많습니다. 보통은 DNS 바깥의 공개 요청 경로가 같이 꼬입니다. 어느 호스트를 공개 버전으로 쓸지 안 정했거나, www와 루트 도메인이 따로 놀거나, proxy mode가 한 단계를 더 만들거나, SSL이 덜 안정됐거나, /ads.txt가 한 호스트에서만 열리는 식입니다.

그래서 Cloudflare나 Vercel 대시보드에는 멀쩡해 보여도, 검색엔진이나 검색엔진 심사, 실제 방문자 입장에서는 여전히 일관성이 없는 상태가 됩니다.

이 글은 그 실전 기준을 정리합니다.

Vercel이 보통 어떤 레코드를 기대하는지
루트 도메인과 www를 어떻게 정리해야 하는지
Cloudflare proxy mode는 언제 도움이 되고 언제 복잡성을 늘리는지
설정을 믿기 전에 무엇을 직접 확인해야 하는지

이 블로그를 처음 Vercel에 배포했을 때 apex 도메인만 추가하고 www는 빠뜨렸더니, Google Search Console에서 절반의 페이지가 “크롤링됨 - 현재 색인이 생성되지 않음”이었습니다. redirect도 없어서 canonical이 두 갈래로 갈라진 상태였습니다. www를 추가하고 apex에서 301 redirect를 걸자 2주 만에 색인이 정상화됐습니다.

짧게 말하면 공개 호스트를 하나 정하고, 루트와 www를 의도적으로 둘 다 구성하고, DNS와 redirect를 단순하게 유지하고, 대시보드보다 실제 브라우저 경로를 믿는 것이 핵심입니다.

Quick answer

Cloudflare와 Vercel을 같이 쓰는 일반적인 블로그나 프런트엔드라면:

www.example.com 같은 공개 호스트를 하나 정합니다
루트 도메인과 www를 둘 다 Vercel에 추가합니다
apex는 Vercel이 요구하는 레코드로, 서브도메인은 기대하는 CNAME으로 설정합니다
비공개 호스트는 공개 호스트로 깔끔하게 redirect합니다
공개 호스트에서 robots.txt, sitemap-index.xml, ads.txt를 확인합니다
정말 필요한 경우에만 Cloudflare proxy나 추가 redirect 규칙을 얹습니다

여기서 하나라도 어긋나면, 문제는 DNS 에러처럼 보이지 않고 색인 문제, 심사 문제, SSL 문제처럼 나타나는 경우가 많습니다.

먼저 공개 호스트를 하나 정하기

실전에서 가장 큰 DNS 실수는 레코드 타입보다 “어느 호스트를 공개 버전으로 쓸지”를 안 정하는 것입니다.

예를 들면:

https://example.com/
또는 https://www.example.com/

Vercel 도메인 문서는 apex 도메인을 추가하면 www도 함께 추가하도록 안내하고, 더 견고하게 운영하려면 반대편 호스트도 명시적으로 추가해서 redirect하라고 설명합니다.

이게 중요한 이유는 공개 호스트가 아래 전부와 맞아야 하기 때문입니다.

홈
글 상세
canonical URL
hreflang
robots.txt
sitemap-index.xml
ads.txt

공개 호스트를 www로 정했다면 apex는 www로 보내야 하고, apex를 공개 호스트로 정했다면 www가 apex로 가야 합니다. 무엇을 고르느냐보다 같은 선택을 끝까지 유지하느냐가 더 중요합니다.

Vercel이 보통 기대하는 DNS 레코드

Vercel 도메인 문서는 기본 구성을 비교적 단순하게 설명합니다.

example.com 같은 apex 도메인: 보통 A 레코드
www.example.com 같은 서브도메인: 보통 CNAME
소유권 검증이 필요할 때: TXT 레코드

대부분의 블로그와 프런트엔드 배포는 이 정도로 해결됩니다.

Cloudflare는 zone apex에서 CNAME flattening도 지원합니다. 그래서 apex에 CNAME을 쓰는 것도 기술적으로 가능한 경우가 있습니다. 그래도 Vercel이 apex에 A 레코드를 요구한다면, 초반에는 변형보다 Vercel이 기대하는 타입을 그대로 따르는 편이 안전합니다.

Proxy mode는 정답이 하나가 아니라 tradeoff다

Cloudflare DNS 문서는 웹 트래픽을 서빙하는 A, AAAA, CNAME 레코드는 proxied로 두는 것을 권장합니다. Cloudflare를 쓰는 주된 이유가 그 레이어에 있으니까요.

반대로 Vercel reverse proxy 문서는 Vercel 프로젝트 앞에 reverse proxy를 두는 것을 기본적으로 권장하지 않는다고 설명합니다. 방화벽 가시성과 실제 클라이언트 IP 처리에 영향을 주기 때문입니다. 다만 Vercel은 Cloudflare를 Verified Proxy Lite 지원 provider로도 문서화하고 있습니다.

그래서 실전 해석은 이렇게 가는 편이 맞습니다.

Cloudflare edge 보호나 프록시 기능이 필요하면 proxied mode도 충분히 유효합니다
단순히 도메인 연결을 깔끔하게 끝내고 문제를 빨리 분리하고 싶다면, 불필요한 proxy, cache, redirect를 겹치지 않는 편이 좋습니다

즉 DNS only가 무조건 맞는 것도 아니고, proxied가 무조건 틀린 것도 아닙니다. 핵심은 그 추가 레이어가 실제로 필요한지입니다.

루트와 www는 하나의 사이트처럼 움직여야 한다

배포가 심사나 색인에서 실패하는 이유는 도메인이 완전히 죽어서가 아니라, 두 호스트가 하나의 사이트처럼 행동하지 않기 때문인 경우가 많습니다.

대표적인 경우:

https://example.com/은 열리는데 https://www.example.com/은 실패한다
둘 다 열리지만 canonical이 서로 다르다
홈은 redirect가 맞는데 /ads.txt는 안 맞다
Search Console은 한 호스트를 보고 있는데 실제 사이트는 다른 호스트가 공개본이다

검색엔진 심사에서는 이 차이가 특히 치명적입니다. 제출한 호스트, 실제 공개 호스트, /ads.txt가 열리는 호스트가 서로 다르면 계속 애매한 상태가 됩니다.

예를 들어 공개 호스트가 https://www.example.com이라면 아래가 다 맞아야 합니다.

https://example.com/이 https://www.example.com/으로 redirect된다
https://example.com/ads.txt도 공개 호스트 쪽으로 깔끔하게 이어진다
페이지 HTML의 canonical URL이 공개 호스트를 가리킨다
sitemap과 robots 경로도 같은 호스트 기준이다

대시보드보다 실제 공개 경로를 확인하기

중요한 경로는 간단한 헤더 확인만으로도 꽤 많이 걸러낼 수 있습니다.

curl -I https://example.com/
curl -I https://www.example.com/
curl -I https://www.example.com/ads.txt

보고 싶은 그림은 하나입니다.

비공개 호스트는 한 번만 redirect한다
공개 호스트는 200 OK를 준다
ads.txt 같은 심사 파일이 공개 호스트에서 정상적으로 열린다

대시보드가 초록색이어도 공개 경로가 여러 번 튀거나 loop가 나거나 호스트가 갈라지면, 그 도메인 설정은 아직 끝난 것이 아닙니다.

Cloudflare를 Vercel 앞단 proxy로 둘 때

이 부분을 건너뛰는 경우가 많습니다.

Cloudflare proxy를 의도적으로 Vercel 앞에 둘 거라면, Vercel reverse proxy 문서 기준으로 아래 경로를 망가뜨리면 안 됩니다.

TLS 설정 중 http://<DOMAIN>/.well-known/acme-challenge/*에 대해 포트 80에서 HTTP -> HTTPS 강제 redirect를 걸어버리는 것
https://<DOMAIN>/.well-known/vercel/*를 캐시해버리는 것

그리고 host redirect와 HTTPS redirect를 Cloudflare와 Vercel 양쪽에서 동시에 중복 관리하지 않는 것이 좋습니다.

나쁜 패턴은 보통 이렇게 생깁니다.

Vercel이 HTTPS를 강제함
Cloudflare도 HTTPS를 강제함
Cloudflare redirect rule이 호스트를 또 바꿈

각각 따로 보면 맞는 말인데, 같이 걸리면 loop나 부분 실패가 금방 생깁니다.

흔한 실수

1. 한쪽 호스트만 완전히 설정해두는 경우

apex는 되는데 www를 Vercel에 추가하지 않았거나, 반대인 경우입니다.

2. 이유 없이 proxy mode를 켜는 경우

추가 레이어는 의도적일 때는 괜찮지만, 문제만 더 복잡하게 만들 수도 있습니다.

3. `ads.txt`가 한 호스트에서만 열리는 경우

특히 AdSense 문제를 볼 때는 심사 호스트와 파일 경로가 어긋나서 더 헷갈려집니다.

4. canonical 메타데이터가 실제 공개 호스트와 다른 경우

브라우저는 한 호스트에서 끝나는데 HTML은 다른 호스트를 가리키면 검색엔진 쪽 해석이 흔들립니다.

5. CNAME flattening을 모든 경우의 지름길처럼 쓰는 경우

Cloudflare는 apex CNAME flattening을 지원하지만, 플랫폼이 기대하는 기본 레코드 타입부터 맞추는 편이 안전합니다. Cloudflare 문서도 모든 CNAME flattening은 일부 third-party verification을 깨뜨릴 수 있다고 설명합니다.

6. 대시보드만 보고 최종 응답을 안 보는 경우

최종 진실은 대시보드가 아니라 공개 응답 경로에 있습니다.

실전 디버깅 순서

뭔가 이상하면 아래 순서로 보세요.

어느 호스트를 공개본으로 쓸지 먼저 정했는가
apex와 www를 둘 다 Vercel에 추가했는가
레코드 타입이 Vercel이 기대하는 타입과 맞는가
Cloudflare proxy status가 의도된 설정인가
redirect가 한 호스트에서 끝나고 200으로 마무리되는가
robots.txt, sitemap-index.xml, ads.txt가 공개 호스트에서 열리는가
canonical과 hreflang 출력도 그 최종 호스트와 맞는가

이 순서가 DNS 표만 계속 들여다보는 것보다 훨씬 빨리 원인을 찾게 해주는 경우가 많습니다.

FAQ

Q. Vercel이면 항상 `www`를 써야 하나요?

항상은 아닙니다. 다만 Vercel은 apex 도메인을 추가할 때 www도 함께 추가하도록 유도하고, 반대편 호스트를 명시적으로 추가해서 redirect하라고 권장합니다. 핵심은 하나를 공개 호스트로 정하고 일관되게 유지하는 것입니다.

Q. Cloudflare proxy mode는 Vercel에서 잘못된 선택인가요?

아닙니다. Cloudflare는 Vercel Verified Proxy Lite 지원 provider입니다. 다만 Vercel 문서도 reverse proxy 계층이 운영상 tradeoff를 늘린다고 설명하므로, 습관처럼 켜기보다 의도를 가지고 쓰는 편이 좋습니다.

Q. Cloudflare가 CNAME flattening을 지원하니 apex도 CNAME으로 가는 게 더 좋은가요?

항상 그렇지는 않습니다. 플랫폼 요구사항과 맞고 왜 그렇게 하는지 분명할 때만 쓰는 편이 좋습니다. Vercel이 apex A 레코드를 요구한다면 먼저 그 구성을 따르세요.

Q. 대시보드에는 connected인데 브라우저는 왜 여전히 이상한가요?

DNS, SSL, redirect, proxy 동작이 같은 시점에 같은 방식으로 안정되지 않기 때문입니다.

Official References

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.