Web が空白・スピナーのまま——Threads だけで起きやすい理由

ブラウザで Meta Threads（threads.net）を開いたとき、他のサイトは普通なのに、タイムライン枠だけ真っ白、ヘッダーだけ出て本文が永遠に回る、ログイン画面が終わらない——といった症状は、X（旧 Twitter）と並ぶ話題サービスゆえに検索でも多いThreads 開かない系の相談です。シングルページアプリ（SPA）は初期の HTML のあと、別ドメインの JavaScript バンドル・スタイル・画像・API 呼び出しを同時並行で取りに行きます。Clash 分流で www.threads.net だけをプロキシに載せ、静的資産や API が載る Meta 共通 CDN が直結や別ルールに抜けると、見た目は「ずっとくるくる」や部分的白画面に見えます。

層を分けてドメインを足すという意味では、Reddit の redd.it・CDN 分流記事 や Telegram の短縮ドメイン分流 と同型です。製品が違うのでホスト集合は別物であり、購読ルールのパッケージ名だけ信用せず、自分のブラウザのネットワークタブと Clash ログで実名を拾う前提が安全です。

threads.net 本体と「メインだけ通った」罠

アドレスバーに出るのは概ね www.threads.net と threads.net です。ここだけ PROXY に乗り、背面の取り込みがうまくいっていればタイトルは表示される一方で、実体のフィード描画は別ホストのスクリプトに依存します。環境によってはリダイレクトチェーンの途中で短いサブドメインが挟まることもあります。

Meta Threads 代理と検索する利用者向けの実務ポイントは、本体行を一本足すだけで満足せず、次節のCDN・API 層まで同じ select グループに束ねることです。YAML の書き方の共通語は YAML・Fake-IP とルール分流の解説 で押さえられます。

静的資産と API：fbcdn、cdninstagram、graph 周辺

Meta 傘の Web では、画像・スクリプトの一部が fbcdn.net 系（例：static.xx.fbcdn.net のようなホスト）や、Instagram と横断されやすい cdninstagram.com・scontent*.cdninstagram.com などに乗ることがあります。データ取得は graph.instagram.com など Graph API に相当する名前がログに現れるケースもあります（サービス側の構成変更で増減します）。

本稿に挙げるホストはすべて概念スケッチ用の例です。実際の Clash クライアントの接続ログやブラウザの開発者ツールで、失敗している（タイムアウト・ブロック・意図しない DIRECT）ホスト名をコピーして DOMAIN-SUFFIX に足してください。Threads が開かないのに他の Meta サービスは気にしない、という narrow な要件なら、広すぎる instagram.com 一行は影響範囲を見て分割するか、ログで絞り込むと安全です。逆に、Instagram もまとめて同じ出口にしたいなら、同じグループに寄せる設計でも構いません。

大枠のルール順と DNS の関係を整理したい場合は ドキュメントの DNS・Fake-IP 節 も参照してください。

ルール例（THREADS グループ・環境依存で要検証）

以下は threads.net と CDN を含めた骨格です。THREADS は select 型の例で、安定ノードに切り替えやすくします。購読の RULE-SET より上に置くか、MATCH の出口と矛盾がないかは環境ごとに確認してください。

# Concept only — verify hostnames from your client logs; adjust vs subscription RULE-SET order.
proxy-groups:
  - name: THREADS
    type: select
    proxies:
      - node-stable-1
      - node-backup
      - DIRECT

rules:
  - DOMAIN-SUFFIX,threads.net,THREADS
  - DOMAIN-SUFFIX,fbcdn.net,THREADS
  - DOMAIN-SUFFIX,cdninstagram.com,THREADS
  # Optional if logs show graph calls; scope may overlap other Meta apps:
  - DOMAIN-SUFFIX,instagram.com,THREADS
  - MATCH,PROXY

instagram.com 行は Instagram 本体とも共有しやすいため、ルール競合や直結したいアプリがある場合は外す・別グループに分けるなど、自分のポリシーに合わせてください。DOMAIN-KEYWORD,threads のような広い書き方は、意図しないホストにマッチしやすく、基本はサフィックスとログ実名の組み合わせを推奨します。

ヒント

公式のルールセットに「facebook」や「instagram」カテゴリがあっても、Web 版 Threads だけ不調なときは、threads.net 行を購読ルールより上に持ってきてヒット確認すると早いです。新サブドメインはリストより先に現場ログが先に変わります。

TUN、システムプロキシ、ブラウザの取り込み差

Threads は主にブラウザ利用が前提で、OS やブラウザがシステムプロキシに従わない、拡張が別経路を使う、別プロファイルだけ例外になっている、といった差が出ます。トラフィックがコアに届いていない状態では、ドメイン表を増やしても症状は変わりません。Windows で TUN を使う場合は TUN のトラブルシューティング で仮想アダプタや他 VPN の競合を先に切り分けてください。

DNS・Fake-IP と名前解決のねじれ

ルールはドメイン文字列でマッチするため、DNS の応答と Fake-IP のフィルタ設定が実 TLS 接続とずれると、見かけ上はプロキシ経由のはずが別出口になることがあります。症状が「threads.net だけ」なのか「Meta 系まとめて」なのかで、nameserver-policy や fake-ip-filter の見直し方も変わります。詳細は前述の Fake-IP 解説と GUI の表示を突き合わせてください。

切り分けチェックリスト

  1. threads.net：www 付き・なしともに同じ THREADS（または同等）に入っているか。
  2. fbcdn / cdninstagram：スクリプト・画像のホストがメインと同じ出口か（部分的白画面の典型）。
  3. graph・API 名：ログに出たホストがルールに含まれ、不要な DIRECT 抜けがないか。
  4. ルール順：購読の一般ルールに先に飲まれていないか、逆に重複や広すぎる行がないか。
  5. DNS：Fake-IP と実接続の一致。reddit 記事と同様、レイヤずれは DNS から疑う。
注意

各サービスの利用規約、居住地域の法規、職場・教育機関のネットワークポリシーは異なります。本稿は一般的なプロキシ設定の説明であり、特定サービスの利用を推奨・保証するものではありません。

まとめ

Meta Threads の Web が白画面や読み込みのまま止まるとき、threads.net 単体のルールだけでは足りず、Meta 系 CDN・API 周辺ホストまで同じ Clash 分流ポリシーに揃えるのが要点です。テキストは出るが画像や操作が死んでいるときは、まず静的ホストの出口食い違いを疑うと早いです。他サイトよりルールとログの対応が追いやすいのが Clash 系クライアントの利点です。

安定した配布物から試すなら、ダウンロードページ で OS に合わせて選ぶと、GUI とコアの対応を追いやすいです。ソースは挙動理解に有用ですが、実行ファイルの主な入手先は配布ページに寄せるのがおすすめです。→ 無料で Clash をダウンロードし、Threads 向けの出口をログで確認する