単一ノード問題で片づかないとき：Web と LIVE でログの顔つきが違う理由
まず頭に置いておきたいのは、画面上「TikTokが重い」の背後にあるのがひとつのAPIではない、という話です。TikTok はアプリ・ドメイン・地域・クライアント更新で叩かれる FQDN の集合が増減します。開発者コンソールの Network を開くと、メインのコンテンツ配信とは別ブラケットのアセットや統計送信が混ざるのも珍しくなく、ユーザーから見れば一律の「ぐるぐる」や「細切れ」に凝縮されてしまいます。ここへ Clash の分流をかけるとき、広いGEOIP や広いリストの先頭で止まっていると読み込み失敗っぽい白画面／フリーズに見えやすく、ただノードだけ替えても再現しないままになりがちです。クライアント未セットアップなら Windows でのセットアップ でプロファイルを読み込み、モードはルールにしてログを一度流すことをまず進めます。
ウェブ視聴とライブ視聴のレイヤーの差
ウェブでの短尺スクロール は多くの場合 TCP 上の HTTPS と画像・字幕・メタ情報の並列フェッチとして観察できます。対してライブは配信側の構成次第でリアルタイム性を増すプロトコルが混じりやすく、ログ上でも UDP や QUIC、あるいは長めのWebSocket／HTTP/2／HTTP/3 によるセッションが混ざることがあります。したがって同じ画面上のサービスでも、短尺側とLIVE 側ではDIRECTに落ちていたら致命的な名前が違い得ます。音声系でUDPとTUN の切り分けを扱った Discord／UDP と近い観察軸になりますが、本文はプラットフォームがYouTube でもDiscord でもなくTikTok と限定します。
WebSocket 依存のサービスとは対象ホストやリトライ挙動が異なるので、単純に Threads ウェブSPAの事例をコピペで当て込むだけでは細切れだけが続く、`pending` が残る、`ICE`関連の名前が並ぶ、といった切り替わった症状にも届きにくいです。共通するのは「命中した経路」「名前」「出口が揃うか」を確認する順序のみです。
ログの真となる軸は「時刻 → 名前／SNI → ルール名 → 出口 → 成否」
運用側の基本は、画面の症状ではなく接続ログの一列で矛盾を潰すことです。表示が IP ばかりのときは、コアの嗅探と HTTPS ドメインの取り扱い を補い、人間が読めるホスト名／SNI と分流表を一致させます。ここまで揃って初めて DOMAIN-SUFFIX の追加などを意味があります。上流のリスト更新で「似た名前の別CDN」だけが迂回した、ということも現場では珍しくなく、半年前のリスト丸写しは危険です。
1DNS を先に整える：FakeIP・DoH・二重VPN
FakeIP を前提にすると、ブラウザが握っている解決結果と実際のTLS握手中の名前が食い違うと読み込み失敗／ランダムに直る／一部サブドメインだけpending のように見えます。fake-ip-filter や nameserver-policy は先にチェックリスト化し、そのうえで巨大なDOMAIN ルールの足し込みをします。総説は Metaコア側のDNS も参照しつつ、アプリ側のVPN・社内PAC・ブラウザ拡張のプロキシを重ねないかを疑います。ブラウザだけ出口を単純にしたいケースでは Chrome とシステムの切り離し も有効です。
とくにライブ視聴ほど名前解決のブレが長時間体感のゴムのように伸びやすく誤検知になります。開始直後だけ固まって以降は大丈夫、などのときはログの名前を時系列で追い開始フェーズに限定した別ホストがDIRECT側に落ちた痕跡を探します。
2分流ルール：リストよりログで増やす TikTok／CDN 側の枠
広いGEOIP やリストの広い順序で先勝ちしないよう、ログに繰り返し出る短尺・ライブ双方のホストを同じ策略組に寄せると再現性が上がります。url-test の周期が短いとTCPセッションが途中で切れ、表向きは再生の途切れに見えることがあるので、症状を切り分けるときは一時的に単一ノード固定も試します。ルールの積み上げ順は 先勝ちの稿 を再確認し、埋もれた DOMAIN-SUFFIX がないかを潰します。
mixin で購読を合成しているなら最終行順が真実です。Mihomo mixin を参照し、個人追記が更新で消えない形にしておくと安全です。
3YAML スケッチ（グループ名とサフィックスはログで置換）
次の例は構造のイメージです。コピペ即本番ではなく、TIKTOK-STABLE は実プロファイルの策略名に差し替え、DOMAIN-SUFFIX は自分のログに出た名前から導いてください。ネット上の古いドメイン一覧よりその場の観測を優先します。
# Example only — replace group name and domains using your live Clash logs
rules:
- DOMAIN-SUFFIX,tiktok.com,TIKTOK-STABLE
- DOMAIN-SUFFIX,tiktokv.com,TIKTOK-STABLE
- DOMAIN-SUFFIX,byteoversea.com,TIKTOK-STABLE
- DOMAIN-KEYWORD,tiktok,TIKTOK-STABLE
- GEOIP,CN,DIRECT
- MATCH,TIKTOK-STABLE
DOMAIN-KEYWORD は過剰マッチしやすいので扱いを理解した上で限定し、基本はログから DOMAIN／DOMAIN-SUFFIX をホワイトリスト的に足すほうが安全です。名称は地域・端末・時期で変わり得るため、本稿は固定表を列挙しません。
4LIVE 側：UDP／QUIC と TUN・ジッタ
ライブでUDPが絡む場合、システムプロキシモードだけでは拾い切れないフローが残ることがあります。クライアントがTUN を提供するなら、UDPが意図した出口へ乗っているかをログで確認します。断続的なのにリセットが目立つなら connection reset と時系列 を当て、策略の切替か遠端かを分けます。ヘルスチェック付きの組で出口が頻繁に入れ替わると、長尺と違い秒単位のカクつきに見えることがあるので、url-test／フェイルオーバ の稿と同系の調整を検討します。
症状の早見
フィードは回るが短尺再生だけ途切れる： CDN系ホストとプレイヤー周りのホストで出口が分裂していないか。DNSキャッシュのクリアと再現比較も有効です。
ウェブは普通だがLIVEだけ固まる： UDP／QUIC のフローがDIRECTに落ちていないか、TUNや嗅探の観測を追加してからルールを足します。
たまに再生できるが多くは失敗： FakeIP と DoH の矛盾、VPNの二重化を疑い、入口を一つに寄せてから再観測します。
注意： TikTok 各線のホスト名・CDN・地域の方針は変わります。本稿は公式情報の代替ではありません。ルールはその場のログと公式ドキュメントを基に、増分更新できる形で管理してください。
入手経路： クライアントの取得は 公式ダウンロードページ を第一にすると取り違えが減ります。ソースや Issue は GitHub で追う目的と、配布パッケージの入手先とは切り離して考えるのが無難です。
コンプライアンス： 居住地の法令と利用規約、サービス側のコンテンツ方針を守ってください。未承認のトラフィック操作や規約違反の利用へ誘導する目的は持たないでください。
まとめ
TikTok のブラウザ利用とLIVE を Clash で接続安定側に寄せるには、抽象的な読み込み失敗対策リストより、DNS（FakeIP／DoH）、分流ルール順、それにUDPが絡むなら経路スタック一式の三本をログで同期させるのが効きます。YouTube長尺バッファ論やThreads とTikTok とでは典型ホスト並びや症状が違うため、名前の丸写しは避け、常に自分の環境での観測を真にしてください。運用資産としては増分メンテ可能な一覧に落とせば、体感のギャンブルを減らせます。
用語の俯瞰は ドキュメント も活用できます。ログとYAMLの対応が揃えれば、ブラウザのもっさりに見える事象でも、追跡可能なネットワーク課題に戻せます。
GUIが違っても読み勝ちはYML上で分流とDNSが同じ次元で描ける点です。競合より設計自由度はあり、短尺＋ライブの混在トラフィックほど「一度きちんと揃えたら長く効く」領域でもあります。