먼저 보는 핵심 체크리스트

Cloudflare를 끼운 상태에서 www 리디렉션이 꼬이면, 거의 항상 원인은 3군데 중 하나입니다.

1. Cloudflare DNS/Redirect 설정
2. Vercel의 도메인(primary domain) 설정
3. 둘 다 리디렉션을 하려고 해서 생기는 중복 리디렉션

진단은 아래 순서로 하면 가장 빠릅니다.

1) 최종적으로 어디로 보내고 싶은지 먼저 고정 예: - example.com -> www.example.com 로 보낼지 - www.example.com -> example.com 로 보낼지

이걸 먼저 하나로 정해야 합니다. Cloudflare와 Vercel이 서로 반대 방향으로 잡혀 있으면 무한 리디렉션이나 랜덤한 꼬임이 납니다.

2) Cloudflare DNS에서 @와 www가 둘 다 Vercel로 향하는지 확인 확인할 것: - @ 루트 도메인 레코드 - www CNAME - 둘 중 하나가 오래된 서버/IP를 가리키고 있지 않은지

보통 안전한 형태는:

• www -> Vercel CNAME
• @ -> Vercel이 안내한 방식

여기서 중요한 건 Cloudflare 오렌지 구름(Proxy)이 켜져 있어도, 원래 목적지가 Vercel이어야 한다는 점입니다.

3) Vercel 프로젝트에서 도메인 2개가 모두 등록됐는지 확인 Vercel에서 아래가 둘 다 들어가 있어야 합니다. - example.com - www.example.com

그리고 어느 쪽이 Primary Domain인지 확인하세요.

실무상 제일 먼저 보는 포인트는 이겁니다:

• 내가 원하는 최종 주소가 Vercel의 Primary Domain과 일치하는가?

예를 들어 최종 주소를 www.example.com 으로 쓰고 싶으면, Vercel에서도 www.example.com 이 primary여야 덜 꼬입니다.

4) 리디렉션을 누가 담당하는지 하나로 통일 이게 제일 중요합니다.

다음 중 하나만 쓰는 게 좋습니다.

권장 방식 - 도메인 canonical 리디렉션: Vercel이 담당 - Cloudflare는 DNS/보안/CDN만 담당

피해야 할 상태 - Cloudflare Redirect Rule에서 www -> non-www - 동시에 Vercel Primary Domain에서 non-www -> www

이렇게 둘 다 리디렉션을 걸면 루프가 생기기 쉽습니다.

즉, 먼저 체크할 질문은 하나입니다.

• www 정규화 리디렉션을 Cloudflare가 하고 있나?
• Vercel도 동시에 하고 있나?

둘 다 켜져 있으면 하나를 끄세요.

5) Cloudflare Redirect Rules / Page Rules / Bulk Redirects 확인 Cloudflare에서 아래를 다 봐야 합니다. - Redirect Rules - Page Rules - Bulk Redirects - Transform Rules(호스트 헤더 관련 커스텀이 있다면)

특히 예전에 만든 규칙이 남아 있으면 문제를 많이 만듭니다.

예:

• example.com/* -> https://www.example.com/$1
• www.example.com/* -> https://example.com/$1

이런 게 동시에 있으면 바로 꼬입니다.

6) SSL 모드 확인: Cloudflare가 Flexible이면 먼저 의심 Cloudflare SSL/TLS 모드가 Flexible이면 리디렉션 꼬임의 단골 원인입니다.

우선 확인:

• Flexible 인가?
• 가능하면 Full 또는 Full (strict) 로 되어 있는가?

Vercel 앞단에서는 Flexible이 특히 불안정합니다. HTTPS 강제와 원본 요청 스킴이 엇갈려서 리디렉션 루프가 생길 수 있습니다.

7) Vercel 쪽 추가 리디렉션 설정 존재 여부 확인 프로젝트 안에 이런 게 있으면 같이 봐야 합니다. - next.config.js / next.config.ts 의 redirects() - vercel.json 의 redirects/rewrites - 미들웨어에서 host 기반 리디렉션

즉,

• Cloudflare 규칙
• Vercel Primary Domain
• 앱 내부 redirect 코드

이 3군데가 서로 같은 방향인지 확인해야 합니다.

8) 실제 응답 헤더로 어디서 리디렉션하는지 추적 텍스트 설정만 보면 헷갈리니, 실제 응답 체인을 보는 게 빠릅니다.

확인 포인트:

• 첫 301/302를 누가 반환하는지
• location 이 어디로 가는지
• 한 번 간 뒤 또 반대로 튀는지

예를 들어 이런 식으로 보면 됩니다.

• http://example.com
• https://example.com
• http://www.example.com
• https://www.example.com

이 4개가 각각 어디로 301/302 되는지 보면, 어느 레이어가 문제인지 바로 드러납니다.

가장 흔한 원인 3개

1. Cloudflare와 Vercel이 서로 다른 canonical을 강제 예: - Cloudflare: www -> apex - Vercel: apex -> www

2. Cloudflare SSL이 Flexible HTTPS 처리 주체가 어긋나서 루프 발생

3. 앱 코드에서도 host redirect를 따로 넣음 특히 Next.js middleware에서 www 정규화를 또 하고 있으면 중복되기 쉽습니다.

실무적으로 가장 빠른 진단 순서

1. 최종 canonical을 정한다 (www 또는 non-www)
2. Vercel Primary Domain이 그 값인지 본다
3. Cloudflare Redirect/Page/Bulk Rules를 전부 훑는다
4. Cloudflare SSL 모드가 Full 또는 Full (strict) 인지 본다
5. 앱 코드(next.config, middleware, vercel.json)에서 host redirect가 있는지 본다
6. 실제 301/302 체인을 확인한다

바로 정리하면 가장 먼저 볼 것은 "www 리디렉션을 Cloudflare와 Vercel이 동시에 하고 있지 않은가" 입니다. 그다음에 DNS 대상, Vercel Primary Domain, Cloudflare SSL 모드를 확인하면 대부분 원인이 바로 좁혀집니다.