통계를 티스토리 서브도메인까지 덮으려다 — 아직 못 덮었습니다

2026년 9월 · 2026년 9월 갱신

apex(birchholt.com) 아래에 티스토리 블로그 두 개를 서브도메인으로 붙여 운영합니다. 통계는 셋을 한 대시보드에서 보려 했습니다. Cloudflare Web Analytics 는 같은 apex 면 site tag 하나를 재사용할 수 있어서, 토큰 하나면 끝날 줄 알았습니다.

결과부터 적습니다. 아직 못 덮었습니다. apex 는 잡히는데 티스토리 쪽은 비콘이 404 로 떨어집니다. 후보를 둘 잘라냈고, 셋째는 아직 확인하지 못했습니다.

먼저 틀렸던 것 — 토큰이 비어 있는데 통계는 쌓이고 있었습니다

2026-09-01 에 비콘 자리만 만들고 cfAnalyticsToken 은 비워뒀으니, apex 통계도 아직 0 일 거라고 생각했습니다.

2026-09-02 에 대시보드를 열어보니 birchholt.com 이 8일 전부터 Automatic setup 으로 등록돼 있었고, 최근 24시간 기준 20 PV / 6 visits 가 이미 쌓여 있었습니다. 라이브 HTML 을 브라우저 UA 로 받아 </body> 직전을 봤더니 저장소에 없는 태그가 있었습니다.

<script type="module"
  src=".../beacon.min.js/v3d52b479..."
  integrity="sha512-d9sL6GJLXn6..."
  data-cf-beacon='{"token":"732288da...","r":1}'></script>

	자동 주입	수동 삽입
스크립트 URL	버전 고정 URL + SRI 동반	버전 없는 `beacon.min.js` → SRI 불가
`type="module"`	자동 부착	직접 부착
닿는 범위	프록시를 지나는 요청만	HTML 에 넣은 곳 전부

type="module" 은 수동일 때 빼먹으면 안 됩니다. 공식 문서 원문입니다.

“For customers using the manual embed approach, you will need to add type="module" to the <script> tag manually.”

module 은 기본이 defer 라 defer 속성은 붙이지 않았고, minify 를 거친 뒤에도 살아 있는 것을 렌더 결과로 확인했습니다.

티스토리에는 자동 주입이 닿지 않습니다

티스토리에 개인 도메인을 붙이려면 Cloudflare 프록시를 꺼야 합니다(앞선 글에 적었습니다). 프록시가 꺼져 있으면 요청이 Cloudflare 를 통과하지 않고, 응답 HTML 을 만질 주체가 없습니다.

그래서 각 스킨의 </body> 직전에 같은 토큰으로 비콘을 직접 넣었습니다. 재사용해도 되는 값과 안 되는 값의 대비는 다른 글에 적었습니다.

여기서 막혔습니다. 비콘이 쏘는 https://cloudflareinsights.com/cdn-cgi/rum 이 POST 404 를 돌려줍니다.

메서드로 1번을, 토큰으로 2번을 잘라냈습니다

404 하나를 놓고 의심할 것이 셋이었습니다.

이 호스트명이 사이트에 등록되지 않았다
토큰이 틀렸거나 서브도메인에 안 먹는다
수집 경로 자체가 이 사이트에서 안 열려 있다

셋을 한 번에 볼 수 없으니 한 번에 하나씩만 바꿔 쐈습니다(방법은 앞선 글에서 데면서 배운 것입니다). 쏜 호스트는 misiq 하나입니다 — checkin 은 같은 스니펫이라 같을 것으로 봤고 따로 쏘지는 않았습니다.

curl -i -X OPTIONS https://cloudflareinsights.com/cdn-cgi/rum \
  -H 'Origin: https://misiq.birchholt.com' \
  -H 'Access-Control-Request-Method: POST'
# → 200
# → access-control-allow-origin: https://misiq.birchholt.com

