티스토리에 개인 도메인을 붙이며 알게 된 것

2026년 8월

티스토리 블로그 두 개에 각각 개인 도메인의 하위 주소를 붙였습니다. misiq-log.tistory.com을 misiq.birchholt.com으로, checkin-directory.tistory.com을 checkin.birchholt.com으로요.

작업 자체는 CNAME 한 줄이면 끝나는 일인데, 시작하기 전에 세운 계획이 틀려 있었습니다. 그리고 붙인 다음에도 예상 못 한 것이 하나 남았습니다. 그 두 가지가 이 글의 내용입니다.

1. “하루 한 번"은 계정당이 아니라 블로그당이었습니다

티스토리 공지에 이런 문장이 있습니다.

개인 도메인은 하루 한 번만 설정할 수 있습니다.

저는 이걸 계정 전체에 걸리는 제한으로 읽었습니다. 그래서 “오늘 하나 붙이고 내일 나머지를 붙이자"고 계획을 세웠습니다. 블로그가 두 개니까 이틀이 걸리는 작업이라고 생각한 것입니다.

그런데 같은 공지의 예시 문장을 다시 읽어보니 이렇게 되어 있었습니다.

abc.com으로 설정하신 후 (…) 당일에 xxx.abc.com 등 다른 도메인으로 변경이 불가

한 블로그가 자기 도메인을 바꾸는 것에 대한 제한이었습니다. 블로그가 다르면 서로 무관합니다. 실제로 같은 날 두 블로그 모두 설정에 성공했습니다.

교훈: 제한 문장을 읽을 때는 무엇에 걸리는 제한인지를 먼저 확정해야 합니다. 계정당인지, 블로그당인지, 도메인당인지에 따라 일정이 통째로 달라집니다. 저는 이걸 확인하지 않아 하루를 더 잡아두고 있었습니다.

2. DNS는 CNAME 한 줄, 단 프록시는 꺼야 합니다

설정한 레코드는 이것뿐입니다.

misiq    CNAME   host.tistory.io
checkin  CNAME   host.tistory.io

문제는 Cloudflare를 DNS로 쓸 때입니다. Cloudflare는 레코드를 추가하면 기본적으로 프록시(주황색 구름)를 켠 상태로 만듭니다. 이 상태로 두면 티스토리의 SSL 인증서 발급이 실패합니다. 인증 기관이 도메인 소유를 확인하러 왔을 때 티스토리 서버가 아니라 Cloudflare가 응답하기 때문입니다.

프록시가 실제로 꺼졌는지는 응답 IP로 확인할 수 있습니다. 티스토리 실서버 대역이 나오면 꺼진 것이고, Cloudflare 대역(104.x, 172.67.x)이 나오면 아직 켜져 있는 것입니다.

$ dig +short misiq.birchholt.com
host.tistory.io.
blog-tistory-xxxxxxxx.kgslb.com.
211.249.222.34          ← 티스토리 실서버. 프록시 OFF 확인

설정 화면에서 회색 구름으로 보이는 것만 믿지 말고 이렇게 한 번 재보는 편이 확실합니다.

CAA 레코드도 미리 봐두면 좋습니다

도메인에 CAA 레코드가 걸려 있으면 특정 인증기관만 인증서를 발급할 수 있습니다. 티스토리는 Let’s Encrypt를 쓰는데, CAA에 그게 빠져 있으면 발급이 막힙니다. 저는 CAA를 아예 설정하지 않은 상태였고(dig CAA 응답 0건), 그래서 차단 요인이 없었습니다. 발급이 계속 안 되면 여기를 의심해볼 만합니다.

3. SSL 발급을 기다리는 동안 건드리면 안 되는 것

DNS 설정을 마치면 티스토리 관리 화면에 “DNS 설정 정보 확인 완료"가 뜨고, 보안 접속 인증서는 발급 대기 상태가 됩니다. 이때 다음 세 가지를 하면 발급이 처음부터 다시 시작되거나 실패합니다.

개인 도메인을 다시 설정하는 것 — 발급 절차가 리셋됩니다
Cloudflare 프록시를 켜는 것 — 위에 적은 이유로 발급이 실패합니다
DNS 레코드를 변경하는 것 — 확인 중이던 값이 바뀝니다

안 되는 것 같아서 이것저것 만지고 싶어지는 구간인데, 여기서는 기다리는 게 맞습니다. 제 경우 두 도메인 모두 다음 날 확인했을 때 발급이 끝나 있었고, curl의 인증서 검증 결과가 0(정상)으로 바뀌어 있었습니다.

$ curl -s -o /dev/null -w "%{http_code} %{ssl_verify_result}\n" https://misiq.birchholt.com/
200 0

4. 남는 문제 — 원래 주소가 사라지지 않습니다

개인 도메인을 붙여도 기존 *.tistory.com 주소가 그대로 살아 있습니다. 리다이렉트되지 않고 똑같이 200을 반환합니다. 같은 글이 두 주소에서 열립니다.

$ curl -s -o /dev/null -w "%{http_code} redirects=%{num_redirects}\n" \
       https://misiq-log.tistory.com/42
200 redirects=0

티스토리가 301 리다이렉트를 지원하지 않기 때문입니다. 검색엔진 입장에서는 같은 내용이 두 주소에 있는 것이라 어느 쪽을 대표로 볼지 애매해집니다.

다만 티스토리가 이 부분은 처리해 두었습니다. 원래 주소로 들어가도 페이지가 스스로를 개인 도메인이라고 선언합니다.

<link rel="canonical" href="https://misiq.birchholt.com/42"/>
<meta property="og:url" content="https://misiq.birchholt.com/42"/>

내부 링크도 전부 개인 도메인을 가리킵니다. 그래서 원래 주소로 들어온 사람도 아무 링크나 누르면 개인 도메인으로 넘어갑니다. 검색 유입은 개인 도메인 쪽으로 모입니다.

다만 완전히 해결된 것은 아닙니다. 옛 링크나 북마크로 원래 주소에 직접 들어오는 경우는 남습니다. 이걸 없앨 방법은 찾지 못했습니다. 티스토리에서 리다이렉트를 설정하는 수단이 없기 때문입니다. 혹시 방법이 있다면 알려주시면 이 글을 고치겠습니다.

정리

항목	확인한 것
하루 1회 제한	계정당이 아니라 블로그당. 블로그가 다르면 같은 날 각각 연결됨
DNS 레코드	`CNAME → host.tistory.io` 한 줄
Cloudflare 프록시	꺼야 함. 응답 IP가 티스토리 대역인지로 검증
CAA 레코드	있으면 Let’s Encrypt 포함 여부 확인. 없으면 차단 요인 없음
SSL 대기 중	재설정·프록시 켜기·레코드 변경 금지
원 주소	200으로 남음. canonical과 내부 링크는 개인 도메인을 가리킴

가장 크게 배운 건 첫 번째입니다. 문서에 적힌 제한을 읽을 때 그게 무엇에 걸리는 제한인지를 확정하지 않으면, 있지도 않은 제약에 맞춰 일정을 짜게 됩니다. 저는 하루를 더 잡아두고 있었고, 실제로 해보고 나서야 알았습니다.

← 다른 기록 보기