문제

Vercel 대시보드에 도메인을 추가하고, 등록대행사에 DNS 레코드 몇 개를 붙여 넣었는데, 지금 빨간 Invalid Configuration이나 한 시간째 “pending”인 인증서를 보고 있습니다. Vercel 프리뷰 URL(your-project.vercel.app)은 멀쩡합니다. 정작 내 도메인은 안 됩니다 — 옛 사이트가 뜨거나, DNS 오류가 나거나, 인증서 경고가 뜹니다. 당신이 건드린 대여섯 가지 중 어느 것이 문제인지 대시보드는 알려주지 않습니다.

멈춘 Vercel 도메인은 거의 전부 세 가지 문제 중 하나이고, 셋은 서로 다른 층에서 실패합니다: 레코드가 엉뚱한 곳을 가리키거나, 변경이 아직 리졸버에 도달하지 못했거나, 인증서가 발급되지 못하는 것입니다. 이 순서대로 점검하면 당신을 물고 있는 하나를 찾습니다.

apex와 www는 서로 다른 레코드가 필요하다 — 바꿔 쓸 수 없다

대부분의 설정이 여기서 틀립니다. 사용자가 입력하는 두 이름이 서로 바꿔도 될 것처럼 보이지만 그렇지 않기 때문입니다.

  • apex — 맨 example.com. Vercel IP를 가리키는 A 레코드가 들어갑니다. 대부분의 프로젝트에서 값은 76.76.21.21이지만, 제 말을 믿지 마세요: 프로젝트 안 도메인 페이지에 Vercel이 당신에게 필요한 정확한 값을 찍어 줍니다. 그걸 쓰세요.
  • www(와 다른 모든 서브도메인). cname.vercel-dns.com을 가리키는 CNAME이 들어갑니다.

이 둘을 뒤집어 apex에 CNAME을 줄 수는 없습니다. DNS 명세는 한 이름에서 CNAME이 다른 레코드와 공존하는 것을 금지하는데, 존 꼭짓점은 SOA와 NS 레코드를 반드시 지녀야 합니다 — 그래서 거기 CNAME은 불법입니다. Vercel의 안내가 비대칭으로 보이는 이유가 바로 이 제약입니다: 루트엔 고정 IP를 줄 수 있는 A 레코드, www엔 트래픽을 조정할 수 있는 CNAME. DNS 제공자가 apex용으로 “ALIAS”, “ANAME”, “CNAME 플래트닝”을 제공한다면 그건 같은 한계에 대한 벤더 우회책이고 역시 괜찮습니다 — 하지만 루트에 평범한 CNAME을 걸면 거부되거나 존의 나머지를 조용히 망가뜨립니다.

레코드를 전혀 편집하지 않는 깔끔한 대안은 도메인의 네임서버를 Vercel 것(이것도 Vercel이 표시합니다 — ns1.vercel-dns.com / ns2.vercel-dns.com)으로 바꾸는 것으로, 존 전체를 Vercel에 넘겨 apex와 www를 대신 관리하게 합니다. 한 방식을 고르세요. 두 방식을 반반씩 섞지 마세요.

“Invalid Configuration”은 판결이 아니라 전파 중이라는 답이다

레코드가 올바르더라도 Vercel은 그걸 봐야 하고, 인터넷의 나머지도 마찬가지입니다. DNS 변경은 저장하는 즉시 적용되지 않습니다 — 리졸버는 TTL이 만료될 때까지 이전 답을 쥐고 있고, 그래서 다 고친 뒤에도 몇 분에서 몇 시간 동안 도메인이 계속 옛 호스트를 보여줄 수 있습니다.

여기 함정 둘:

  • 엉뚱한 곳을 고쳤다. 도메인의 네임서버가 오래전에 외부 DNS 제공자로 바뀌어 있었다면, 방금 등록대행사에서 고친 레코드는 아무도 읽지 않는 사문서입니다. 레코드는 위임이 실제로 가리키는 네임서버에서만 유효합니다. (그게 어디인지 모르겠다면 그건 그것대로 별도 문제입니다: 네임서버·DNS 제공자 확인하는 법 참고.)
  • 현실이 아니라 패널을 보고 있다. 등록대행사 패널에 올바른 값이 보인다고 리졸버가 아직 그걸 돌려준다는 뜻은 아닙니다. 설정이 깨졌다고 결론짓기 전에 전 세계에서 실제로 뭐가 해석되는지 확인하세요 — 전파 중인 올바른 레코드는 Vercel 대시보드에선 없는 레코드와 똑같아 보입니다.

