「ずっと読み込み」の正体はネットワーク一箇所とは限らない
ブラウザ上で Grok のような生成 AI の Web UI を開いたとき、画面中央のインジケータが回り続け、本文や入力欄が現れない。こうした体験は、単一の HTTP リクエスト失敗だけでは説明できません。認証トークン取得、WebSocket や SSE 相当の長めの接続、別ドメインの計測や CDN、HTTP/3（QUIC）による UDP 経路など、複数の並行フローが「どれか一つでも詰まる」と UI 全体が前に進まないことがあります。
開発者向けの IDE や Git ホスト（別記事で扱う典型）とは異なり、一般向け AI プロダクトはフロントエンドの分割とドメインの追加が速い傾向があります。したがって「昨日まで動いていたのに今日だけ別ホストが増えた」ことは珍しくなく、ルールを静的な数行で固定し続ける運用ほど差分に弱いです。ここでは xAI 系を例に、分流の考え方と検証の型を押さえ、あとからルールセットを差し替えやすい形にすることを目標にします。
なぜ「xAI だけ別ポリシー」に切り出すのか
多くのプロファイルは、GEOIP や「中国向けサイトは DIRECT」といった広い例外を先に置き、残りをデフォルトで PROXY に流すか、その逆の構成です。AI サービスは CDN やエッジの所在地表示が読者の思い込みとズレやすく、意図せず DIRECT に落ちる、あるいは 逆に過剰にマッチして別の安い出口に乗り、レート制限や追加検証に引っかかる、といったパターンが出ます。
そこで実務的には、AI ツール用の policy-group（または同等の論理出口）を一つ決め、そこに載せるドメイン集合を rule-providers や小さなローカルルールで束ねる方法が扱いやすいです。購読ルールの分割や更新間隔の設計は、当サイトのRule Providers 解説と思想がつながります。ポイントは「ドメインの完全な列挙」より、更新可能な単位でモジュール化し、順序を誤らないことです。
典型ドメインと SNI の捉え方（サービス変更に注意）
公開情報と一般的なブラウザ挙動に基づくと、xAI／Grok 周辺では x.ai 配下の API や管理系ホスト、grok.com 系のエンドポイント、さらに X（旧 Twitter）エコシステムと連携する画面では x.com や twitter.com など別系統のホストが同時に動くことがあります。TLS の SNI はブラウザが選ぶため、ルールが DOMAIN ベースでも、実際のコネクションは サブドメイン単位で増減します。
設定例を示すときは、読者の環境で名前解決とログを見ながら調整する前提で、コピペ一本勝ちを避けるのが安全です。次の YAML はあくまで構造のイメージです（コメントは英語のみ）。
# Illustrative fragments — verify live hostnames in your client logs
rules:
- DOMAIN-SUFFIX,x.ai,GROK_AI
- DOMAIN-SUFFIX,grok.com,GROK_AI
- DOMAIN-SUFFIX,x.com,GROK_AI
- DOMAIN-SUFFIX,twitter.com,GROK_AIDOMAIN-SUFFIX は記述が簡潔ですが、将来サブドメインが増えると意図しない範囲まで同じ出口に乗る副作用もあります。逆に DOMAIN-KEYWORD は短い文字列ほど他社ドメインに誤爆しやすいので、本番プロファイルではルールプロバイダ側のメンテ品質とセットで判断してください。
プロキシグループ設計：フォールバックと遅延計測
AI ツールは長文応答や画像生成など、タイムアウトしやすい往復を伴います。単一の select だけで運用すると、ノードの一時不調のたびに手切り替えが増えがちです。url-test や fallback を組み合わせ、計測 URL と間隔を過激に短くしすぎない（過剰切替でかえって不安定になる）バランスを取ると、体感が安定しやすくなります。
同じグループに「一般ブラウジング用の安いノード」と「AI 向けの高品質ノード」を混ぜると、自動選択が読者の期待とズレることがあります。用途別にグループを分けるほうが、ログ上の「どの接続がどの出口か」も追いやすいです。システム全体をルールの上に確実に載せたい場合は、環境によっては TUN モードの検討余地があります。詳細はTUN モードガイドを参照してください。
誤判定その1：DNS がプロキシ判断より先にズレる
Clash 系クライアントでは、DNS の扱い（redir-host、fake-ip、名前解決を誰が行うか）によって、ルールに渡る前の段階で期待と違う IP が選ばれることがあります。特に fake-ip を用いる構成では、ブラウザや OS のキャッシュ、あるいはブラウザ内蔵のセキュア DNS（DoH）と競合し、症状が「ルールは合っているのに挙動がおかしい」に見えることがあります。
切り分けの実務手順としては、（1）該当ホスト名をクライアントの接続ログで確認する、（2）同じホストを dig や nslookup で見た結果と比較する、（3）ブラウザ側の「DNS over HTTPS」を一時オフにして再現性が変わるか見る、の三段が有効です。社内ポリシーで DoH を必須にしている場合は、Clash の DNS 設定と役割分担を文書化しておくと再発時に速いです。
誤判定その2：直結ルールが先に当たる
GEOIP,CN,DIRECT や「社内ドメインは DIRECT」など、運用上必要な直結ルールは往々にしてリストの上方に置かれます。ここに載っているマッチ条件が広すぎると、AI サービスの一部ホストが意図せず直結に落ち、結果として遅延・リセット・人間確認ページのループに見えることがあります。
対策の基本は、より狭い例外（特定サフィックスやルールセット）を、広い GEOIP より上に置く「順序の逆転」です。ただし上へ寄せすぎると別の衝突が出るため、変更後は必ず数分間ログを眺め、意図しないドメインが新しい出口に流れていないかを確認してください。
誤判定その3：UDP／HTTP3（QUIC）がルートから外れる
HTTP/3 は QUIC（UDP）を使うため、TCP だけを想定した TUN／iptables 系の例外や、UDP を明示的に遮断するネットワークと組み合わさると、ブラウザが自動的にプロトコルを切り替えた瞬間にだけ失敗する、という再現が難しい不具合になりがちです。症状が「ページは開くがチャットだけ進まない」「画像だけ出ない」に偏るときは、UDP の取り扱いを疑う価値があります。
検証としては、ブラウザ側で一時的に HTTP/3 をオフにできる場合は比較実験が速いです。クライアント設定で QUIC 関連の扱いを変えられる実装もあるため、利用中の GUI の項目説明と、Mihomo 側のドキュメントを突き合わせます。オープンソースの挙動確認はMihomo の GitHubが参照先になりますが、パッケージの入手は当サイトのダウンロードページを優先すると、初見の読者が手順を取り違えにくくなります。
検証チェックリスト（現場向け短冊）
次の項目を上から順に潰すと、原因の当たりが速くなります。（1）該当タブだけシークレットで開き直し、拡張機能の干渉を除外する。（2）クライアントの接続ログで、失敗しているホスト名とポート、プロトコル（TCP／UDP）を特定する。（3）そのホストに対するルールの最初のマッチが何かを確認する。（4）DNS のモードとブラウザ DoH の有無を切り替えて再現性を見る。（5）別ブラウザ・別プロファイルで同じか比較する。（6）ノード自体の遅延とパケットロスを url-test 結果と照合する。（7）必要なら TUN とシステムプロキシのどちらで挙動が変わるかを切り分ける。
これらは Cursor や GitHub のタイムアウト調査（別テーマの記事で深掘りしやすい領域）とは観測点が異なります。AI Web UI は長寿命接続とサードパーティホストが絡みやすい点を意識すると、ログの見方がブレにくくなります。
ドキュメント参照とまとめ
画面操作や全体的な導線はドキュメント／チュートリアルも併せて参照してください。ルール設計の基礎体力を上げることは、ホスト名が変わるたびに手作業で追いかける負担を減らします。
Grok（xAI）のように話題の変化が速いカテゴリほど、「特定ドメインの暗記」より「ログで事実を拾い、ルールセットを更新する運用」が効きます。DNS・順序・UDP の三つを軸に切り分け、AI ツール用の出口を独立させれば、他のトラフィックへの副作用も抑えやすくなります。同種のクライアントのなかでも、Clash／Mihomo 系は可視化とルールの差し替えがしやすく、試行錯誤のコストを下げやすいのが強みです。