Grok や X（Twitter）が開かない？xAI 系と X 系ドメインを Clash / mihomo で分流する実測メモ（2026）

1. 他の AI 向け記事と何が違うか（xAI と X）

当サイトでは、ChatGPT 向けの固定ノード・fallback、Claude / Anthropic の地域表示と DNS（fake-ip）、Gemini / Google AI の広いドメイン散らばりと QUICを別稿で扱っています。いずれも「見えているホストより裏で別名義の通信が増える」点では共通ですが、xAI は比較的新しく、エンドポイント名がドキュメント更新とともに増えやすい一方、X は CDN・動画・API が長年にわたり複数サフィックスに分岐してきた経緯があります。

したがって本稿は「Grok の製品紹介」ではなく、2026 年時点で切り分けに効くドメイン次元の話に絞ります。利用規約・法令・各サービスの許容地域は技術とは別レイヤーです。本稿は一般情報であり、特定サービスの利用を推奨・保証するものではありません。

購読の取り込みや初期設定は サブスクリプション導入ガイドを参照しつつ、以下では xAI 系と X 系のホスト名の束ね方に焦点を当てます。

2. 切り分けは「ドメイン」「DNS」「QUIC」の三層で考える

第一層はルーティング（ドメイン分流）です。x.com だけをプロキシに載せても、画像や API が pbs.twimg.com など別ホストへ飛ぶと、テキストだけ表示されメディアが真っ白のような症状が出ます。ここは DOMAIN-SUFFIX などで関連ホストを同じ策略グループへそろえるのが基本です。

第二層がDNSです。fake-ip やローカル DNS の出口と、実際の TCP/UDP 接続の策略が食い違うと、「名前は解けているのに想定と違う国のノードに出ている」といった見えにくいズレが起きます。ルールは正しくても体感が悪いときは、ここを疑う価値があります。

第三層がHTTP/3（QUIC）です。UDP 上の QUIC は、プロキシ実装・ノード・端末のファイアウォールとの相性で、TCP の HTTPS より断続的に失敗しやすい場面があります。X の Web や一部のモダンブラウザ経路で、Gemini 稿と同様の切り分けが有効なことがあります。

3. xAI / Grok 側で押さえたいホスト名

サービス側の構成は変わり得るため、常に公式ドキュメントや開発者コンソールの通信先と突き合わせる前提で読んでください。切り分けの出発点として、ブラウザやアプリの挙動からよく登場するのは x.ai 配下や、API・認証まわりで api.x.ai といった名前です。Grok を X 上の体験として使う場合は、フロントが X 側・推論が xAI 側に分かれるため、片方だけ国内直結のままだと「会話 UI は出るが応答が返らない」タイプの不整合が起きやすいです。

ルールの評価順は ルールルーティング解説のとおり、具体的な DOMAIN 行を、広い GEOIP や MATCH より上に置きます。購読ルールセットの末尾に追記するだけでは効かないことがある点に注意してください。

開発者向けに SDK やサンプルから別ホストが増えた場合は、開発者ツールやコアログで失敗しているホスト名を足し込む運用が安全です。最初から広すぎるサフィックスを取り込むと、意図しないトラフィックまで同じノードに流れ、遅延や課金の前提を崩すことがあります。

4. X（Twitter）側で押さえたいホスト名

X は長らく twitter.com 系と twimg.com 系の静的配信が中心でしたが、ブランド移行に伴い x.com が表に出ます。実務では 両系統を同じ策略に載せるか、ログを見て不足があれば追加するのが扱いやすいです。画像・動画は pbs.twimg.com や video.twimg.com など、サブドメインが細かく分かれるため、DOMAIN-SUFFIX,twimg.com のようにサフィックスで束ねる例がよく使われます。

モバイルアプリやサードパーティクライアントでは、Web とは別ホストが増えることがあります。症状が「Web だけ」「アプリだけ」に分かれるときは、そのクライアント専用の名前解決ログを優先して確認してください。

TUN モードやシステムプロキシでは、DNS の通り道も絡みます。モードごとの違いは TUN モードの解説も参照し、名前解決と実接続の策略が矛盾していないかをログで確認してください。

5. mihomo ルール例：専用策略グループへまとめる

実務では xAI+X 用の策略グループを一つ用意するか、xAI 用と X 用で分けるかを、ノードの地理・遅延・ログ上の挙動から選ぶとよいでしょう。分ける利点は、片方だけ別地域ノードを試しやすいことです。合わせる利点はルールが単純になることです。

以下は構造の例です。プロキシ名は環境に合わせて置き換えてください。コメントは英語表記としています。

