증상: 피드는 되는데 영상·라이브만 멈출 때
TikTok 클라이언트와 웹은 한 화면 안에서도 단계별로 백엔드를 부릅니다. 추천·검색·프로필·댓글·계정 동기화 같은 API 트래픽, 썸네일·아이콘·번들 자산을 끌어오는 CDN, 그리고 실제 숏폼 조각·적응형 스트림·라이브 방송에 붙는 미디어 엣지까지 도메인이 갈라집니다. 그중 일부만 원하는 정책 그룹을 타고 나머지가 느린 직접 회선이나 다른 지역 출구에 남으면 썸네일·텍스트는 빠른데 영상만 끝없이 돌거나, 특정 탭·라이브룸만 열리지 않는 패턴이 납니다. 전역 프록시로 모두 밀어 넣으면 다른 앱과 대역을 나눠 쓰고, 반대로 tiktok.com만 프록시에 두고 미디어·이미지용 접미사를 빠뜨리면 TLS는 열려도 세션이 엇갈려 무한 로딩이 반복됩니다. 규칙·분류 모범 사례에서 말한 것처럼 위에서 아래로 읽히는 한 줄이 먼저 잡아채면 아래쪽 TikTok 전용 줄은 실행되지 않으므로, 증상이 날 때는 넓은 MATCH·광고 목록·GEOIP와의 순서부터 의심하는 것이 빠릅니다.
계정·스토어·지역 안내는 출구 IP·계정 리전과 엮이고, 실제 재생은 ByteDance 계열 CDN·엣지에 더 가깝게 붙는 경우가 많습니다. 두 축이 같은 노드 지역을 가리키지 않으면 「피드 문구는 정상인데 재생만 이상하다」처럼 느껴질 수 있습니다. 관측부터: 문제가 날 때 Clash 라이브 연결 목록을 켠 채 동일 영상을 처음부터 다시 재생하고, 썸네일 로드→첫 미디어 요청→댓글 로드까지 붙는 호스트 이름을 순서대로 적어 보세요. tiktok.com만 프록시이고 이미지·미디어 접미사가 DIRECT인지 같은 표의 균열을 먼저 찾는 것이 빠릅니다.
TikTok·ByteDance 이름 공간(웹·API·CDN·미디어)
앱 빌드·지역·A/B 실험에 따라 호스트 표는 계속 바뀌므로, 아래는 관측을 돕는 묶음 예시일 뿐 단정이 아닙니다. 실제 프로필에는 본인 기기에서 찍힌 이름을 우선합니다. (1) 사용자가 보는 웹·앱 셸과 내비게이션: tiktok.com, 지역별 사이트, 모바일 앱 딥링크. (2) 계정·동기화·일부 공통 API·분석에 붙는 ByteDance 계열 접미사: 예를 들어 pstatp.com, snssdk.com, byteoversea.com, ibytedtos.com 등이 로그에 자주 등장합니다(환경마다 다름). (3) 이미지·정적 자산·CDN: byteimg.com, ttcdn·muscdn 류 접미사, 기타 이미지 배포 호스트. (4) 실제 미디어·라이브 스트림: 긴 서브도메인을 가진 엣지와 지역 캐시가 섞여 찍힙니다.
Clash 입장에서는 여전히 도메인 규칙과 원격 규칙 세트로 출구를 고릅니다. DOMAIN-KEYWORD,tiktok처럼 넓게 잡는 방법은 빠르지만 무관 트래픽까지 끌어올 수 있어, 로그로 실명이 확인된 뒤 DOMAIN-SUFFIX를 층층이 쌓는 쪽이 운영에 유리합니다. Meta 계열에서 geosite·커뮤니티 규칙 세트에 TikTok·ByteDance 류 카테고리가 있다면 버전과 출처를 확인하고, 오래된 세트는 새 엔드포인트를 놓칩니다. Netflix·Disney+·YouTube 스트리밍 글과 사고방식은 같지만 표는 다릅니다. 구독·노드 유지보수에서 다룬 것처럼 규칙 프로바이더 갱신 경로를 안정적으로 두면 목록이 갱신될 때마다 구멍이 줄어듭니다.
계정·앱 스토어 리전과 CDN 출구
TikTok은 계정 국가·스토어 리전·콘텐츠 정책과 연결된 안내가 있고, 실제 숏폼·라이브 재생은 CDN·엣지 경로에 더 가깝게 붙습니다. 두 축이 같은 출구를 가리키지 않으면 「문구는 A지역인데 재생만 B회선 같다」처럼 느껴질 수 있고, 일부 기능 표시는 출구 IP 기준으로 바뀌기도 합니다. 이 글은 기술적으로 출구를 맞추는 방법을 설명하지만, 서비스 약관상 허용된 이용 방식과는 별개입니다. 계정·스토어 설정을 바꾸기 전에 약관과 TikTok 지원 문서를 확인하는 것이 안전합니다.
광고 차단·추적 차단 확장이나 기업 프록시가 미디어 호스트만 부분 차단하면 목록은 되는데 재생만 실패하는 패턴도 나옵니다. Clash 밖의 필터와 도메인 분류가 동시에 걸리면 원인 추적이 어려워지므로, 한 번에 한 겹씩 끄고 라이브 로그를 비교하는 편이 낫습니다.
도메인 규칙·규칙 세트·분류 순서
Clash Meta 계열은 규칙을 위에서 아래로 평가하므로, TikTok·ByteDance에 해당하는 DOMAIN-SUFFIX 묶음이 넓은 MATCH나 다른 대륙 GEOIP보다 먼저 오도록 정렬해야 합니다. 스트리밍·숏폼 한 줄을 추가했는데도 효과가 없다면, 그보다 위에 있는 다른 줄이 이미 잡아챘는지부터 의심합니다. 광고 차단 목록이 CDN 호스트를 오탐하면 자산만 말라버리는 것과 같습니다.
아래는 이해를 돕는 예시 YAML 조각입니다. 정책 그룹 이름·노드 풀·추가 접미사는 본인 구독과 로그에 맞게 바꿉니다.
Illustrative YAML fragment
rules:
- DOMAIN-SUFFIX,tiktok.com,TT_MEDIA
- DOMAIN-SUFFIX,tiktokcdn.com,TT_MEDIA
- DOMAIN-SUFFIX,byteimg.com,TT_MEDIA
- DOMAIN-SUFFIX,pstatp.com,TT_MEDIA
- DOMAIN-SUFFIX,snssdk.com,TT_MEDIA
- DOMAIN-SUFFIX,byteoversea.com,TT_MEDIA
- DOMAIN-SUFFIX,ibytedtos.com,TT_MEDIA
- GEOIP,CN,DIRECT
- MATCH,DIRECT
실제 환경에서는 위 목록보다 더 세분화하거나, 반대로 snssdk.com처럼 넓은 접미사를 다른 ByteDance 제품과 공유하면 일상 트래픽까지 같은 출구로 갈 수 있어 로그를 보고 조정해야 합니다. 새 앱 업데이트 후 갑자기 로딩만 길어졌다면, 릴리스 직후 로그에 새 호스트가 등장했는지 보고 한 줄씩 정책으로 옮기는 방식이 가장 재현 가능합니다. MATCH가 전부 DIRECT인데 빠진 이름이 있으면 그 호스트만 다른 출구로 새어 세션이 엇갈릴 수 있습니다.
스트리밍 노드·지연·숏폼·라이브
노드 선택에서 흔한 오해
지연 숫자만 낮은 노드가 항상 끊김 없는 숏폼·라이브로 이어지지는 않습니다. 장시간 TLS·UDP(라이브)·대역을 안정적으로 유지하는지, 상용망과 콘텐츠망 사이 라우팅이 어떤지가 중요합니다. 데이터센터형 IP는 구독 설명에 「스트리밍」이 있어도 실제 협상이 보수적으로 잡히거나 중간 품질에 머무는 경우가 있습니다. 노드 지역 라벨이 계정·스토어 리전과 크게 어긋나면 일부 안내 문구나 실험 기능 표시가 기대와 다를 수 있으니, 의도한 리전과 출구를 맞추는 것이 안전합니다.
정책 그룹과 측정 URL
url-test·fallback을 쓴다면 측정 URL이 실제 미디어 경로와 무관한 작은 객체만 보고 있지 않은지 확인하세요. 자세한 설정은 정책 그룹·지연 측정 글을 함께 보는 것이 좋습니다. TT_MEDIA 그룹 안에서만 노드를 바꿔 가며 같은 영상을 재생해 보면, 「회선은 정상인데 Clash 규칙만 켜면 로딩이 길다」 같은 원인 분리가 쉬워집니다.
DNS·fake-ip·TUN과 앱 트래픽
DNS 응답과 프록시 출구가 다르면 TLS는 열려도 앱이 다음 단계로 진행하지 못하는 경우가 있습니다. fake-ip를 쓸 때는 DOMAIN 규칙과 리졸버가 같은 전제를 공유하는지 점검해야 합니다. nameserver·fallback·fake-ip-filter를 단계적으로 맞추려면 Meta DNS 가이드를 참고하세요. 브라우저 DoH·OS DNS·Clash DNS를 한 기기에서 뒤섞으면 우선순위가 꼬이기 쉬우니, FAQ의 연결·DNS 항목과 함께 한 갈래로 정리하는 편이 낫습니다.
모바일 앱·TV·일부 태블릿은 시스템 프록시를 무시합니다. 이때는 TUN으로 라우팅 테이블에 올리는 편이 확실한 경우가 많습니다. 다른 VPN·기업 보안 에이전트와 겹치면 충돌이 나므로, 병용 전 TUN 심화 글에서 패턴을 읽어 두세요. 증상이 특정 기기에서만 난다면 그 기기의 DNS 고정·IPv6 경로도 함께 의심합니다.
연결 로그로 출구를 맞추는 법
추측보다 로그에 찍힌 정책 적중과 목적지를 봅니다. 홈 로드 직후·첫 미디어 요청 직후·댓글 로드 직후에 어떤 접미사가 TT_MEDIA를 탔는지, 동일 세션의 다른 호스트가 DIRECT로 새는지를 나란히 적어 두면 규칙 수정이 빨라집니다. TLS 단계에서 끊기는지는 timeout·TLS 진단 글과도 연결됩니다. GUI마다 로그 가독성이 다르므로 클라이언트 선택 때 진단 화면을 기준에 넣을 만합니다.
핵심은 「전부 프록시」도 「최소 프록시」도 아니라, 숏폼·라이브·CDN에 필요한 이름 공간을 한눈에 덮는 중간의 명시성입니다. 규칙이 읽히면 매일 밤 노드 룰렛을 돌릴 필요가 줄어듭니다.
약관·합법망을 먼저 두는 이유
일부 지역에서는 VPN·프록시 사용이 제한되거나 계약 위반으로 이어질 수 있습니다. 크리에이터 도구·라이브·결제는 특히 약관과 결제 규정을 따릅니다. 기술적 가능성과 합법적 이용 범위는 별개이므로, 프로필을 바꾸기 전에 약관과 내부 보안 정책을 확인하는 것이 안전합니다.
맺음말: OTT와 닮았지만 ByteDance 표는 따로 둔다
TikTok 무한 로딩 문제는 종종 단일 스위치가 아니라 여러 호스트의 출구 불일치에서 옵니다. Clash는 정책 그룹·도메인 분류·원격 규칙 세트·DNS 모드로 그 불일치를 드러낼 수 있고, Netflix용 nflxvideo 묶음이나 YouTube용 googlevideo 묶음을 그대로 TikTok에 붙이면 구멍이 남습니다. 같은 사고방식을 쓰되 도메인 세트는 ByteDance·TikTok용으로 다시 관측하는 것이 정답에 가깝습니다. 스트리밍 시리즈로 이미 익숙한 독자라면 Netflix·YouTube 글의 절차를 그대로 가져오되, 로그에 찍히는 접미사만 갈아끼우면 됩니다.
노드 품질은 날마다 변하지만, 어떤 이름이 어떤 정책을 탔는지가 기록 가능하면 원인 분리가 빨라집니다. 새 엔드포인트가 보이면 접미사를 보강하고, DNS와 TUN을 같은 전제로 맞추며, TT_MEDIA 그룹 안에서만 A/B 테스트를 하면 라이브·VOD 이슈도 추측이 아니라 확인으로 바뀝니다. 불투명한 「부스터」보다 규칙이 파일에 남는 쪽이 장기적으로 덜 지치는 운영입니다.
→ Clash를 무료로 다운로드해 TikTok·ByteDance 관련 호스트를 한 미디어 정책으로 묶고, 로딩이 길 때마다 규칙 룰렛 대신 로그로 원인을 줄여 보세요.