症状の整理：ホームは開くのに「会話が進まない」

ブラウザで生成 AI のサービスを開いたとき、最初の画面やログインまでは問題なくても、メッセージを送った直後からスピナーが止まらない、あるいは特定の API 呼び出しだけ失敗する——といった挙動は、2026 年現在もサポート問い合わせや検索クエリに頻出します。ユーザーから見れば「とりあえずプロキシをオンにしたのに直らない」「別のサイトは普通に見える」という状態なので、単一スイッチの話では片付きません。

こうしたサービスは、見た目の HTML を配信するドメインと、ストリーミング応答やツール呼び出しを担うホストが分かれていることが珍しくありません。Clash / mihomo における分流ルールは、まさに「どのホスト名の通信を、どの出口（プロキシグループ）に乗せるか」を決める仕組みです。ここが粗いと、ページの骨格だけ別経路、会話本体は意図せず直結、といった部分代理になり、ブラウザ上では一見つながっているように見えて、対話処理だけが壊れることがあります。

なぜ「全部 MATCH でプロキシ」でも直らないことがあるか

ひとつの勘違いは、設定ファイルの最終行をプロキシに向ければ、ブラウザから出る通信はすべて同じノードに揃うはず、という期待です。実際には次の要因で、ログ上はプロキシ経由でもアプリから見た経路が割れます。

第一にルールの順序です。Clash 系はリストの上から評価し、最初にマッチした行で決着がつきます。国内向けの GEOIP や広い DIRECT を先に置きすぎると、AI 向けのサブドメインが意図せず直結側へ落ちます。サブスクリプションで配られる巨大ルールセットをそのまま使う場合も、自前の「AI 用」例外が上書きされない位置にあると効きません。

第二にDNS と実接続のズレです。名前解決で返ったアドレスと、TLS を張る実経路が一致しないと、エッジやリージョンの選択が意図とずれ、ウェブソケットや長めの HTTP ストリームだけが不安定になることがあります。Fake-IP を使う構成では名前解決の見え方が変わるため、ルールだけをいじっても症状が残ることがあります。DNS の仕組み全般は、ドキュメントの Fake-IP／DNS 解説で補完できます。

第三にノードの実体です。データセンター出口はレート制限やボット対策の影響を受けやすく、一般ブラウジングよりも API 呼び出し側だけブロックやタイムアウトが出やすいことがあります。同じ国名表示でもサーバや ASN が違えば挙動が変わるため、「国が合っていれば必ず動く」では済まない場面があります。

AI 専用のプロキシグループを切る

実務では、日常のブラウジング用とは別にAI サイト専用の proxy-groups エントリを用意すると運用が楽です。select 型にしておけば、サービス側の調整やノードの混雑に合わせて、そのグループだけ手早く切り替えられます。url-test で自動選定する場合も、計測 URL と tolerance は「短い会話の体感」とトレードオフになるので、頻繁な切り替えでセッションが切れないよう余裕を見ます。

ルール側では、対象サービスのドメイン・サブドメインを RULE-SET や DOMAIN-SUFFIX でまとめ、広い DIRECT や GEOIP より上に置くのが基本です。利用するルールセットは信頼できるソースを選び、更新頻度と合意してメンテナンスしてください。記法の基礎と優先順位の感覚は、YAML・ルール分流の解説記事とあわせて読むと、どのブロックを触ればよいかが掴みやすくなります。

# Concept only — replace RULE-SET names/URLs with ones you trust and maintain.
proxy-groups:
  - name: AI
    type: select
    proxies:
      - node-us-west
      - node-sg
      - DIRECT

rules:
  - RULE-SET,openai_chat,AI
  - RULE-SET,anthropic_api,AI
  # Place AI rules above broad DIRECT / GEOIP / MATCH ...
  - MATCH,PROXY
ヒント

ブラウザ拡張や別プロファイルで「そのサイトだけシステムプロキシを無視」していると、Clash 側のルールがそもそも効きません。症状がブラウザ限定か、端末全体かを先に切り分けると早いです。

