바쁘니

티스토리에 개인 도메인을 붙이는 건 어렵지 않습니다. 문제는 그 구조가 나중에 무엇을 제약하는지입니다.저는 다 붙이고 나서야 알았습니다.결론부터 — 세 가지 제약제약내용블로그 1개 = 도메인 1개서브도메인을 쓰려면 블로그를 새로 만들어야 한다CNAME 방식루트 도메인에 걸면 MX·TXT를 함께 쓸 수 없다인증서 발급 주체가 티스토리내가 통제할 수 없다붙이기 전에 이것만 알고 시작하면 나중에 고생을 덜 합니다.1. 연결 방식은 CNAME입니다티스토리 개인 도메인은 이렇게 겁니다.CNAME blog host.tistory.ioA 레코드(IP 직접 지정)가 아니라 CNAME(별칭) 입니다. 서버 IP가 바뀌어도 티스토리 쪽에서 알아서 처리되므로 운영자 입장에선 편합니다.문제는 루트 도메인(example..

"주소를 바꿨으니 예전 주소로 들어오면 새 주소로 보내야지."방법이 여럿인데 겉으로는 다 똑같아 보입니다. 브라우저에서는 전부 새 페이지로 넘어가니까요.그런데 검색엔진이 받아들이는 방식은 전혀 다릅니다.결론부터방식응답검색엔진주소 표시줄쓸 곳301HTTP 301색인 이전새 주소영구 이전302HTTP 302기존 주소 유지새 주소임시 점검·A/B308 / 307HTTP 308/307301/302와 유사새 주소POST 유지해야 할 때meta refreshHTTP 200취급이 불확실새 주소권장하지 않음프레임(마스킹)HTTP 200이전 안 됨옛 주소 그대로피할 것주소를 영구히 옮겼다면 301입니다. 나머지는 목적이 다릅니다.301과 302의 차이301 Moved Permanently302 Found뜻"여기 영구히 ..

블로그에 글이 실제로 몇 개인지, 검색엔진이 뭘 보고 있는지 확인하려면 `sitemap.xml`을 보면 됩니다.**로그인하지 않고 밖에서** 알 수 있습니다.## 결론부터```bash# URL 개수 세기curl -s https://example.com/sitemap.xml| grep -c ''# 실제 주소 보기curl -s https://example.com/sitemap.xml | grep -o '[^' | sed 's/]*>//g'```사이트맵은 **"이 사이트에 이런 페이지들이 있다"고 검색엔진에 알려주는 목록**입니다.대부분의 블로그 서비스가 자동으로 만들어 줍니다.## 함정 — 숫자를 그대로 믿으면 안 됩니다### 1) 시스템 URL이 섞여 있습니다블로그 서비스는 글이 하나도 없어도 이런 주소들..

요즘 인증서는 대부분 자동 갱신됩니다. 그래서 실패해도 아무도 모릅니다.발급 당시엔 멀쩡하니, 만료일 당일에 사이트가 죽고 나서야 알게 됩니다.결론부터# 만료일 확인 — 이거 하나만 주기적으로 돌리면 됩니다echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -subject -datessubject=CN = example.comnotBefore=Sep 7 17:01:45 2026 GMTnotAfter=Dec 6 17:01:44 2026 GMTLet's Encrypt 인증서는 유효기간이 90일입니다. 자동 갱신을 전제로 한 설계입니다갱신은 만료 전에 미리 일어납..

"브라우저에서는 되는데 왜 안 된다고 하지?"사이트 문제를 브라우저로 확인하면 캐시, 자동 재시도, 인증서 예외 처리 때문에 실제와 다르게 보입니다. curl은 그런 보정 없이 서버가 실제로 뭘 주는지 그대로 보여줍니다.결론부터 — 이 다섯 개면 대부분 잡힙니다curl -s -o /dev/null -w '%{http_code}\n' https://example.com/ # ① 살아있나curl -sI https://example.com/ | grep -i location # ② 어디로 보내나curl -s ... vs curl -sk ... # ③ 인증서 문제인가curl --resolve example...

도메인을 바꿨는데 반영이 안 되거나, 접속이 되다 안 되다 할 때 dig를 씁니다.옵션이 많지만 실무에서 실제로 치는 건 다섯 가지 정도입니다.결론부터 — 이 다섯 개면 됩니다dig +short A example.com # ① 어디를 가리키나dig +short NS example.com # ② 네임서버가 어디인가dig @ns.example-dns.com example.com A +short # ③ 캐시 무시하고 진짜 값dig example.com ANY +noall +answer # ④ 레코드 전체 보기dig +short -x 1.2.3.4 ..

브라우저에서 "이 사이트는 안전하지 않습니다"가 뜨거나, curl이 아무 응답 없이 실패할 때가 있습니다.서버에 인증서가 없는 게 아니라 "엉뚱한 인증서"가 응답하는 경우가 많습니다.원인은 대개 셋 중 하나이고, 명령어 한 줄로 구분됩니다.결론부터echo | openssl s_client -connect 도메인:443 -servername 도메인 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates이 한 줄로 누구 이름의 인증서인지, 언제까지인지, 누가 발급했는지가 나옵니다.증상subject 확인 결과원인만료 오류내 도메인 이름은 맞는데 notAfter가 지났다① 만료이름 불일치전혀 다른 이름이 나온다② 이름 불일치특정 기기만 오류subject는 맞..

도메인 설정을 바꿨는데 접속 결과가 404였다가 200이었다가 연결 실패였다가 했습니다.캐시 문제인 줄 알았는데 아니었습니다. DNS 레코드 두 개가 충돌하고 있었습니다.결론부터CNAME 레코드는 같은 이름에 다른 레코드와 함께 존재할 수 없습니다. DNS 규격입니다.그런데 관리 화면에서는 두 개가 나란히 등록되기도 합니다. 그러면 이렇게 됩니다.example.com. 600 IN A 121.254.x.x ← 새로 추가한 것example.com. 600 IN CNAME host.example.net. ← 예전에 있던 것이 상태에서는 조회하는 리졸버마다 다른 답을 줍니다. 어떤 곳은 A를 따라가고 어떤 곳은 CNAME을 따라갑니다. 내 브라우저에서는 되는데 다른 데서는 ..