문제

도메인을 티스토리에 연결했는데 뭔가 어긋납니다. 블로그가 여전히 *.tistory.com 주소로 뜨거나, 브라우저가 인증서 경고를 내거나, 티스토리 관리 화면이 계속 “도메인을 확인할 수 없다”고 합니다. DNS 레코드는 보기엔 맞습니다. 실제로도 대개 맞습니다 — 문제는 레코드의 오타가 아니라 어떤 이름을 연결했는지, 그리고 언제 연결했는지입니다.

증상

  • 티스토리 개인 도메인 설정 화면이 “도메인 설정 정보를 확인할 수 없습니다”에서 확인 완료로 넘어가지 않습니다.
  • 도메인은 해석되는데 브라우저가 인증서 불일치 경고를 냅니다 — 흔히 www에서만 또는 맨 루트에서만, 둘 다는 아닙니다.
  • example.com으로 들어온 방문자는 오류를 보는데 www.example.com은 되거나, 그 반대입니다.
  • 몇 주 동안 멀쩡하다가 어느 날 HTTPS가 저절로 깨졌습니다.

티스토리 개인 도메인이 실제로 작동하는 방식

움직이는 부품이 둘인데, 사람들이 이 둘을 뒤섞습니다.

DNS 쪽은 CNAME 하나입니다: 내 호스트명 → host.tistory.io. 이 레코드가 전 세계 리졸버에게 “이 이름으로 오는 트래픽은 티스토리 정문으로 간다”고 알립니다. 이 레코드는 티스토리 안이 아니라, 내 네임서버가 가리키는 DNS 제공자(등록기관 또는 DNS 호스트) 패널에 있습니다.

티스토리 쪽은 관리 → 블로그 → 개인 도메인 설정에서 하는 연결입니다. 정확한 도메인을 입력하면 티스토리가 그 이름의 CNAME이 이미 자기를 가리키는지 확인합니다. 확인되면 티스토리가 그 호스트명에 대한 HTTPS 인증서를 자동 발급합니다. 인증서 파일은 손댈 일이 없습니다.

순서가 중요하고, 대부분 여기서 넘어집니다: DNS 먼저, 티스토리 나중. 티스토리는 이미 존재하고 전파된 레코드에 대고 확인합니다. CNAME이 살아나기 전에 티스토리에서 연결하면 확인할 게 아무것도 안 보입니다.

그리고 인증서는 정확히 호스트명 하나 — 입력한 문자열 — 에 대해 발급됩니다. 이 한 가지 사실이 아래 “HTTPS가 깨졌다” 대부분의 원인입니다.

주요 원인 3가지

  1. 루트 도메인에 CNAME을 넣으려 했다. example.com은 존 apex이고, apex는 이미 SOA·NS 레코드를 갖고 있습니다. RFC 1034 §3.6.2는 CNAME이 있는 이름은 다른 레코드를 가질 수 없다고 규정합니다 — 그래서 apex의 일반 CNAME은 불법이고, 대부분의 DNS 패널은 이를 거부하거나 조용히 메일까지 망가뜨립니다. 단서: www는 잘 연결되는데 맨 루트만 안 됩니다. 해법은 서브도메인(www)을 쓰거나, apex에서 ALIAS/ANAME/CNAME 플래트닝을 제공하는 제공자를 쓰는 것입니다.
  2. www와 루트가 어긋나 한쪽에 인증서가 없다. 티스토리는 연결한 이름 하나에만 인증서를 발급했습니다. 등록하지 않은 다른 형태는 맞는 인증서가 없어, 누가 방문하는 순간 경고를 냅니다. 단서: 한 형태는 자물쇠가 멀쩡하고 다른 형태는 깨져 있습니다. 해법은 두 번째 연결이 아니라, 모든 방문자를 연결한 형태로 보내는 301 리다이렉트입니다.
  3. 기다리지 않았거나, 순서가 틀렸다. DNS 변경은 전파에 시간이 걸립니다 — 보통 몇 분이지만 기존 TTL에 따라 24~48시간까지도 갑니다. CNAME이 전파되기 전에 티스토리에서 연결하면 확인이 실패하고, 확인 몇 초 뒤에 HTTPS를 테스트하면 인증서가 아직 발급 전일 수 있습니다. 단서: “안 되는데” 실제로 잘못 설정된 건 없습니다 — 그냥 이른 겁니다.

DechoNet으로 진단

  • DNS 조회 — 내 호스트명이 실제로 host.tistory.io로 향하는 CNAME을 반환하는지 확인하고, apex가 갖고 있으면 안 되는 걸 물고 있진 않은지 봅니다. 패널이 “설정했다”고 말하는 것이 아니라 리졸버가 보는 것을 가장 빨리 확인하는 방법입니다.
  • DNS 전파 확인 — 전 세계 여러 리졸버에 한 번에 질의해, 레코드를 다시 고치기 전에 “안 됨”이 사실은 “아직 전파 전”인지 판별합니다.
  • SSL 확인 — HTTPS가 살아났어야 할 때, 인증서가 방문자가 실제로 치는 정확한 호스트명을 커버하는지 확인하고 www-루트 불일치를 바로 짚습니다.

해결 체크리스트

  • 표준 형태를 먼저 하나 정하세요 — www.example.com 아니면 맨 루트 — 그리고 그것만 밀고 나갑니다.
  • DNS 패널에서 그 호스트명에 CNAME을 추가하고 값을 **host.tistory.io**로 지정합니다. 서브도메인이면 이것만으로 됩니다.
  • 굳이 맨 루트를 쓰려면 제공자의 ALIAS/ANAME/CNAME 플래트닝으로 apex를 host.tistory.io로 향하게 하세요. 그 자리의 일반 CNAME은 무효입니다.
  • DNS 전파 확인을 돌려 CNAME이 여러 리졸버에서 보일 때까지 기다린 뒤에야 티스토리를 만지세요.
  • 티스토리에서 관리 → 블로그 → 개인 도메인 설정으로 가서, 설정한 정확한 호스트명을 입력하고 확인을 받습니다(느리면 새로 고침 버튼).
  • 다른 형태(루트→www 또는 www→루트)에서 301 리다이렉트를 걸어, 모든 방문자가 인증서가 있는 그 한 호스트명으로 도착하게 합니다.
  • 확인 뒤 HTTPS 발급에 시간을 준 다음, 표준 호스트명에 대고 SSL 확인을 돌립니다.

이럴 땐 넘겨야 한다

  • CNAME이 확인됐고, 전파됐고, host.tistory.io를 가리키는데도 충분히 기다린 뒤 HTTPS가 여전히 안 올라오면, 이건 내 DNS가 아니라 티스토리의 인증서 발급 문제입니다. 관리 화면에서 도메인을 연결 해제했다가 다시 연결하는 것이 흔한 리셋이고, 그 이상은 내가 고칠 레코드가 아니라 카카오/티스토리 지원의 몫입니다.
  • 등록기관이 www에 CNAME을 아예 못 넣게 막으면, 지금 편집 중인 패널의 DNS 제공자로 네임서버가 실제로 향하고 있는지 확인하세요. 존의 권위 서버가 아닌 호스트에서 레코드를 편집하면 리졸버가 볼 수 있는 건 아무것도 바뀌지 않습니다.

내 도메인에서 바로 확인

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