検索意図：何が「開けない」のかを言い切る

ユーザーが TikTok や CapCut Cloud を「開けない」と言うとき、実際には次のどれかです。(1) ログイン画面は出るがフィードだけ白紙。(2) Studio のプロジェクト一覧は出るがプレビューウィンドウが永遠にスピナー。(3) CapCut の書き出しだけタイムアウト。(4) モバイルアプリは快適だがブラウザ版だけ不安定。いずれも単一ドメインの丸め込みでは足りず、別のサブドメインや別ゾーンの ByteDance CDN にリクエストが散っているパターンが多いです。

Reddit や別サービスの「SNS 本体と CDN を分ける」系の記事とは、当てるべき TLD と証明書の束が違います。あちらの前提をそのまま持ち込むより、接続一覧で実際にどのホストがどの Policy に落ちたかを先に確かめる方が早いです。

通信が三層に割れやすい理由

短尺・編集クラウドでは、おおまかに (A) ページと設定を返す HTML／GraphQL 風 API、(B) 静的アセット用のホスト群、(C) 実際のメディア片（セグメント・オブジェクト）用ホスト、の三段に分かれます。半プロキシ構成では、(A) だけが意図した出口に乗り、(B)(C) が別ルールに捕まって DIRECT のまま不安定ゾーンへ落ちる、あるいはその逆で、認証 Cookie が届かない——といった非対称が起きます。

海外アクセスやローカル規制の文脈では、DNS が権威とターミナル表示で食い違っているケースも重なりやすいです。fake-ip 系と redir-host の組み合わせを変えた直後に症状が出るなら、まずキャッシュとエッジの向き先を疑ってください。

YouTube 稿・Reddit 稿との棲み分け

当ブログの YouTube と googlevideo の記事は、Google 側の動画配信とアカウントホストの整合が焦点です。Reddit はテキスト SNS と CDN の組み合わせが違います。今回の TikTok／CapCut は、ByteDance 傘下でドメインや証明書の山が似通っていても、実際の取得パスは製品・地域・AB テストで変わるため、過去に効いた DOMAIN-SUFFIX のセットをコピペしてもすぐ壊れることがあります。コピペよりログから追い足しを勧めます。

ログに出やすい症状パターン

  • 開発者ツールの Network で、ドキュメント系は 200 だが .m3u8 やセグメント相当が pending のまま。
  • 同一タブ内で別ホストへの TLS が大量に張られ、一方だけ handshake timeout 相当。
  • CapCut のクラウド書き出しでジョブは作成されるが、進捗ポーリングのホストだけ別 Policy。
  • TUN オフにするとアプリは動くが、システムプロキシ経由のブラウザだけ死ぬ——などブラウザ実装差。

ここでいったん立ち止まり、アプリ／ブラウザをまたいでも同一プロファイルで再現するかを切り分けます。再現がブラウザ限定なら、HTTP/3 やセキュア DNS の影響も疑い、必要に応じて Chrome と QUIC 稿を参照してください。

DNS と名前解決の揃え方

Mihomo 系では dns ブロックと nameserver-policy が、どの名前をどのリゾルバに投げるかを決めます。TikTok 関連の apex と www だけ特別扱いしても、実際の取得は v* や地域コード付きの別名に逃げることがあります。ルールで DOMAIN-SUFFIX を増やす前に、fake-ip の対象に入り過ぎていないか、購読の fallback だけが生きている尻拭いになっていないかを確認してください。

解決結果が端末の dig と Clash のログで違うときは、ブラウザのセキュア DNS をオフにする、アプリ側の独自 DNS を切る、など二重解決を止めるのが先です。

ルール順：広い catch と細かい例外

典型的には、地域・キャリア向けの GeoIP や「手元の直通リスト」が先に当たり、その後ろの「某プロキシ行きの ByteDance 束」に届かない、という並びミスが起きます。より具体的なサフィックスほど上に寄せるか、逆に意図的に最後の広域 MATCH に任せるかは、あなたのプロバイダ規約とレイテンシのトレードオフ次第です。いずれにせよ、二重に矛盾する行を置かないことが重要です。

# Example skeleton — replace policy/group names with yours; verify live hostnames via logs
RULE-SET,byteoversea-optional,CUSTOM_PROXY
DOMAIN-SUFFIX,tiktok.com,CUSTOM_PROXY
DOMAIN-SUFFIX,tiktokv.com,CUSTOM_PROXY
DOMAIN-SUFFIX,capcut.com,CUSTOM_PROXY
# Add missing API/CDN suffixes discovered in your connection log, not copy-pasted blindly

上の名前は例示です。実際のホスト名はクライアントの版、地域、アカウント種別で変わります。接続ログに出たFQDNをルールに昇格する運用が最も壊れにくいです。

接続ログで「分裂」を確定させる

GUI クライアントの Connections ビューで、同一秒付近に並ぶ複数ホストの Policy 列を見比べます。TikTok のページ読み込み1回で十数ホストが立つなら、そのうち一つでも DIRECT に孤立していればレイアウトが崩れます。CapCut Cloud も、プレビュー用と書き出し用で別ホストに分岐しがちです。

タイムスタンプとバイト数が伸びない行を拾い、その FQDN をメモしてルールに反映し、再度同じ操作を繰り返してください。これを 2〜3 サイクル回すと、足りないサフィックスが見えてきます。

TUN・システムプロキシとの関係

ブラウザだけが迂回しているときは TUN を併用すると揃うこともありますが、逆に企業 VPN や別フィルタと競合してループや二重 NATになることもあります。TUN モードの有効化を読みつつ、最小構成（プロファイルを絞る、他のトンネルを一時停止）から試してください。

クリエイターツールチェーン視点の運用メモ

撮影端末・編集 PC・公開用ブラウザが別マシンにあるチームでは、各端末の DNS と Clash のバージョン差だけで「自分の席では再現しない」が起きます。出海向けの検証環境を揃えるなら、まずリゾルバとルールファイルの版を固定し、接続ログのエクスポート手順だけ共通化するとトラブル習慣が下がります。

外部 S3 互換やサードパーティ転送に逃がす書き出し設定を使う場合、そのホストが ByteDance 系ルールから漏れている典型にも注意してください。

各サービスの利用規約と著作権、およびお住まいの法域での利用条件を遵守してください。本稿はネットワークトラブルシュートの整理であり、規約違反や回避行為を推奨するものではありません。

最終チェックリスト（コピー用）

  1. 症状が API／静的 CDN／メディア のどれで止まっているか、Network と Clash ログで切り分けたか。
  2. DNS が二重に効いていないか（ブラウザ DoH、アプリ内 DNS、OS、Clash）。
  3. ルール順でより広い GeoIP や DIRECT 行が先食いしていないか。
  4. ログから拾った FQDN をサフィックス化し、再現テストを回したか。
  5. TUN／システムプロキシ／VPN の競合を切り分けたか。

まとめ

TikTok や CapCut Cloud の「半通」は、表向きのドメイン一つでは説明できず、ByteDance CDN と API が Policy 上で分裂していることがほとんどです。購読ルールのコピペに頼らず、Connections ログで FQDN を足していくほうが、製品更新にも強いです。DNS・ルール順・TUN の三本柱を同時に揃えると、クリエイターツールチェーン全体の体感が一気に改善することも多いです。

可視化とプロファイル管理がしやすいクライアントに寄せると、確認のループも短くなります。→ Clash を無料ダウンロードし、TikTok／CapCut 利用時の接続ログを一度棚卸ししてみる