1. 「くるくる」が示すもの：Grok と X は別ドメインの束
ブラウザで Grok を開いたとき、骨格だけ表示され本文が永遠に流れ込まない。あるいは X 本体は動くのに、Grok パネルだけ応答が始まらない。こうした症状は、ユーザーから見ると「AI が重い」に見えがちですが、裏側では複数ホストへの並列リクエストの一部が TLS 失敗・タイムアウト・誤ルーティングで詰まっているケースが典型です。Clash の接続一覧に出るホスト名と実際に選ばれたポリシーを並べると、想像以上に早く切り分けが進みます。
設定の全体像をまだ把握していない場合は、先にサブスクリプション取り込みの記事で YAML の骨格とルールモードを押さえておくと、以降の手順が読みやすくなります。
2. 通信を「層」に分ける：SNS 本体・メディア・xAI
実際のホスト名はプロダクト更新で変わり得るため、開発者ツールのネットワーク欄と Clash のログに出た名前を正とします。設計メモとして、次のような役割分けを頭に置くとルールが書きやすくなります。
| 層 | イメージ | 切り分けのポイント |
|---|---|---|
| X の UI／API | x.com、api.x.com、旧 twitter.com 系 | TL は出るが Grok だけ止まるなら、別ホストが DIRECT に落ちていないか。 |
| メディア CDN | pbs.twimg.com、video.twimg.com など twimg 系 | 画像だけ欠ける・動画だけ回る症状と相性がよい。広すぎるサフィックスは副作用に注意。 |
| 短縮・計測 | t.co など | リンク遷移だけ失敗するパターンで浮きやすい。 |
| xAI／Grok | x.ai 配下、Grok 用サブドメイン | チャット送信後だけ固まるなら API／ストリーム系を疑う。 |
重要なのは、「X にログインできれば Grok も通る」ではないという点です。フロントは初期表示のあと、別ホストからスクリプト・認可・推論ストリームを引きに行くため、一枚岩のドメイン想定でルールを書くとすぐ破綻します。
3. ドメイン収集：ブラウザと Clash の両方で拾う
収集の基本は次の二系統です。どちらか片方だけでは取りこぼしが出やすいので、併用してください。
- ブラウザの開発者ツール（ネットワーク）を開き、X と Grok をハードリロード。フィルタを外し、ドメイン列を眺めて
x.com、twitter、twimg、x.ai、明らかに CDN らしいホストをメモする。 - Clash（Mihomo 対応 GUI なら接続ビュー）で、同じ操作のあとに現れた接続行を時系列で並べ、
DIRECTや想定外のポリシーに落ちている名前をマークする。 - Grok へメッセージを送信した直後だけ増えるホストがあるため、ストリーミングを一度走らせたあとにもう一度ログを眺める。
- 重複やワイルドカード化できそうなサフィックスを整理し、購読ルールより手前に置くべき具体ルールとして YAML に落とす。
ポートやプロセス周りの一般的な詰まりはトラブルシュート記事へ。本稿は X／xAI 特有のマルチドメイン構成に焦点を当てます。
4. 推奨する切り分け順序
- Clash が起動していること、システムプロキシかTUNのどちらでブラウザトラフィックを握っているかを確認する。
- 接続ログで X／Grok 関連ホストが、意図したポリシーグループに入っているか、誤った
DIRECTがないかを見る。 fake-ipを含む DNS 設定を確認し、必要なら主要サフィックスへnameserver-policy等を当てて名前解決のブレを減らす。- メディア CDN・メイン UI・xAI バックエンドをホスト／サフィックス単位でルール化し、購読内の広い
DIRECTより上側に矛盾なく配置する。 - ルールが意図どおりになったあとで、遅延の揺れが少ないノードを選び、過剰な自動切替を避ける。
5. システムプロキシと TUN：ブラウザでも取りこぼしがある
OS のシステムプロキシに Clash の mixed ポートを指定する方法は手軽ですが、プロキシ設定を読まないコンポーネントや、拡張機能・別プロファイルのブラウザが混ざると、見かけ上「同じ Chrome なのに別経路」が起きます。TUN はルーティング層でトラフィックを取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで関連ホストがすべて期待どおりの経路になったか検証してください。
6. DNS／fake-ip：名前解決とルール判定のズレ
fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。X のようにサブドメインと CDN が多いサービスでは、軽いズレでもフロントがリトライを繰り返し、ユーザーにはただのローディングに見えます。Grok まわりも同様で、認可とストリームが別ホストに分かれていると症状が読みにくくなります。対策の基本は、上流 DNS を信頼できるものにそろえ、収集した主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。
7. 分流ルールの考え方（記述例は置き換え前提）
購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。twimg.com のようなサフィックスは他用途にも使われることがあるため、ログに出た特定サブドメインに絞るか、ルールセットの細分化を検討してください。
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,x.com,PROXY
- DOMAIN-SUFFIX,twitter.com,PROXY
- DOMAIN-SUFFIX,twimg.com,PROXY
- DOMAIN-SUFFIX,x.ai,PROXYGrok 用ストリームだけ別グループ（例：PROXY_AI）に分け、X のメディア取得（PROXY_CDN）と切り離すと、障害時の切り分けが容易になります。グループ名は proxy-groups に定義済みである必要があります。
8. 他の AI 向け記事との違い
OpenAI 系はChatGPT 向け分流記事、対話型検索はPerplexity 向け記事が軸になります。DeepSeek、GitHub Copilot、Claude も別記事でホスト構成を整理済みです。本稿はそこからスコープを移し、X 上の Grok 利用と xAI バックエンドに絞ります。複数の生成 AI を併用する環境では、プロダクトごとにポリシーグループを分けておくと、片方の障害が他方のルール調整を汚染しにくくなります。
9. ノード選定：瞬間最速より「揺れの少なさ」
スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、ストリーミング応答型のチャット UI には不向きです。TLS の再ハンドシェイクが増え、ブラウザ側はリトライやタイムアウトとして現れます。手動選択で様子を見たり、xAI 専用グループを作って安定路線に固定するのが実用的です。プロトコル特性の比較はプロトコル比較記事も参考になります。
10. 追加の落とし穴：Cookie ドメイン・拡張機能・複数 VPN
x.com と twitter.com が混在する期間は、Cookie や OAuth リダイレクトがドメイン跨ぎになりやすく、片方だけ誤ルーティングしているとログインループに見えます。ブラウザ拡張が独自プロキシを指定していると OS 設定と二重化し結果が読みにくくなるため、検証時は一旦無効化してください。また別製品の VPN と TUN を同時に有効にしている場合、ルートの奪い合いで「ときどきだけ直結」が紛れ込みます。単一路径に戻してからログで確認するのが早道です。
11. まとめ：証拠ベースでドメインを束ねる
Grok の Web が読み込みのまま進まない症状は、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年も AI アシスタントと SNS の境界は流動的なので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。
接続ログと購読更新を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、ルールとコアの整合が取りやすい製品ほど長く運用しやすい印象です。X と Grok を安定して使いたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める