📖 チュートリアル ⏱ 約18分で読めます

2026：Grok と X（Twitter）を Clash で安定利用するドメイン分流と DNS（実測）

Grok（xAI）とX（旧 Twitter）は、2026 年も検索需要の高い組み合わせです。ブラウザや公式アプリでは、タイムライン表示、メディア取得、ログイン／決済フロー、そして Grok 系のチャットやAPI呼び出しが、別ドメインに分散しやすい構造になっています。その結果、「タイムラインは出るのに画像だけ真っ白」「Grok だけ応答が途切れる」「curl からの API だけタイムアウト」といった症状は、単一の PROXY 行に頼るより、ドメイン分流とDNS（fake-ip・DoH を含む）を揃えた方が切り分けが速くなります。本稿は ChatGPT／OpenAI 向け記事、Gemini 向け記事、Claude 向け記事とホスト集合を明確に分離し、Clash（多くの場合 Clash Meta／Mihomo コア）で x.com 系と x.ai 系を想定したルール例、名前解決の注意点、Rule モードでのログ実測までを日本語で整理します。サービス側のエッジ構成は更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。

Grok と X が「一体に見える」のに、ネットワークでは分岐する理由

プロダクト体験上はアカウントや画面遷移が近い一方、TLS で実際に繋がるホスト名は、ソーシャル本体・静的アセット・認証・AI バックエンドでバラけやすいのが現実です。X では x.com を中心に、画像や動画の取得で twimg.com や video.twimg.com などが現れ、旧来の twitter.com へのリダイレクトや互換ホストが残る場合もあります。Grok や xAI 周りでは x.ai 配下のサブドメイン、開発者向けなら api.x.ai のようなAPI エンドポイントがドキュメント上の代表例として挙がることがあり、ブラウザのチャット UI と CLI／SDK が別 FQDNを叩く典型になります。

ここで分流が曖昧だと、(1) タイムラインは速いがメディアだけ別経路に落ちて読み込み失敗、(2) Web の Grok は動くが API だけシステムプロキシを読まずに直出し、(3) fake-ip で返した擬似 IP と実際の転送先が噛み合わず証明書や接続リセットに見える、といった部分的成功が起きがちです。用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読するとスムーズです。

分流の土台：用途別の proxy-groups を切る

購読テンプレの PROXY を直接指すより、XSocialProxy と XaiGrokProxy のように用途名のグループを select または url-test で分け、rules からは常にその名前を参照するのが運用しやすいです。同一ノードに寄せてシンプルにするか、ソーシャルと API で遅延の良い出口を分けるかは後から変更しやすくなります。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレ内のグループ名綴りと rules の参照が一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態のまま DNS だけ疑いがちです。

X（Twitter）側でよく現れるホストの考え方

タイムラインやポスト閲覧では x.com が主軸になり、サムネイルや添付メディアで pbs.twimg.com など twimg.com 系が混ざることが多いです。動画ストリーミングでは別サブドメインが増える場合もあります。ログインや決済でサードパーティの決済ドメインが挟まることもありますが、本稿の焦点は「X 本体＋主要 CDN」に置きます。方針として、(A) x.com と twitter.com と twimg.com を同じ XSocialProxyに寄せるのが素直で、(B) メディアだけ別ノードにしたい場合は DOMAIN-SUFFIX,twimg.com だけ別グループ、も可能です。(C) 広い DOMAIN-SUFFIX は手早い反面、意図しないサブドメインまで同じ出口に乗るため、運用後はログで必要範囲に絞るのが安全です。

rules:
  # Examples only — tune group names and domains to your logs
  - DOMAIN-SUFFIX,x.com,XSocialProxy
  - DOMAIN-SUFFIX,twitter.com,XSocialProxy
  - DOMAIN-SUFFIX,twimg.com,XSocialProxy

モバイル公式アプリは追加のテレメトリや別ホストを使うことがあり、ブラウザと完全一致しない場合があります。そのときは接続ログに出た FQDN をそのまま DOMAIN や DOMAIN-SUFFIX で足してください。

Grok／xAI 側：Web と API を分けて見る

