티스토리에 개인 도메인을 붙이며 알게 된 것
주제가 다른 티스토리 블로그를 두 개 쓰고 있어서, 가지고 있는 도메인 하나의
하위 주소를 각각 붙였습니다. 블로그마다 도메인을 따로 사는 대신
한 도메인 밑으로 모은 것입니다.
misiq-log.tistory.com을 misiq.birchholt.com으로,
checkin-directory.tistory.com을 checkin.birchholt.com으로요.
작업 자체는 CNAME(내 주소를 티스토리 주소에 이어 붙이는 설정) 한 줄이면 끝나는 일인데 시작하기 전에 세운 계획이 틀려 있었고 붙인 다음에도 예상 못 한 것이 하나 남았습니다. 이 글에는 그 두 가지를 적었습니다.
1. “하루 한 번"은 계정당이 아니라 블로그당이었습니다
티스토리 공지에 이런 문장이 있습니다.
개인 도메인은 하루 한 번만 설정할 수 있습니다.
저는 이걸 계정 전체에 걸리는 제한으로 읽었습니다. 그래서 “오늘 하나 붙이고 내일 나머지를 붙이자"고 계획을 세웠습니다. 블로그가 두 개니까 이틀이 걸리는 작업이라고 생각한 것입니다.
그런데 같은 공지의 예시 문장을 다시 읽어보니 이렇게 되어 있었습니다.
abc.com으로 설정하신 후 (…) 당일에 xxx.abc.com 등 다른 도메인으로 변경이 불가
한 블로그가 자기 도메인을 바꾸는 것에 대한 제한이었습니다. 블로그가 다르면 서로 무관합니다. 실제로 같은 날 두 블로그 모두 설정에 성공했습니다.
인용한 두 문장은 티스토리 공지 「보안 인증서 발급 속도가 개선되었습니다」(2023-12-06)의 「참고」 항목에 있습니다. 2026-09-22에 다시 열어 같은 문구가 그대로 남아 있는 것을 확인했습니다. 원문은 「예를 들어, abc.com으로 설정하신 후 보안 인증서 발급까지 완료된 경우, 당일에 xxx.abc.com 등 다른 도메인으로 변경이 불가합니다」입니다.
교훈: 제한 문장을 읽을 때는 무엇에 걸리는 제한인지를 먼저 확정해야 합니다. 계정당인지, 블로그당인지, 도메인당인지에 따라 일정이 통째로 달라집니다. 저는 이걸 확인하지 않아 하루를 더 잡아두고 있었습니다.
2. DNS는 CNAME 한 줄, 단 프록시는 꺼야 합니다
설정한 레코드는 이것뿐입니다.
misiq CNAME host.tistory.io
checkin CNAME host.tistory.io
Cloudflare를 DNS(도메인 주소를 실제 서버로 안내하는 전화번호부)로 쓸 때 문제가 생깁니다. Cloudflare는 레코드를 추가하면 기본적으로 프록시를 켠 상태로 만듭니다. 주황색 구름으로 표시되는 이 프록시는 방문 요청을 Cloudflare가 대신 받아 넘겨주는 기능입니다.
이 상태로 두면 티스토리가 도메인 소유를 확인하려고 DNS를 조회했을 때 설정이 제대로 읽히지 않습니다. 그래서 도메인 연결과 티스토리의 SSL 인증서(주소창 자물쇠가 뜨는 암호화 접속용 증명서) 발급이 넘어가지 않습니다.
티스토리 공식 문서에서는 프록시를 언급한 대목을 찾지 못했습니다. 프록시를 켜면 티스토리가 도메인 설정 정보를 인식하지 못한다는 설명은 같은 조합을 다룬 외부 해설에서 확인했고(romantech.net/1309, 2026-09-22 본문 확인), 제가 직접 확인한 것은 프록시를 끈 상태에서 두 도메인 모두 발급이 끝났다는 데까지입니다. 프록시를 켜 놓고 실패하는 것을 재현해 보지는 않았습니다.
프록시가 실제로 꺼졌는지는 응답 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 확인
설정 화면에서 회색 구름으로 보이는 것만 믿지 말고 이렇게 한 번 재보는 편이 확실합니다.
다만 위 예시의 IP는 잰 시점의 값일 뿐 고정값이 아닙니다. 같은 주소를 연달아 재도, 쓰는 DNS
해석기를 바꿔도 211.249.222.34 와 27.0.236. 으로 시작하는 값이 번갈아 나왔습니다.
티스토리는 응답 IP가 하나가 아닙니다. 그래서 특정 IP를 외워두고 맞춰보는 대신
Cloudflare 대역인지 아닌지만 보면 됩니다.
Cloudflare는 프록시가 쓰는 IP 대역을 공개해 둡니다 —
cloudflare.com/ips-v4에 104.16.0.0/13·104.24.0.0/14·
172.64.0.0/13 등이 들어 있습니다(2026-09-22 확인). 티스토리 쪽 IP가 바뀌어 온 이력은 공지
「개인 도메인을 A레코드로 관리 중이라면 DNS를 변경해 주세요」에
남아 있습니다 — 서버 교체로 IP가 바뀌니 A레코드 대신 CNAME을 쓰라는 안내입니다.
IP 측정은 2026-09-22 dig +short입니다 — 같은 이름을 연달아 다섯 번, 해석기를 바꿔
(@8.8.8.8·@1.1.1.1·@168.126.63.1·@9.9.9.9) 네 번 쟀고 두 값이 섞여 나왔습니다.
두 블로그의 CNAME 종착점은 blog-tistory-l51ybqnn.kgslb.com 으로 같았습니다.
CAA 레코드도 미리 봐두면 좋습니다
도메인에 CAA 레코드가 걸려 있으면 거기 적어둔 인증기관만 그 도메인의 인증서를 발급할 수 있습니다.
제 도메인에 발급된 인증서는 발급 기관이 Let’s Encrypt였습니다.
그러니 CAA를 쓰면서 여기에 Let’s Encrypt를 빠뜨리면 발급이 막히게 됩니다.
저는 CAA를 아예 설정하지 않은 상태여서(dig CAA 응답 0건)
차단 요인이 없었습니다. 발급이 계속 안 되면 여기를 의심해볼 만합니다.
발급 기관은 openssl s_client로 직접 확인했습니다 —
issuer= /C=US/O=Let's Encrypt/CN=YE1, 유효기간 2026-08-25 ~ 2026-11-23(2026-09-22 측정).
티스토리가 모든 블로그에 늘 같은 기관을 쓴다고 밝혀 둔 문서는 찾지 못했으니,
CAA를 손보기 전에 자기 도메인에서 한 번 재보는 편이 안전합니다.
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
2026-09-22에 같은 명령을 다시 보내도 두 도메인 모두 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 리다이렉트(옛 주소로 온 사람을 새 주소로 영구히 넘겨주는 기능)를 켜는 자리가 없습니다. 제가 못 찾은 것일 수도 있지만, 스킨에 직접 넣어 흉내 내는 쪽은 권하지 않습니다 — 티스토리는 다른 사이트로 강제 전환하는 것을 「사이트 납치」로 보고 규제 대상이라고 공지해 두었습니다. 검색엔진 입장에서는 같은 내용이 두 주소에 있는 것이라 어느 쪽을 대표로 볼지 애매해집니다.
티스토리 공지 「다른 사이트로 강제 전환 금지 안내」 — 「다른 사이트로 강제 전환하는 것은 사이트 납치로 간주되어 바로 규제될 수 있으니 코드를 수정하거나 제거해 주시기 바랍니다」(2026-09-22 본문 확인). 이 공지는 무효 클릭 방지 코드에서 나온 사례를 다루고 있고 자기 개인 도메인으로 넘기는 경우를 콕 집어 말하지는 않습니다. 다만 규제되면 블로그 접근 자체가 막히는 쪽이라 저는 시도하지 않았습니다.
다만 티스토리가 이 부분은 처리해 두어서 원래 주소로 들어가도
페이지가 스스로를 개인 도메인이라고 선언합니다.
아래 canonical 이 그 선언인데, 이 주소가 원본이라고 검색엔진에 알려주는 표시입니다.
<link rel="canonical" href="https://misiq.birchholt.com/42"/>
<meta property="og:url" content="https://misiq.birchholt.com/42"/>
내부 링크도 전부 개인 도메인을 가리킵니다. 그래서 원래 주소로 들어온 사람도 아무 링크나 누르면 개인 도메인으로 넘어갑니다. 검색 유입은 개인 도메인 쪽으로 모이게 됩니다.
센 방법 — 원래 주소로 열리는 글 페이지의 HTML을 받아 href의 호스트를 전부 뽑아
세었습니다. 블로그 안으로 돌아오는 링크는 전부 개인 도메인이었고 tistory.com 호스트는
0건이었습니다. 나머지는 스타일시트·파비콘·글꼴 같은 리소스 주소입니다(2026-09-22 측정).
canonical과 og:url도 같은 날 같은 페이지에서 확인했습니다.
옛 링크나 북마크로 원래 주소에 직접 들어오는 경우가 남아 있어 완전히 해결된 것은 아닙니다. 티스토리에서 리다이렉트를 설정하는 수단이 없어서 이걸 없앨 방법은 찾지 못했습니다. 혹시 방법이 있다면 알려주시면 이 글을 고치겠습니다.
정리
| 항목 | 확인한 것 |
|---|---|
| 하루 1회 제한 | 계정당이 아니라 블로그당. 블로그가 다르면 같은 날 각각 연결됨 |
| DNS 레코드 | CNAME → host.tistory.io 한 줄 |
| Cloudflare 프록시 | 꺼야 함. 응답 IP가 Cloudflare 대역이 아닌지로 검증 |
| CAA 레코드 | 있으면 Let’s Encrypt 포함 여부 확인. 없으면 차단 요인 없음 |
| SSL 대기 중 | 재설정·프록시 켜기·레코드 변경은 손대지 않음 |
| 원 주소 | 200으로 남음. canonical과 내부 링크는 개인 도메인을 가리킴 |
첫 번째에서 가장 크게 배웠습니다. 저는 문서에 적힌 제한을 읽으면서 그게 무엇에 걸리는 제한인지를 확정하지 않았습니다. 있지도 않은 제약에 맞춰 일정을 짜고 하루를 더 잡아두었다는 건 실제로 해보고 나서야 알았습니다.