증상 — 웹은 되는데 왜 라이브만 유독 불안정할까
첫 화면의 추천 피드 카드까지는 불러오는데, 카드를 탭했을 때만 무한 회전 표시가 돌거나, For You와 달리 LIVE 카테고리에서만 새로 고침이 반복된다면 “서버 접속 차단”이라기보다 TCP 세션·TLS, HTTP/3 QUIC, WebSocket 장시간 연결 같은 하위 채널이 일부만 실패했을 가능성이 큽니다. 모바일 앱은 OS 백그라운드 업데이트나 앱별 DNS 정책이 있지만, 데스크톱 웹 클라이언트는 브라우저 DevTools 네트워크 탭에 찍히는 호스트 문자열대로 순서대로 요청합니다. 따라서 tiktok.com HTML과 API를 타는 패킷이 통과했어도, 같은 화면을 구성하는 mcdn·sign 도메인류가 다른 룰이 잡거나, 이름은 같아도 리졸브 결과가 순간 다른 CDN 엣지으로 붙으면 사용자 체감은 혼합 지연처럼 느껴집니다.
2026년에도 숏폼·라이브 커머스 트래픽은 높게 유지되고, 특정 지역에서는 서비스 접근·규제 이슈로 검색·문의량이 줄지 않았습니다. 이 글에서는 정책 논의가 아니라 사용자 측에서 Clash로 연결 안정을 확보하기 위한 분류 규칙 정렬 순서입니다. 직장·학교 규약과 현지 법령은 반드시 지키세요.
글의 초점 — 웹 문서와 LIVE 재생 차이
틱톡 웹 초기 렌더는 HTML·자바스크립트 번들과 정적 에셋이 중심이고, 피드를 스크롤할 때는 XHR 또는 fetch로 페이지네이션 데이터를 가져오는 패턴이 흔합니다. 반면 LIVE는 실시간이므로 채팅 오버레이·선물 정보 등이 WebSocket이나 유사 채널로 붙는 경우가 많고, 일부 브라우저·네트워크 조합에서는 영상 재생 세그먼트(HLS 또는 DASH 근처)와 UDP 기반 QUIC까지 동시에 쓰입니다. 그래서 GEOIP CN → DIRECT 같은 규칙 하나가 더 앞에 있거나, 특정 접미사만 별도 노드로 스위칭되어 있으면 “탭 하나의 데이터는 따라왔지만 동영상 디코더에 연료가 안 간다”처럼 보일 수 있습니다. Discord 같은 음성·화상에서의 UDP 이슈는 UDP·TUN 관련 글과 결이 비슷합니다.
범위
아래 YAML 예시는 개념을 보여 주기 위한 것이며, 실제 버전의 ByteDance/지역별 CNAME 체인과 다를 수 있습니다. 프로덕션에 넣기 전에 반드시 본인 환경에서 Network 탭과 코어 로그로 호스트 문자열을 수집하세요.
1호스트 문자열 실측하기
크롬 또는 Firefox에서 DevTools를 열고 페이지를 새로고침하면 tiktok.com 외에 tiktokcdn.com·byteoversea.com·통신사별 엣지 접미사가 함께 찍히는데, 시점에 따라 달라질 수 있습니다. 필터 입력란에 tiktok·byte·mcdn 등을 넣어 한 번에 보이는 이름을 메모하세요. Mihomo Sniffer를 켠 경우 TLS SNI로 보이는 이름과 브라우저가 인지한 문자열에 차이가 있을 수 있으니 HTTPS 스니퍼 라우팅 글을 참고합니다.
2분류 규칙 초안: 틱톡 묶음을 한 정책으로
수집한 접미사를 DOMAIN-SUFFIX로 묶을 때는 다른 서비스와 겹치지 않는지 확인하세요. 아래 예시에서는 PROXY_TT 자리에 본인의 프록시 정책 그룹 이름을 넣으며, 배열 상단부터 MATCH까지의 규칙 순서는 필수 검토입니다. 광고 차단·GEOIP 직통 룰이 먼저 걸려 있으면 의도와 다른 DIRECT 매칭이 나옵니다(규칙 순서 글).
# Illustrative only — replace PROXY_TT and verify order vs your RULE-SET / MATCH
rules:
- DOMAIN-SUFFIX,tiktok.com,PROXY_TT
- DOMAIN-SUFFIX,tiktokcdn.com,PROXY_TT
- DOMAIN-SUFFIX,ttwstatic.com,PROXY_TT
- DOMAIN-SUFFIX,byteoversea.com,PROXY_TT
- DOMAIN-KEYWORD,tiktokcdn,PROXY_TT
- MATCH,DIRECT메모: DOMAIN-KEYWORD,tiktok처럼 너무 넓게 잡으면 다른 브랜드·테스트 도메인까지 같은 그룹으로 붙을 수 있습니다. 운영 환경에서는 RULE-SET이나 로컬 목록으로 수집한 FQDN 위주가 안전합니다.
노드 전환 주의
url-test나 짧은 주기 fallback이 LIVE 세션 중간에 출구를 바꾸면, 스트림이 끊겼다가 이어지는 것처럼 보일 수 있습니다. 비교 실험 시에는 일시적으로 selector에서 한 노드에 고정한 뒤 지연을 재측정해 보세요. 이미 load-balance·consistent-hashing 튜토리얼을 쓰는 경우에도, 영상·채팅이 묶인 출구가 자주 바뀌지 않는지 로그로 확인하는 편이 좋습니다.
3DNS: FakeIP, DoH, 이름 일관성
FakeIP 모드에서는 브라우저가 본 IP와 실제 연결 시 복원된 도메인이 어긋나 라우팅이 흔들릴 수 있습니다. fake-ip-filter에 테스트용 도메인·LAN 이름을 명시했는지, enhanced-mode 설정이 해당 접미사에 맞춰 있는지 재확인하세요(LAN 직통 글). DoH를 브라우저와 코어에 이중 적용했다면 순간 다른 응답으로 엣지이 달라질 수 있으니, 디버깅 중에는 코어 하나로 묶거나 브라우저 Secure DNS를 잠시 끄고 비교해 보는 것이 원인 분리에 유리합니다. 심층 배선은 Meta 코어 DNS·유출 방지 글과 함께 읽으면 정리가 빨라집니다.
4QUIC·UDP와 TUN
시스템 프록시만 켠 상태에서 UDP가 우회하지 못하면 HTTP/3 핸드셰이크가 느리거나 실패할 수 있습니다. 전 구간을 같은 규칙으로 맞추려면 TUN 모드를 검토하고, 그때도 스플릿 규칙이 직통으로 충분히 열려 있는지 설정 허브와 클라이언트 매뉴얼에서 확인하세요.
5검증 순서
- DevTools 또는
curl -v으로 TLS 구간 시간을 재고, 실패 시 정확한 오류 문자열을 남긴다. - Clash 로그에서 동일 호스트가 어떤 규칙 이름과 정책으로 매칭됐는지 본다.
- DNS 패널에서 질의 이름·응답 IP가 브라우저와 일치하는지 확인한다.
- 노드·스니퍼·IPv6 우선 같은 스위치를 한 번에 하나씩 바꿔 재현 폭을 줄인다.
소스 코드는 GitHub, 설치 패키지는 공식 다운로드
Clash·Mihomo의 라이선스와 이슈 트래커는 GitHub에서 확인하는 경우가 많습니다. 반면 클라이언트 설치 파일은 공식 다운로드 페이지를 주 경로로 두는 편이 안내가 일관되고 업데이트 추적도 쉽습니다.
준수: 서비스 약관·저작권·미성년자 보호 규정을 위반하지 마세요. 예시 도메인은 변경될 수 있습니다.
맺음말
TikTok 웹과 LIVE는 보이는 UI는 단순해 보여도 백엔드 호스트·프로토콜이 겹겹이 쌓여 있어, Clash 분류 규칙과 DNS가 조금만 달라도 숏폼 재생이나 실시간 채팅만 불안정해질 수 있습니다. 한 번 관련 접미사를 모아 정책 그룹에 올려 두고, 로그로 매칭을 확인하면 이후 갱신에도 대응하기 쉽습니다. 다른 프록시 스택보다 프로필·로그가 한곳에 모인 Clash 계열이 이런 경우 운영에 유리하다는 점도 함께 짚어둡니다.
→ Clash 클라이언트를 무료로 받아 TikTok 포함 숏폼·라이브 트래픽 묶음을 한 규칙 트리로 정돈해 보세요