Grokのブラウザ体験は X 内の導線と xAI ドメインが混在しうるため、ログで実際に TLS で繋いでいるホストを確認することが重要です。開発者向けのHTTP APIでは、ドキュメント上 api.x.ai のようなエンドポイントが例として挙がることがありますが、プレビュー版やエンドポイント統合でホストが入れ替わる可能性は常にあります。OpenAI や Anthropic の記事と同様、base URL の文字列とログの FQDNを突き合わせないままルールを写経すると取りこぼしが出ます。

rules:
  # Examples only — verify against your client logs
  - DOMAIN-SUFFIX,x.ai,XaiGrokProxy
  - DOMAIN-SUFFIX,api.x.ai,XaiGrokProxy

サードパーティの非公式クライアントやラッパーサイトは別ドメインになることが多く、本稿のリストとは一致しません。社内ゲートウェイ越しに独自名を割り当てている場合も、ルールはクライアントが解決した名前基準で書きます。

DNS と fake-ip：ルールより前に潰れる名前解決の落とし穴

分流ルールが正しくても、DNS の応答が期待と違うと、タイムアウトや証明書警告に見えます。Clash／Mihomo 系では dns ブロックの fake-ip モードは、ルールマッチングを速くする一方で、(1) アプリが独自にキャッシュした IP とコア側のマッピングがずれる、(2) ブラウザの Secure DNS（DoH）と二重に効いて挙動が読みにくい、といった典型的な摩擦を生みます。比較実験ではブラウザ側 DoH を一時オフにし、一度に一項目だけ設定を変えるのが安全です。

nameserver-policy で x.com や x.ai だけ信頼できる upstream に寄せる、IPv6 の有無と OS の解決順を確認する、なども有効です。CLI やコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY の明示を検討してください。ルールの優先順位は、具体的な DOMAIN を広い RULE-SET や MATCH より上に置く原則が、API の取りこぼし防止に効きます。

⚠️ 注意 API キーやアクセストークンは設定ファイル・環境変数に残りやすいです。リポジトリにコミットしない・共有端末では権限を絞るなど、セキュリティはプロキシ設定とは独立して確認してください。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は一時的に「ルール不足かノード品質か」を切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。X か Grok か片方だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

実測手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから X を開き、同じ端末から可能なら Grok 利用や API の疎通を試し、症状が再現するかを記録します。ローカル回線やプロバイダ要因の切り分けにもなります。

  2. 2

    Rule に戻し、タイムライン・メディア・Grok／API それぞれでログを読む

    接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合はログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI 変更や CDN 切替にも追従しやすくなります。職場・学校など組織ネットでは、技術的に可能でも規程と管理者の指示を優先してください。

よくある質問

タイムラインは出るのに画像や動画だけ出ない

twimg.com などメディア用ホストが DIRECT のまま、または意図しない地域の出口に乗っているパターンが多いです。ログで該当 FQDN を特定し、XSocialProxy 側へ寄せてください。

ブラウザの Grok は動くが API だけ失敗する

ターミナルやコンテナがシステムプロキシを読んでいない、または別の DNS キャッシュを参照している可能性があります。環境変数、TUN、実行ユーザの違いを確認し、ログに出た API 用ホストをルールに足してください。

DOMAIN-SUFFIX,x.ai を広げすぎたくない

まずログで実際に使うサブドメインを列挙し、必要なら DOMAIN 行でピンポイントに足します。将来のホスト追加に備え、定期的にログレビューを挟むのが現実的です。

まとめ

GrokとXのように、プロダクト上は近いがTLS 上のホストが分岐しやすい組み合わせでは、ドメイン分流をソーシャル本体・メディア CDN・xAI／API に分解し、DNS（fake-ip・DoH を含む）とRule モードでのログ検証をセットにすると、「海外 AI＋ソーシャルを日常運用で安定させたい」という目的に沿いやすくなります。本稿の例は出発点であり、ログに基づきルールを育てることが長く使うコツです。OpenAI 公式は ChatGPT の記事、Google 系は Gemini の記事、Anthropic 系は Claude の記事で別ホスト集合として扱っているため、混同せず参照してください。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。

→ Clash を無料ダウンロードし、Grok／X 向けの分流と DNS を試す