DNS／名前解決：クエリ経路を揃える

分流の相棒が DNS です。nameserver-policy で特定サフィックスのクエリだけ、信頼できるアップストリームへ寄せる構成は、ホストごとの出口ブレを減らすのに効くことがあります。一方で、フォールバックチェーンを重ねすぎると遅延やタイムアウトが増えるので、「本当に必要な名前だけ政策を分ける」ほうが運用は楽です。

Fake-IP を使う場合、fake-ip-filter に載った名前は通常解決に回るため、AI 関連ホストを誤って列挙していないかも確認ポイントです。TUN と併用するときは、OS の DNS がコアに集まっているか（仮想 NIC の状態）を合わせて見ます。プライバシー面を主題にした深掘りは前述のドキュメント該当セクションで体系化されています。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query
  nameserver-policy:
    # example: route AI-related suffixes to a resolver you control
    "+.openai.com": https://dns.example/dns-query
    "+.anthropic.com": https://dns.example/dns-query

ストリーミング分流（Netflix 記事）との違い

当ブログでは、Netflix のカタログ地域とストリーミング分流を扱う記事を別途公開しています。どちらも「特定カテゴリのトラフィックだけ専用グループへ」という骨格は共通ですが、検証の焦点が異なります。動画配信は CDN・DRM・広域のリージョン判定が前面に出る一方、生成 AI の Web は長時間の SSE／WebSocket、ツール呼び出し、サードパーティの計測ホストなど、細かいホスト名の取りこぼしが症状に直結しやすいです。併せて読む場合は、Netflix 分流の記事を参照してください。

モバイル（Android）でアプリ単位に分けたい場合

ブラウザではなく公式アプリだけ別ノードにしたい場合は、OS 側のアプリ単位プロキシやバイパス設定が絡みます。Clash for Android まわりの手順は、アプリ別プロキシの解説記事で整理しています。本稿の「ドメイン単位の分流」と組み合わせるときは、どちらのレイヤでトラフィックを捕まえているかを意識すると迷子になりにくいです。

切り分けチェックリスト（短時間で試せる順）

  1. ルールヒット：ログを一時的に詳細化し、問題のホストが本当に AI（仮）側に落ちているか確認する。
  2. 広い DIRECT の位置：GEOIP や国内向け直結が先に勝っていないか見直す。
  3. DNS の集約：クエリがコアの設定どおりに流れているか、別クライアントが DNS を横取りしていないか。
  4. ノードの入れ替え：同じ地域表示でも別サーバに変えて会話が安定するか試す。
  5. アプリ境界：ブラウザだけ不調なら拡張・プロファイル・別の DNS over HTTPS 設定を疑う。
注意

利用規約・法令・契約は国やサービスごとに異なります。本稿はネットワーク設定の一般的な説明であり、特定サービスの利用を推奨・保証するものではありません。

まとめ

生成 AI の Web は注目度が高い分、トラブル時の検索語も具体的になりやすく、プロキシ利用者にとってはChatGPT プロキシや分流ルールといったキーワードで設定を探す流れと相性がよいテーマです。Clash では、AI 関連のホストを上のルールで捕捉し、AI サイト用プロキシグループに流す設計が効きやすく、その裏側ではDNS の経路と Fake-IP の例外まで含めて一貫させる必要があります。

ストリーミング向けの分流と並べて学ぶと、「垂類（AI と動画）ごとに専用グループを切る」というパターンが手に取りやすくなります。GUI クライアントで試行錯誤する場合も、最終的には YAML のどこを動かしたかが説明できる状態にしておくと、サブスク更新後のトラブルに強くなります。

安定したクライアントからルール検証を始めたい場合は、クライアントのダウンロードページで OS に合ったビルドを選ぶと手順が短くなります。オープンソースのリポジトリは挙動の理解に役立ちますが、実行ファイルの入手は配布ページを主な入口にすると、コアと UI の対応関係が追いやすいです。→ 無料で Clash をダウンロードし、AI 向け分流の検証を始める