Vercel은 스스로 다시 확인하고, 올바른 답이 전파되는 순간 Valid Configuration으로 바뀝니다. 레코드가 정말로 맞다면 이건 고칠 문제가 아니라 기다릴 문제입니다.

SSL은 저절로 발급된다 — 챌린지를 막는 게 없다면

Vercel은 당신 도메인용 무료 인증서(Let’s Encrypt)를 자동으로 요청합니다. 당신이 생성하거나 업로드할 건 없습니다. 하지만 도메인이 Vercel로 해석되고 동시에 발급 챌린지가 완료될 수 있을 때만 발급됩니다. DNS가 그 외엔 올바른데도 인증서를 “pending”으로 붙잡아 두는 두 가지:

  • CA를 허가하지 않는 CAA 레코드. 도메인에 CAA 레코드가 있다면, 그건 어느 인증 기관이 당신을 위해 발급할 수 있는지에 대한 허용 목록입니다. 거기에 Let’s Encrypt가 없으면 CA는 거부할 의무가 있고 — 당신 인증서는 조용히 발급되지 않습니다. CAA 레코드를 지우거나 letsencrypt.org 항목을 추가하세요.
  • 앞단에 앉은 프록시. Cloudflare(혹은 유사) 레코드를 proxied / 주황 구름으로 둔 경우 연결을 가로채, 챌린지가 Vercel 대신 프록시에 닿습니다. 설정 중에는 레코드를 DNS-only로 두세요. 프록시는 나중에 다시 고려할 수 있지만, Vercel이 도메인을 검증하는 동안은 안 됩니다.

DNS가 Vercel을 가리키고, 적대적 CAA가 없고, 길을 막는 프록시가 없으면 인증서는 몇 분 안에 발급됩니다.

DechoNet으로 진단

  • DNS 조회는 apex의 A 레코드와 www의 CNAME을 권위 네임서버에서 그대로 읽어와, 패널에 입력했다는 사실이 아니라 실제로 Vercel IP와 cname.vercel-dns.com을 가리키는지 확인합니다. 인증서를 막을 수 있는 CAA 레코드도 보여줍니다.
  • 전파 확인은 전 세계 리졸버가 새 레코드를 아직 돌려주는지 보여줘, “내 설정이 깨졌다”와 “옛 TTL이 만료되길 기다려야 한다”를 가릅니다.
  • SSL 확인은 도메인이 Vercel로 해석된 뒤, apex와 www 양쪽에 유효한 인증서가 실제로 발급돼 제공되는지 확인합니다 — 브라우저 경고를 끄는 마지막 단계입니다.

점검 체크리스트

  • apex(example.com)에 Vercel이 도메인 페이지에 표시한 정확한 값(보통 76.76.21.21)으로 A 레코드 — CNAME 아님.
  • www에 cname.vercel-dns.com으로 CNAME(또는 도메인 전체를 Vercel 네임서버로 위임 — 둘 다가 아니라 한 방식).
  • 도메인의 네임서버가 실제로 가리키는 제공자에서 DNS를 편집하고 있는지 — 더 이상 권위가 없는 등록대행사 패널이 아니라.
  • 전파 확인에서 리졸버가 새 레코드를 돌려주는지 — 아니라면 설정은 맞는데 전파 중일 수 있음.
  • CAA 레코드가 CA를 막지 않는지(지우거나 letsencrypt.org 허용), Vercel 앞단에 proxied로 남은 레코드가 없는지.
  • DNS가 올바른 뒤, SSL 확인에서 apex와 www 양쪽에 유효한 인증서가 보이는지.

이럴 땐 넘기세요

  • DNS가 어디서나 Vercel로 올바르게 해석되는데 옛 TTL이 완전히 만료된 뒤에도 대시보드가 여전히 Invalid Configuration이라면, Vercel에서 도메인을 다시 추가해 새 확인을 강제해 볼 만합니다 — DNS 문제가 아니라 낡은 검증 상태입니다.
  • DNS가 올바르고 CAA도 프록시도 없는데 인증서가 pending에 머무른다면, 차단은 발급 쪽에 있습니다 — 이미 맞는 레코드를 다시 편집하지 말고 Vercel 도메인 페이지에서 구체적 챌린지 오류를 확인하세요.
  • apex를 Vercel로 가리키려는데 DNS 제공자가 루트에 A/ALIAS 옵션을 아예 제공하지 않는다면, 맨 도메인을 거기서 호스팅할 수 없습니다 — apex 레코드를 지원하는 제공자(또는 Vercel 자체 네임서버)로 DNS를 옮기거나, www에서 사이트를 제공하고 apex를 거기로 리다이렉트하세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.