なぜ「Web は動くのに API やアプリだけおかしい」のか
生成 AI の利用が一般化した 2026 年現在、ChatGPT や Claude（Anthropic）などは、ブラウザからの利用に加え、デスクトップ／モバイル公式アプリや、各種エディタ・IDE からの API 呼び出しが日常的になっています。ここで Clash 利用者がつまずきやすいのが、ブラウザでは問題なく表示できるのに、同じサービスの API やネイティブアプリだけがタイムアウト・認証エラー・断続的な切断を繰り返すというパターンです。
原因は一つではありませんが、Clash の文脈では次のような組み合わせが典型です。ブラウザは OS のシステムプロキシ設定に従う一方で、一部のアプリはプロキシを無視して直接接続しようとする、あるいは名前解決だけがコアの外側で済んでしまい、ルールマッチ前に意図しない経路に乗る、といったケースです。後半で述べるように、TUN で全トラフィックを握る方法もありますが、本稿ではまずルール分流とDNSの設計で大半をカバーする前提で整理します。TUN の仕組み自体は TUN モードの解説記事 に譲ります。
AI サービス向けドメインルールの置き方
まず押さえたいのは、利用するサービスが実際にどのホスト名に接続しているかです。Web のチャット画面だけでなく、API クライアントやデスクトップアプリは、api.openai.com や *.anthropic.com、CDN・認証・リアルタイム通信用の別サブドメインなど、複数のドメインにまたがることがほとんどです。サブスクリプションに同梱されているルールセットに「AI 向け」の項目があればそれを活かしつつ、不足している場合は DOMAIN-SUFFIX や DOMAIN-KEYWORD を補います。
運用上のコツは、ルールの評価順序の前半に AI 関連を置くことです。後ろの広い GEOIP や「最終 MATCH」で意図せず DIRECT に落ちると、いわゆる漏れ代理として挙動が不安定になります。逆に、国内向け CDN まですべて海外ノードに流してしまうと遅延が増えるため、必要なサフィックスだけをピンポイントで列挙するバランスが重要です。ルールタイプの詳細な書き方は ルール分流の詳解記事 とあわせて参照すると、自分の構成に足りない行が特定しやすくなります。
ポリシーグループの選び方（select / url-test / fallback）
ドメインがどのプロキシに流れるかはルールで決まりますが、実際に選ばれるノードの集合と切り替えロジックはポリシーグループ側で定義されます。ChatGPT や Claude のように長めのセッションやストリーミング応答が多い用途では、手動の select で安定しているノードを固定するのが分かりやすいです。複数ノードを自動で試したい場合は url-test や fallback を使いますが、テスト間隔が短すぎると切り替わりが多く、かえって切断感が強まることがあります。
また、ブラウザ用と API 用で別のポリシーグループ名をルールに割り当てる構成も有効です。見た目は冗長に見えても、切り分け時に「ブラウザだけ別ノード」といった状態を明示的に避けられます。いずれにせよ、ルールが参照するグループ名と、プロキシ一覧の実在する名前が一致しているかは、設定変更のたびに確認してください。
DNS・fake-ip と「名前解決の取りこぼし」
多くの Clash（mihomo 系を含む）構成では、DNS モードがルールマッチの前提になります。fake-ip を使う場合、コアが名前解決と接続の対応付けを行いやすくなりますが、コアの外で先に解決してしまうと、意図したドメインルールに届かずに実 IP へ直行する、という現象が起き得ます。AI クライアントが OS の解決キャッシュや独自リゾルバに依存しているとき、まさにこのパターンが表面化しやすいです。
対策の方向性は、システム／アプリの DNS 設定と Clash の DNS 設定の役割分担をはっきりさせることです。TUN と併用する場合は、名前解決の経路もコア側に寄せる設計が採られがちですが、本稿の範囲では「ブラウザと API で挙動が違うときは、まず DNS の経路を疑う」というチェック項目だけ覚えておけば十分です。fake-ip-filter に特定ドメインを入れる・入れないの調整は、国内サービスと海外 AI を混在させるときのトレードオフが出やすいので、症状に応じて少しずつ試すのが安全です。
スプリットトンネリングの考え方（国内直結と海外プロキシ）
すべてのトラフィックを同一ノードに流すと単純ですが、国内の動画や金融系まで遅延するなど副作用が出ます。国内向けは DIRECT、海外の AI 関連ドメインだけをプロキシに送るいわゆるスプリットトンネリングは、体感速度と安定性のバランスが取りやすいです。ここで重要なのは、「AI 用のドメイン集合」をルール上で明示することと、最終ルールが意図せず全体を DIRECT または PROXY に振っていないかを確認することです。
サブスクリプションが提供するデフォルトルールをそのまま使う場合でも、利用サービスに合わせて追記ルールファイルやローカル優先のルールを足す運用が現実的です。サブスク URL の管理そのものは サブスクリプション管理の記事 で扱っているため、本稿では重複を避け、ルールの中身と DNS の観点に集中します。
切り分けチェックリスト（2026 年版のよくある論点）
まずブラウザと API／アプリで同じノード・同じルールに乗っているかを確認します。次に、アプリがシステムプロキシを参照しているか、独自の接続設定があるかを製品のヘルプで確認します。三つ目に、DNS がどこで解決されているか（OS、ルータ、Clash コア）を整理します。四つ目に、セキュリティソフトや別 VPN がトラフィックを横取りしていないかです。これらはいずれも、ログや接続テストツールで段階的に絞り込めます。
「Web は開くが API だけ失敗する」場合、証明書ピン留めやホストの不一致などプロキシ以前の要因もゼロではありません。しかし Clash 利用者としては、ドメインルールの抜け・DNS の取りこぼし・ポリシーグループの選択ミスを先に潰すと、対応の優先順位が明確になります。設定用語や画面の対応関係を俯瞰したい場合は、ドキュメントページ も併せて参照してください。
まとめ
ChatGPT・Claude を含む生成 AI 利用では、見えている画面と同じサービスでも、接続経路が Web と API で分かれることがあります。Clash ではそのギャップを埋める鍵が、ドメイン単位のルール分流、用途に合ったポリシーグループ、そしてDNS と fake-ip の設計の三つに集約されます。サブスク更新の手順や TUN の全容とは切り口を分け、日常の「途切れにくさ」を優先して調整すると、運用が楽になります。
同種のツールをいくつか試したことがある方なら、ルール表現の柔らかさとコミュニティの知見の豊富さから、Clash エコシステムの扱いやすさを実感しやすいはずです。クライアントの入手と各 OS 向けパッケージは、本サイトの ダウンロードページ から確認できます。ソースコードやライセンスを知りたい場合は公式リポジトリも参照してくださいが、実行ファイルの入手はサイトの導線を優先すると、説明とバージョンの対応が取りやすくなります。
Clash を無料ダウンロードして、設定を試す → 各プラットフォーム向けのビルドが揃っており、画面の案内に沿えば短時間で初期設定まで進められます。