スピナーや途切れが「経路の割れ」に見える理由
TikTok のクライアントは、フィードやプロフィールの JSON、短尺・ライブのメディア取得、画像・フォント、計測や API 用の別ホストへ、端末や地域・実験フラグによって多数の HTTPS 接続を張ります。Clash は接続ごとに DIRECT か特定の proxy-groups かを決めるため、同じ画面の中でもホスト単位で出口が混ざると、枠やテキストは描画されるのにセグメント取得だけ遅延し、ユーザーには回り続けるスピナーや再生の途切れとして見えます。ログを開くと、tiktok.com だけプロキシに乗り、tiktokv.com や tiktokcdn.com 系が DIRECT のまま、といった表の割れが典型です。まず設計の骨格は ルール分流のベストプラクティス に沿って整理し、神秘的な「アプリの不調」より先に、ルール欠け・順序の誤り・DNS の答えと出口の不一致を疑うと早いことが多いです。
ショート動画は長尺映画ほど単一 CDN に収まらず、ライブや広告・計測のホストが増減しやすい世代のプロダクトです。分流の目的は「規約違反の裏口を作る」ことではなく、許容された単一の視聴コンテキストに経路を揃え、未知のホスト漏れを減らすための衛生です。グローバルプロキシにすべてを流す説明は簡単ですが、OS 更新・クラウド同期・別タブの大容量転送と細かく連続する動画チャンクが同じトンネルを奪い合い、遅延のジッターが増えます。Hugging Face の CDN 分流 と同様、本体と配信サフィックスを同一ポリシーへ束ねる考え方が有効です。
ライブやコメントのリアルタイム性は、RTT とセッション維持の両方を要求します。出口がホストごとにちぐはぐだと、画面の一部だけ別地域のノードへ流れ、体感としては「読み込みだけ終わらない」に近づきます。Clash でできるのは、判定に使われそうなホスト群がすべて同じポリシーグループに乗り、かつそのグループで選ばれているノードの条件が一貫しているかをログで確認することです。
tiktok.com だけプロキシに乗り、tiktokv.com や tiktokcdn.com 相当のホストが DIRECT のまま、といった割れがないか確認してください。ここが割れていると、UI は出ても短尺だけ不安定という説明がつきやすくなります。
分流の核:ByteDance 名前空間をひとつのショート動画ポリシーへ
実務では TIKTOK や SHORTVIDEO のようなショート動画専用ポリシーグループを用意し、TikTok に関わるサフィックスをそこへ集約します。日常の国内サイトや社内イントラは DIRECT、長尺ストリーミングは別グループ、AI 向けはまた別、というように責務を分けると、ルールプロバイダを更新したときの影響範囲が読みやすくなります。ポリシーグループの中身は、遅延テスト付きの url-test、手動選択、フォールバックなど環境に合わせてよいのですが、短尺・ライブ向けに帯域と安定性のバランスが取れたノードを選ぶのが要点です。細かい接続ログが読めるクライアントを選ぶことは切り分けでも同様で、クライアントの選び方 も参照してください。
ノード名のラベルより、実際のライブ接続でホストが意図したグループに乗っているかを優先します。表示上の「ストリーミング専用」でも、混雑や輻輳で長時間セッションに不向きな経路はあります。まずドメインが正しいグループに揃っているかを確認してからノードを総入れ替えした方が早いことがほとんどです。
ドメインの束:本体・CDN・API・ライブ・計測
運用上は次のような束に分けてメモすると整理しやすいです。(1)ブランド/アカウント UI:tiktok.com、地域によっては別 TLD やリダイレクト。(2)アプリ・API 系:tiktokv.com など——クライアント実装やリージョンで増減します。(3)メディア CDN:tiktokcdn.com や muscdn.com、p16- などのサブドメインを含む配信ホスト。(4)ライブ・リアルタイム:通常の短尺よりセッション維持と UDP/QUIC の扱いが絡みやすいです。(5)計測・サードパーティ:ブロックリストや企業プロキシが一部だけ潰すと、UI は生きているのに再生だけ止まることがあります。フォーラムのコピペ一覧は出発点にすぎず、自分の端末のログで見えたホスト名を正とします。実際のサフィックスはアプリ版・Web 版・地域で変わるため、定期的にライブ接続を眺める習慣が効きます。
サードパーティの geosite 型カテゴリやコミュニティのルールセットを購読に含める場合も、版と供給元を確認し、意図せず広告ブロックが CDN を潰していないか、広い捕捉行が具体行より上に来ていないかを見ます。ルールは上から順にマッチするため、ここが崩れると「ルールは書いたのに効いていない」状態になります。
ルールセット(ルールプロバイダ)と版管理
Clash Meta 系では rule-providers で外部のドメインリストを取り込み、定期更新できます。ByteDance/TikTok 向けの行が含まれる集合を選ぶ場合、リスト全体の方針(広告ブロック寄りか、分流のみか)を確認してください。更新のたびにホスト集合が変わるため、壊れたら一つ前の版へ戻して差分を見る——購読とノード保守 の型と同じく、版の固定と差分レビューが長く効きます。購読 URL やルールセット取得が死んだプロキシチェーンへ入ると更新が止まり、新ホストに追従できなくなります。
自前で DOMAIN-SUFFIX を足す場合も、ログに出た実名から順に増やすのが安全です。DOMAIN-KEYWORD は手早い反面、無関係ホストを巻き込みやすいので限定利用にとどめます。
ノード地区とライブ/地域まわり
TikTok はコンテンツのライセンスや利用ポリシーと、実際の出口 IP から見える地域の整合を扱う場面があります。Clash でできるのは、判定に使われそうなホスト群がすべて同じポリシーグループに乗り、かつそのグループで選ばれているノードの所在地が一貫しているかをログで確認することです。「表示やおすすめの地域を変える」ためのプロキシ運用は、サービス規約と法令の両方で問題になり得ます。本稿は許可されたネットワークで、意図した単一の視聴コンテキストに経路を揃えるための話に限ります。
ショート動画向けノードの選び方
ショート動画向けノードというラベルはプロバイダ任せのマーケ語であり、技術的にはその出口がメディア CDN との経路・混雑状況に適しているかの問題です。極端に CPU 負荷の高い多重暗号化や、過剰なユーザー数の共有出口は、長時間の TCP セッションやライブに不向きなことがあります。一方で、帯域だけ広く RTT が不安定な経路も適応ビットレートには不利です。timeout と TLS の読み方 は、接続が張る前に落ちているのか、途中で切れているのかを分けるのに役立ちます。
高解像度や高フレームレートを狙う場合でも、端末・作品ごとの提供フォーマットは配信側と受信側の条件が揃わないと上がりません。プロキシは「届かない帯域を届ける」装置ではなく、すでに提供されているレンジの選択が正しく機能するための経路衛生だと捉えると期待値が適切です。
DOMAIN-SUFFIX・YAML 例
DOMAIN-SUFFIX,tiktok.com,TIKTOK のようにサフィックスで束ねるのが基本です。メディア取得が tiktokv.com や tiktokcdn.com にあるなら、そのサフィックスも同じ TIKTOK に入れる必要があります。単一ホストだけ切りたい場合は DOMAIN。下の YAML は教育用のイメージです。実際のグループ名・国内判定(GEOIP の国コードなど)は環境に合わせて置き換え、観測したホストに合わせて行を増減してください。地域やアプリ版でホスト名が増える場合は、ログの実名を追って足していきます。
Illustrative YAML fragment
rules:
- DOMAIN-SUFFIX,tiktok.com,TIKTOK
- DOMAIN-SUFFIX,tiktokv.com,TIKTOK
- DOMAIN-SUFFIX,tiktokcdn.com,TIKTOK
- DOMAIN-SUFFIX,muscdn.com,TIKTOK
- GEOIP,JP,DIRECT
- MATCH,DIRECT
byteoversea.com や snssdk.com など、コミュニティルールに登場するサフィックスは環境によって意味づけが異なることがあります。ログに出たものだけを足すか、信頼できるルールプロバイダの説明を読んだうえで採用してください。新しい CDN 名が観測されたら行を足し、ルールプロバイダ更新後に壊れたら差分を戻す——ソフトウェアの依存更新と同じ運用が長く効きます。
DNS/fake-ip をルールと揃える
fake-ip モードではアプリに合成アドレスが返り、実解決はプロキシ側で進むことがあります。DOMAIN 系ルールと DNS の見え方がズレると、「名前解決は一瞬なのに再生が始まらない」パターンが出ます。ブラウザの Secure DNS、OS のリゾルバ、Clash の dns ブロックを同時に有効にすると優先が衝突するため、Clash Meta の DNS・fallback・fake-ip と よくある質問の DNS の項 を手掛かりに、層を分けて切り分けてください。
企業ネットワークで公開名が書き換えられる場合は、Clash だけいじっても直らないことがあります。簡単な回線で再現するか、IT と resolver トレースを共有できる形でエスカレーションします。
システムプロキシ・TUN・モバイルアプリ
PC ブラウザならシステムプロキシで十分なことが多いですが、スマートフォンのネイティブアプリは OS プロキシを無視したり、別のネットワークスタックを使うことがあります。TikTok アプリはメディア取得ホストへの接続が多く、プロキシを見ない経路が残るほど TUN で捕まえる必要が出ます。TUN でデフォルトルート側から揃えると同じプロファイルに乗せやすい反面、他 VPN やゼロトラスト製品と競合します。詳細は TUN モードの詳解 を先に読み、除外インターフェースと DNS の取り扱いを決めてから有効化してください。
ルール順・ブロックリスト・購読更新ループ
広告/トラッカー系リストがメディア CDN を誤ってブロックすると、UI は生きているのに再生だけが始まらないことがあります。ルールプロバイダを更新した直後に壊れたら、一つ前の版へ戻して差分を見てください。また、購読 URL やルールセット取得が不安定なプロキシチェーンへ入ると更新が止まり、新ホストに追従できなくなります。更新経路を DIRECT または低リスク専用に分離する型は 購読とノード保守 と共通です。
YouTube/Netflix/Disney+ 記事との棲み分け
当サイトの YouTube 向けドメイン分流 は googlevideo.com・ytimg.com など Google 名前空間を軸にしています。Netflix 向け は nflxvideo.net など、Disney+ 向け は bamgrid.com 系や disneyplus.com を中心にした別の名前空間です。一方 TikTok は tiktok.com・tiktokv.com・tiktokcdn.com などByteDance/CDN の束が独立しているため、ルールセットをそのまま流用するとホスト漏れが出やすいです。手法はいずれも「関連サフィックスを同一ポリシーへ」「DNS とルール順を一致」「アプリは TUN を検討」という三拍子で似ていますが、コピペ対象のドメイン行だけはプラットフォームごとに差し替える必要があります。
許可された利用の前提で押さえるチェック
- TikTok・プロキシ・職場ポリシーのすべてで許容されているか確認する。
- スクロール/再生直前のホスト名を列挙し、
TIKTOK(相当)へ揃っているかログで見る。 tiktok.comだけプロキシ、tiktokcdn.comだけ直結、といった表の割れを潰す。- ノード条件が UI・CDN・API でちぐはぐになっていないか確認する。
- DNS/fake-ip・ブラウザ DoH・OS リゾルバの二重化を整理する。
- ルール順とブロックリストの誤爆を確認する。
- 購読・ルール更新がループせず成功しているか確認する。
- システムプロキシと TUN、ネイティブアプリの経路差を比較する。
- ローカル要因を切ったうえでノードと配信側ステータスを切り分ける。
各ステップでログ行を残すと、設定の全消しより早く収束します。
まとめ
TikTok の体験は、単一ドメインではなく本体 UI・メディア CDN・API・ライブ・計測など複数ホストの協奏です。Clash は ドメイン分流とショート動画向けポリシーグループで、その協奏を同じ出口ストーリーに揃える道具です。ズレはスピナーや途切れとして現れがちですが、ログとサフィックスの不足を埋めることで多くは再現可能な経路バグに戻せます。
グローバルプロキシより、名前空間を分けた方が帯域競合を減らし、他サービス向けルールとも責務がぶつかりにくくなります。不透明なプロファイルより、編集と検証ができるクライアントを選ぶ価値は 2026 年も変わりません。
→ 無料で Clash をダウンロードし、TikTok の「ずっと読み込み」を経路の設計として扱えるようにしてください。