어떤 증상에 이 글이 해당할까

TikTok 웹 클라이언트와 모바일 브라우저에서 보이는 개인 페이지는 화면 뼈대와 썸네일·영상 조각·분석 스크립트를 서로 다른 호스트에서 불러옵니다. 크리에이터 대시보드나 크로스보더 셀러가 통계·숏폼 링크를 데스크톱 웹으로 확인할 때도 같은 구조입니다. Clash나 mihomo에서 프록시는 켜 두었는데도 아래 증상이면 DOMAIN-SUFFIX,tiktok.com 한 줄만으로는 부족했을 가능성이 큽니다.

  • 주소 표시줄은 tiktok.com인데 피드·프로필 탭이 비어 있거나, 상단 UI만 있고 무한 스피너만 돈다.
  • 텍스트 일부는 나오는데 프로필 사진·영상 썸네일·댓글 블록만 계속 로딩된다.
  • 브라우저 개발자 도구 네트워크 탭에서 정적 자산·세그먼트 요청만 빨간색(실패)으로 보인다.
  • 같은 Wi-Fi에서 다른 사이트는 정상인데 TikTok 웹만 반복적으로 깨진다.

이 패턴은 “노드 하나가 불안정해서”보다 rules 배열에서 첫 매칭된 줄이 호스트마다 달라져 출구가 갈라질 때 더 흔합니다. 단축 도메인과 CDN을 한 묶음으로 정리한 Reddit redd.it·CDN 글, Threads·Meta CDN 글, UDP 쪽은 Discord 분기 글과 같은 유형으로 이해하면 유지보수가 쉬워집니다.

왜 tiktok.com만 프록시하면 화면이 비는가

TikTok 웹의 표면 도메인은 tiktok.com이지만, 실제 트래픽은 (1) 로그인·라우팅용 tiktok.com 문서, (2) 정적 리소스와 번들을 실어 나르는 tiktokcdn.com·지역별 접두 호스트, (3) 로그인 페이지나 공통 자산에 자주 등장하는 ttwstatic.com 계열, (4) 영상·이미지 배포를 위해 로그에 반복되는 기타 ByteDance 계열 접미사로 나뉩니다. HTML만 프록시로 받고 JS 번들이나 세그먼트 요청이 GEOIP나 넓은 MATCH 아래에서 DIRECT로 떨어지면, 브라우저는 빈 레이아웃만 그린 채 데이터를 기다리다 흰 화면·스피너로 보일 수 있습니다.

또한 브라우저는 OS 프록시를 따르지만, DNS prefetch나 확장 프로그램, 다른 VPN이 끼어 있으면 Clash가 보기에 맞는 규칙과 실제 SYN이 나가는 경로가 어긋날 수 있습니다. 지역별 회선이나 IPv6 우선 환경에서는 같은 노드라도 웹만 불안정하게 보이기도 하므로, 원인을 좁힐 때는 Connections 로그의 FQDN·SNI를 기준으로 두는 것이 안전합니다.

팁

문제가 난 순간 Connections 창을 켜 두고 탭을 새로고침하세요. 실패한 줄의 도메인·SNI를 적어 두면, DOMAIN-KEYWORD,tiktok처럼 과하게 넓은 규칙 없이도 누락 호스트를 보완할 수 있습니다.

호스트를 역할별로 묶기 (출발점)

엔드포인트는 배포·A/B 테스트에 따라 바뀔 수 있으므로 아래는 교육용 출발점이며, 최종 기준은 항상 본인 로그입니다.

  • 웹 메인·API 축: tiktok.com, www.tiktok.com, m.tiktok.com — 문서·일부 API 진입.
  • CDN·정적 자산: tiktokcdn.com 및 지역·용도별 서브도메인 — 썸네일·스크립트·번들에 자주 등장합니다.
  • 웹 로그인·공통 정적: ttwstatic.com 계열 — 로그인 페이지나 공유 리소스 경로에서 반복적으로 보일 수 있습니다.
  • 기타 로그에 보이는 호스트: 영상 세그먼트나 추적 스크립트용 이름이 따로 찍히면 DOMAIN 또는 DOMAIN-SUFFIX로 한 줄씩 추가합니다.

처음에는 tiktok.com와 tiktokcdn.com, 로그에 반복되는 ttwstatic.com부터 같은 전략 그룹에 넣고, 남는 실패 호스트만 좁혀 덧붙이는 방식이 실수가 적습니다. DNS가 fake-ip 모드라면 이름 해석과 규칙 매칭이 어긋나지 않는지 YAML·DNS 가이드의 fake-ip-filter·nameserver 설정과 함께 대조하세요.

전략 그룹: PROXY_TIKTOK

운영상 이름은 PROXY_TIKTOK처럼 고정해 두면 규칙 줄과 주석을 맞추기 쉽습니다. 타입은 대개 select가 무난하고, 자동 url-test가 너무 자주 출구를 바꾸면 세션·쿠키가 끊기는 체감이 날 수 있으니 재현 테스트 때는 한동안 노드를 수동 고정해 비교하는 것이 좋습니다.

tiktokcdn.com 전체를 다른 서비스와 공유하는 매우 넓은 블록과 함께 쓰면 의도치 않게 트래픽이 섞일 수 있습니다. Threads 글에서 instagram.com 전체를 묶을 때와 같이, 영향 범위를 먼저 정한 뒤 접미사를 넓히세요. 처음에는 로그에 실제로 보인 서브도메인 위주로 두고, 안정화 후에만 일반화하는 편이 안전합니다.