200 이고, access-control-allow-origin 에 제 서브도메인이 그대로 실려 옵니다. preflight 에는 토큰이 실리지 않으니 이 응답은 토큰과 무관합니다. 등록되지 않은 호스트라면 이렇게 되돌려줄 이유가 없다고 봤습니다 — 다만 요청 Origin 을 그대로 되비추는 구현도 있어서 이것만으로 확정은 아닙니다. 호스트명 등록과 postfix 매칭은 정상으로 보고 1번을 내렸습니다. 같은 주소에서 OPTIONS 만 200, POST 만 404 라면 라우팅이 없는 게 아니라 뒤의 수집 핸들러가 안 열린 것입니다.

다음은 토큰만 바꿨습니다. 아무 값이나 넣어도 진짜 토큰과 똑같이 404 였습니다. 토큰이 원인이면 응답이 달라야 합니다. 같다는 건 애초에 토큰을 보지 않고 끊는다는 뜻입니다(2번 탈락).

바꾼 축	고정한 것	결과	읽히는 것
메서드 → OPTIONS	URL·Origin(토큰 없음)	200 + ACAO 에 내 서브도메인	호스트 등록·매칭 정상으로 추정
토큰 → 가짜 값	URL·메서드·본문 형식	404(진짜와 동일)	토큰을 보지 않음
URL 3종(bare·`?token=`·끝 슬래시)	메서드·토큰	전부 404	주소 오타 아님

요청 형태는 beacon.min.js 원본에 맞췄습니다 — content-type: application/json, payload 키는 siteToken, 성공 시 204 기대(sendObjectBeacon 구현 확인). 보내는 쪽 문제는 아닙니다.

남은 가설은 하나인데, 아직 확인하지 못했습니다

남은 3번은 사이트가 Automatic setup 이라 수동 수집 경로가 열려 있지 않다는 가설입니다. 자동은 자기 도메인의 /cdn-cgi/rum 으로 쏘고 프록시가 그 자리에서 처리합니다. 수동은 cloudflareinsights.com 으로 쏘는데, 티스토리는 수동밖에 못 씁니다.

대시보드 Manage site 에서 「Enable with JS Snippet installation」 으로 바꾸면 풀릴 것으로 봅니다. 다만 미확정입니다 — 아직 안 바꿔봤습니다.

모드를 바꾸는 순간 자동 주입이 멈추므로, apex 토큰을 채워 배포하는 쪽을 먼저 하고 전환을 나중에 두기로 했습니다. 반대로 하면 그 사이 apex 통계가 빌 수 있다고 봤습니다.

이 순서 논증은 아직 검증하지 못했습니다. 구멍이 둘 보입니다. 하나, 3번 가설이 맞다면 미리 배포해둔 apex 의 수동 비콘도 전환 전까지는 똑같이 404 라 공백을 못 메웁니다. 둘, 제 템플릿에서 수동 스니펫은 <head> 에 들어가고 자동 주입 태그는 </body> 직전에 들어갑니다 — 문서 순서로는 수동이 먼저 실행됩니다. 아래 줄이 정말 두 번째 실행을 막는 것이라면, 막히는 쪽이 멀쩡히 돌던 자동 비콘일 수 있습니다.

중복 집계가 날까 싶어 beacon.min.js 를 열었을 때 눈에 걸린 줄입니다.

if(v&&"single"===v.load)return;

가드처럼 보여서 겹치는 상태로 배포하기로 했습니다. 다만 v 가 어디서 채워지고 load 를 누가 "single" 로 세팅하는지까지는 못 짚었고, 두 태그가 실제로 한 번만 집계되는지도 대시보드로 확인하지 못했습니다.

정리

자동 설정은 프록시가 있어야 닿습니다. 프록시를 끈 티스토리에는 안 들어갑니다
가짜 값과 진짜 값의 응답이 같으면, 그 값은 판정에 쓰이지 않는 것입니다
배포 순서를 정한 근거가 아직 미확인인 가설에 기대고 있으면 그 순서도 검증된 게 아닙니다
남은 가설은 아직 확인하지 못했습니다. 지금 대시보드에 잡히는 것은 apex 뿐입니다

← 다른 기록 보기