X と Grok のトラフィックは「複数ホストの合唱」
ブラウザ版の X と組み込みの Grok 体験は、単一の x.com だけで完結しません。メインの HTML、静的アセット用 CDN、リアルタイム更新やメディア配信用の別ホストが同時に動き、そのどれか一つでも意図せず DIRECT のまま「届かない回線」へ出ると、全体としては真っ白な画面、アイコンと動画だけ無限ロード、会話が途中で止まるといった症状に見えます。体感としては遅延というより経路がそもそもプロキシに乗っていないケースが多いです。
2026 年前後の実運用では x.com が入口として定着しつつ、リダイレクトや埋め込みで twitter.com 系、画像・動画の *.twimg.com、短縮リンクの t.co などが絡みます。Grok アクセス用のホスト名はプロダクト更新で増減しやすいため、固定リストを暗記するよりログで失敗 FQDN を拾い、ローカルルールに足す方が安全です。大切なのは、購読ルールセットに任せきりにせず、ソーシャルメディア向けの明示ルールを GEOIP や広すぎる国内直結より前に置くことです。
再現用の最小例:ポリシーグループとドメインルール
以下は概念デモです。既存の proxies 名や購読構成に合わせて置き換えてください。Clash Meta(Mihomo) 系を想定し、コメントは英語のみとしています。
proxy-groups:
# Stable manual pick for social + Grok web
- name: SOCIAL-AI
type: select
proxies:
- HK-STABLE
- US-STABLE
- DIRECT
rules:
# Put explicit social domains BEFORE broad GEOIP DIRECT
- DOMAIN-SUFFIX,x.com,SOCIAL-AI
- DOMAIN-SUFFIX,twitter.com,SOCIAL-AI
- DOMAIN-SUFFIX,twimg.com,SOCIAL-AI
- DOMAIN-SUFFIX,t.co,SOCIAL-AI
- DOMAIN-SUFFIX,pscp.tv,SOCIAL-AI
# Add Grok / xAI hosts from live logs (names change over time)
- DOMAIN-SUFFIX,x.ai,SOCIAL-AI
# ... your GEOIP / MATCH rules follow
実機では RULE-SET で公式・コミュニティのリストを引きつつ、上のようなローカル追記を「上書き専用ファイル」にまとめておくと、購読更新で消えにくくなります。DOMAIN-KEYWORD,twitter のような広い書き方は他サービスを巻き込みやすいので、まずは DOMAIN-SUFFIX とログ根拠を優先してください。
ポリシーグループ:速さより「切り替わりすぎない」こと
タイムラインも Grok も、多数の TLS セッションと長めの接続に依存します。間隔の狭い url-test だけに任せると、ハンドシェイクの途中で別ノードへ跳ばされ、結果として間欠的にだけ失敗する挙動が出やすくなります。現実的には Selector で手動固定するか、計測間隔を長めに取った url-test/fallback を併用し、検証済みの 1〜2 ノードを軸にするのがClash Twitter プロキシ用途では扱いやすいです。
空港系のリモートルールをそのまま信じる前に、マージ後の評価順と重複する DOMAIN 行を一度眺めてください。「ノードが弱い」の前にルールが意図と逆順というパターンの方が多いです。
ルール順:国内直結が先だと X 分流が死ぬ
典型的なつまずきは、冒頭に広い GEOIP や「国内サイトは DIRECT」の塊があり、その後ろにソーシャル用のサフィックスが追いやられている構成です。CDN のエッジ選定によっては、ブラウザが取りに行くホストが意図しないカテゴリに分類され、画像だけ・API だけが落ちます。対策は単純で、確定している DOMAIN-SUFFIX/RULE-SET を先に置き、最後に広い GEOIP や MATCH を置く、という骨格に戻すことです。
国内直結と海外プロキシの地盤づくり自体は、分流ルールの最適戦略で扱っている考え方と同じです。本稿では GEOIP の細部を繰り返さず、マージ結果の中でソーシャルメディア行が実際にどの位置にあるかだけを強調します。
DNS と fake-ip:「トップだけ開く」の正体
fake-ip を使う構成では、メインドキュメントと静的リソースで見えている IP と実際の接続経路がズレることがあります。症状としてはアドレスバーは正常でもサムネイルが出ない、といった部分的成功が出やすいです。ノードを総入れ替えする前に、ログで失敗ホストがどのポリシーに落ちたかを確認し、DIRECT のままならルール不足、プロキシに乗っているのに失敗ならノード側、と分岐させると早いです。
TUN モード と併用する場合は、OS やブラウザの DNS が Clash の外に逃げていないかも見てください。ルールは「どの出口へ送るか」、DNS は「どの名前空間を見ているか」——この二つが噛み合わないと、設定をいじっても表面症状だけがループします。
公式アプリとブラウザ:挙動が別物になり得る
デスクトップ/モバイルの公式クライアントは、独自の DNS、QUIC、証明書ピン留めなどでブラウザと経路が分岐します。ブラウザでは安定しているのにアプリだけおかしいときは、いきなり巨大なルール変更をせず、まずブラウザでルールとノードを検証し、VPN/TUN がアプリのトラフィックを捕捉できているかを切り分けるのがコスト低です。
端末メーカーやキャリアの省電力・データ節約機能がバックグラウンド接続を切っているケースもあるため、OS 側の制限もあわせて確認するとよいでしょう。
切り分けチェックリスト
タイムラインだけ真っ白
api や stream、CDN 系のサブドメインがまだ DIRECT になっていないか、接続ログでフィルタしてください。ノード変更より命中ルールの修正が先です。
Grok の返答が途中で切れる
ポリシーグループの自動切替や UDP の扱い、他製品による HTTPS インスペクションが重なっていないかを疑い、単一ノード固定で再現性を見ます。
Wi‑Fi とモバイルデータで挙動が違う
キャリア DNS や IPv6 の有無が異なると、同じ端末でも解決経路が変わります。両方の環境でログを比較し、必要なら DNS やルールを分けます。
まとめ:X 分流は「ドメイン・DNS・ポリシー」の三角形
インターネット上の話題は移り変わっても、トラブルシュートの型はあまり変わりません。まずログで失敗リクエストがプロキシに入ったか、どのグループに入ったかを確定させ、次にルール順と DNS、最後にノード品質へ進む——この順番を守ると、「半日サブスクをいじったが実は DOMAIN が一つ足りなかった」という徒労を減らせます。Grok アクセスやタイムライン閲覧のようにソーシャルメディア プロキシ全体を快適にしたい場合も、同じ三角形に立ち返るのが近道です。
クライアントの導入や購読の取り込みがまだなら、当サイトのダウンロードページから入手し、購読 URL チュートリアルで土台を整えてから本稿のルールを足すとスムーズです。オープンソースのソースコードや議論は各プロジェクトの GitHub で追えますが、初回インストールのパッケージはサイト経由で揃えると取り違えが減ります。→ Clash を無料ダウンロードし、X と Grok の経路を手元で試す