규칙 예시 (개념 스케치)

rules는 위에서 아래로 평가되며 첫 매칭이 최종입니다. TikTok 전용 줄은 넓은 GEOIP,CN·MATCH보다 위에 두되, 사내망·은행·결제 예외는 그보다 더 위에 둡니다. 프록시 이름은 본인 프로필에 맞게 바꿉니다.

# Conceptual excerpt — adapt proxy group names and your upstream nodes
proxy-groups:
  - name: PROXY_TIKTOK
    type: select
    proxies:
      - NODE_STABLE_A
      - NODE_STABLE_B
      - PROXY_DEFAULT

rules:
  - DOMAIN-SUFFIX,tiktok.com,PROXY_TIKTOK
  - DOMAIN-SUFFIX,tiktokcdn.com,PROXY_TIKTOK
  - DOMAIN-SUFFIX,ttwstatic.com,PROXY_TIKTOK
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

tiktokcdn.com 줄은 다른 Byte 제품 웹과 호스트가 겹칠 여지가 있는지 구독 RULE-SET과 함께 점검하세요. DOMAIN-KEYWORD,tiktok는 오탐이 나기 쉬워 임시 진단용에 가깝습니다. 최종 형태는 로그에서 확인된 이름을 우선합니다.

DNS·Fake-IP가 의심될 때

증상이 “문서는 열리는데 특정 API·정적 호스트만 타임아웃”이면 Fake-IP와 브라우저 내부 DNS가 엇갈리는 경우를 의심할 수 있습니다. TikTok 웹이 시스템 DNS를 직접 쓰는 경로가 섞이면 Clash 로그상으로는 규칙이 맞는데 실제 연결은 다른 IP로 보일 수 있습니다. 이때는 (1) fake-ip-filter에 해당 이름을 넣을지, (2) TikTok 관련 이름만 특정 nameserver로 보낼지, (3) TUN으로 트래픽을 모을지 중 하나를 골라 한 축으로 정렬하는 것이 중요합니다.

IPv6 우선 경로나, Wi-Fi와 이동통신을 바꿀 때만 증상이 달라지면 이중 스택·회선별 DNS도 함께 확인하세요.

TUN·앱 경로: 브라우저와 시스템이 다를 때

Android에서는 앱별 경로가 앱별 프록시 가이드에서 정리한 것처럼 OS 정책에 따라 달라집니다. 공식 TikTok 앱이 시스템 VPN을 완전히 따르지 않으면, 브라우저만 고쳐도 앱은 그대로일 수 있습니다. 데스크톱에서도 브라우저 확장·별도 프록시가 TikTok만 우회하면 Clash 규칙과 경쟁합니다. 테스트할 때는 가능한 한 Clash 한 벌만 켜 재현하는 것이 원인 분리에 유리합니다.

Windows에서 TUN을 켠 뒤 전체 인터넷이 끊기면 방화벽·다른 VPN과의 충돌을 먼저 정리합니다. TikTok만이 아니라 시스템 전반 증상인지 구분하세요.

주의

지역 법령·서비스 약관·기관 보안 정책을 위반하는 우회를 돕는 목적의 설명은 하지 않습니다. 이 글은 합법적으로 접근 권한이 있는 네트워크에서 기술 경로 불일치로 생기는 로딩 문제를 줄이는 데 한합니다.

점검 순서 체크리스트

  1. Connections 로그에 찍힌 TikTok 관련 FQDN을 적고, 그보다 넓은 규칙이 위에서 먼저 잡히지 않았는지 확인합니다.
  2. tiktok.com과 정적·CDN 축(tiktokcdn.com, ttwstatic.com 등)이 동일한 전략 그룹으로 나가는지 확인합니다.
  3. 구독 RULE-SET 안의 글로벌 미디어·CDN 세트와 TikTok 전용 줄의 중복·순서를 함께 점검합니다.
  4. Fake-IP·스플릿 DNS 조합에서 해석 결과가 어긋나지 않는지 YAML과 대조합니다.
  5. 브라우저와 공식 앱을 나누어, 어느 쪽에서만 재현되는지 범위를 좁힙니다.
  6. TUN·시스템 프록시 중 무엇을 쓰는지 한 가지로 고정하고 다른 VPN과 중복이 없는지 봅니다.
  7. 노드를 바꾸기 전에 규칙 순서·DNS를 먼저 맞췄는지 확인합니다.

정리

TikTok 웹이 tiktok.com만 프록시되고 tiktokcdn.com·ttwstatic.com 같은 CDN 축이 DIRECT로 갈라지면 무한 로딩·빈 피드가 자주 납니다. PROXY_TIKTOK 같은 전용 그룹에 메인과 CDN 접미사를 묶고, Connections 로그로 확인된 호스트를 보강하며, 범위 큰 키워드 규칙은 정책에 맞게 좁히면 같은 노드에서도 체감이 달라질 수 있습니다. 크리에이터·커머스 워크플로에서 웹 대시보드만 불안정할 때 특히 이 패턴을 우선 의심하면 좋습니다.

규칙을 손볼 때마다 날짜와 변경 요약을 남겨 두면 이후 비교가 쉽습니다. 클라이언트는 공식 배포 경로에서 확인하는 것이 안전합니다. → Clash를 무료로 내려받아 프로필을 맞춘 뒤, 로그에 나온 실제 호스트부터 TikTok 전용 규칙을 다시 점검해 보시기 바랍니다.