# proxy-groups: one group for xAI + X (split into two groups if you prefer)
proxy-groups:
  - name: XAI_X
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: keep specific DOMAIN lines above broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,x.ai,XAI_X
  - DOMAIN-SUFFIX,api.x.ai,XAI_X
  - DOMAIN-SUFFIX,x.com,XAI_X
  - DOMAIN-SUFFIX,twitter.com,XAI_X
  - DOMAIN-SUFFIX,twimg.com,XAI_X
  - MATCH,PROXY

上記は出発点です。手元のログに grok や xai を含む別ホストが出たら、そのサフィックスを同じグループへ追加してください。逆に、仕事用の別ドメインまで誤って同じノードに流さないよう、広すぎるワイルドカードは避けるのが安全です。

6. DNS（fake-ip・解決経路）でズレるパターン

Claude 向け記事で触れたように、fake-ip と実接続の策略が噛み合わないと、サービス側から見た出口やキャッシュ挙動が期待とずれることがあります。xAI や X でも、ブラウザ拡張・別 DNS アプリ・OS の VPN プロファイルが同時に有効だと、名前解決だけ別ルートに逃げるケースがあります。

切り分けでは、（1）コアの DNS ログで問い合わせがコアを通っているか、（2）接続ログでマッチした策略名が意図どおりかをセットで見ると早いです。「ping が通る／通らない」だけでは、HTTPS の SNI やプロキシ内ルールと一致しないことがある点にも留意してください。

企業ネットワークでは分割 DNS が入ることがあり、自宅と同じ YAML を持ち込んでも再現しない場合があります。そのときは社内ポリシーとセキュリティ要件を優先し、本稿の手順はあくまで個人環境向けの参考として扱ってください。

7. QUIC / HTTP3 が絡むときの症状と試し方

QUIC が原因候補になりやすいのは、TCP の HTTPS では安定しているのに特定ブラウザだけ不安定、プロキシの UDP 設定やノードを変えると成功率が変わるといったときです。詳しい無効化手順は Gemini / QUIC の記事に譲り、本稿ではX や Grok の Web を触っているときも同じ切り分けを併用できる点だけ押さえておきます。

Chromium 系では chrome://flags や edge://flags から Experimental QUIC protocol を無効化し、再起動して比較するのが手軽です。Firefox でも HTTP/3 関連設定を一時オフにして試せます。設定名はバージョンで変わるため、画面上で QUIC や HTTP3 を検索すると見つけやすいです。

QUIC を切っても改善しない場合は、ドメイン漏れや認証エラー、レート制限など別要因のサインかもしれません。ブラウザ操作は切り分けの一手段にとどめ、HTTP ステータスとコアログを併記してください。

8. 実測の進め方：ログでホスト名を拾う

おすすめの順序は次のとおりです。（1）コアのログで、問題操作中にどのホストがどの策略にマッチしたかを確認する。（2）意図したグループに揃っているのに不安定なら、DNS ログと fake-ip 設定を確認する。（3）それでも断続的なら、ブラウザで QUIC を無効化して同じ操作を繰り返す。（4）改善するなら UDP 経路やノード側制限を疑い、別ノードで比較する。

開発者ツールのネットワークタブで赤くなっているホスト名をメモしておくと、ルールに足すサフィックスが具体的になります。体感の「なんとなく直った」ではなく、どの名前が残っていたかを残すのが再現性を上げるコツです。

API や CLI を併用する場合は、ブラウザとDNS の通り道が違うことがあります。失敗している側の名前解決ログを優先して見てください。

9. つまずきやすいポイント

第一に、ルールの順序ミスです。広い MATCH や GEOIP が先に勝ってしまうと、細かく書いた X 用行が死んでいることがあります。ルールの並びを購読ファイル全体で見直してください。

第二に、過剰な DOMAIN 取り込みです。関係のないドメインまで同じ海外ノードに流すと、遅延や課題が増えるだけでなく、他サービスのトラブルシュートを難しくします。ログに出た分から足す方が運用は楽です。

第三に、利用規約と法令の順守です。技術的に経路を整えられることと、各プラットフォームが許容する利用形態は別問題です。アカウントの状態や表示メッセージは、プロキシ以外の理由も考慮してください。

10. まとめ

Grok / xAIとX（旧 Twitter）は、話題上は近いことが多くても、プロキシ設定では別ドメイン群として束ねるのが安定しやすいです。まず mihomo の DOMAIN ルールで関連ホストを同じ策略に揃え、ズレが疑わしければ DNS、断続的な失敗が続くなら QUIC 無効化——この三段は、ChatGPT・Claude・Gemini 向けの各稿と重ならない補助線になります。

同じ Clash 系クライアントでも、コアの世代と GUI の表記は移り変わります。手元の環境を最新に近づけ、購読とルールを整理したうえでログを追うのがいちばん確実です。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから整えるのがおすすめです。