目次
複数の AI サービスを別々に管理するには、長いドメイン一覧を集めるよりも、アカウント認証、モデルへのリクエスト、アップロードがそれぞれどこへ送られるかを把握することが大切です。共通のログイン用ドメインは、ほかの製品でも使われる場合があります。実際のセッションに合わせてルールを補い、サービスごとに安定した接続経路を保つことで、ほかのアクセスまで変えてしまうことを避けましょう。
ページ、ログイン、モデル応答、アップロードにはどのリクエストがある？
ChatGPT、Gemini、Claude のルールを設定するときは、ログイン、メッセージ送信、ファイルアップロードを個別に行い、対応するドメインと接続経路を記録します。ホームページが開いても、一部のリクエストの成功しか確認できません。同じサービスの別のリクエストが異なるポリシーを使う場合があります。すでに失敗している操作は下の表で調べてください。
失敗した操作に対応するリクエスト
| 確認された現象 | 確認する点 | 避けたい見当違いの対処 |
|---|---|---|
| 画面が真っ白になる、またはスタイルが欠ける | スクリプト、静的リソース、DNS | アカウントを何度も切り替える |
| ログイン後に再びログインページへ戻る | 認証リダイレクト、Cookie、出口の地域 | モデル API のルールだけを追加する |
| メッセージが読み込み中のまま、または途中で切断される | モデルのエンドポイント、ストリーミング接続、ノードの切り替え | トップページだけをテストする |
| ファイルのアップロードが止まる | アップロード用ドメイン、オブジェクトストレージ、リクエスト本文のサイズ | すべての CDN をプロキシ対象へ追加する |
ログインと API リクエストの出口をそろえる
認証リクエストとログイン直後の最初のインターフェースリクエストが異なる出口を使うと、再認証を求められたり、セッションが無効になったりする可能性があります。トラブルシューティング時は手動ポリシーグループを作り、利用可能なノードを一つ固定して、アカウントページ、メインサイト、インターフェースが一回のログイン中に同じ出口を使うようにします。
これは三つのサービスで一つのノードを永続的に共有するという意味ではありません。問題を確認した後は ChatGPT、Gemini、Claude ごとにグループを分けられますが、各サービス内の認証リクエストとデータリクエストは同じ地域を維持する必要があります。アカウントが利用できない、現在地でサービスが提供されていない、製品側でレート制限されているといった問題は、Clash のルールを数件増やしても解消しません。
ドメインは実際のセッションから特定し、古いリストを丸ごとコピーしない
接続履歴を消してから、Claude にログインする、Gemini で短いメッセージを送る、ChatGPT で小さなファイルをアップロードするなど、一つの操作だけを行います。失敗の前後に出たホスト名、一致したルール、アウトバウンドを記録し、想定どおり転送されていないリクエストを探します。
明確な製品入口から記録を始めます。ChatGPT は chatgpt.com、OpenAI API は api.openai.com を使用します。Gemini のウェブ版は gemini.google.com、Gemini API の一般的な入口は generativelanguage.googleapis.com です。
Claude のウェブ版は claude.ai、Anthropic API は api.anthropic.com を使用します。ログインのリダイレクト先、静的リソース、アップロード先は、自分の接続記録から追加してください。
新しいルールは、広範な GEOIP、ルールセット、MATCH より前に置きます。Google のログイン用ドメインは Gmail や YouTube などのサービスでも共用されるため、Gemini のためだけに accounts.google.com のような広いドメインを AI グループへ永続的に割り当てないでください。
接続記録で認証リクエストが誤った出口を使ったことを確認してから、そのセッションで現れたホストを AI グループへ追加し、再検証します。
以下は、そのまま貼り付けて使う完全な設定ではありません。現在のサブスクリプションに実在するグループ名で、すべての YOUR_EXISTING_GROUP を置き換えます。未置換なら group not found になります。三つの AI グループを作ったら、参照先の既存グループを開いて使えるノードを固定し、その後にルールを追加してください。
# 必须先把 YOUR_EXISTING_GROUP 替换成当前配置里真实存在的组名
proxy-groups:
- name: AI-OPENAI
type: select
proxies:
- YOUR_EXISTING_GROUP
- DIRECT
- name: AI-GOOGLE
type: select
proxies:
- YOUR_EXISTING_GROUP
- DIRECT
- name: AI-CLAUDE
type: select
proxies:
- YOUR_EXISTING_GROUP
- DIRECT
rules:
- DOMAIN-SUFFIX,chatgpt.com,AI-OPENAI
- DOMAIN,api.openai.com,AI-OPENAI
- DOMAIN,gemini.google.com,AI-GOOGLE
- DOMAIN,generativelanguage.googleapis.com,AI-GOOGLE
- DOMAIN,api.anthropic.com,AI-CLAUDE
- DOMAIN-SUFFIX,anthropic.com,AI-CLAUDE
- DOMAIN-SUFFIX,claude.ai,AI-CLAUDE
- GEOIP,CN,DIRECT
- MATCH,YOUR_EXISTING_GROUPこのルールセットが実際に機能している証拠
- 設定チェックに合格し、group not found がない
- ChatGPT、Gemini、Claude のテストリクエストが、それぞれ対応するポリシーグループに一致する
- ログインのリダイレクト中とメッセージ送信中に出口が変わらない
- ルールへ追加していない Google サービスが誤って AI-GOOGLE に入らない
ウェブ版は正常なのに CLI がタイムアウトする場合、同じプロキシ入口を使っていない可能性が高い
ブラウザーは通常 Windows や macOS のシステムプロキシを使いますが、Python SDK、コマンドラインツール、IDE の拡張機能、コンテナはそうとは限りません。失敗したリクエストが Clash の接続ページに表示されるか確認します。記録がない場合は、そのプロセスのプロキシ設定と、リクエストが実際に送信されたかを調べてください。空の一覧だけでプロキシを通っていないとは断定できません。
コマンドラインツールでは HTTP_PROXY、HTTPS_PROXY、NO_PROXY を一時的に設定でき、デスクトップの開発環境でもアプリの説明に従ってプロキシを指定できます。システムプロキシを使わないプロセスが実際に複数ある場合に限り、TUN を検討してください。接続がすでに記録へ表示されているなら、環境変数を変更し続けず、一致したルール、ポリシーグループ、ノードを確認します。
異なる DNS 経路が白い画面の原因か確認する
ブラウザのセキュア DNS、システム DNS、Clash DNS が同時に動作すると、同じサービスでもプログラムごとに異なるアドレスが返る場合があります。トラブルシューティング中はブラウザ独自の DoH を一時的に無効にし、ドメイン問い合わせと接続の両方を Clash に通してから、画面の白抜けやリソース読み込み失敗が続くか確認します。
名前解決に成功しても TLS ハンドシェイクや接続が引き続きタイムアウトする場合に限り、ノード品質とルールを見直します。一度の DNS 失敗だけで十の都市を切り替えたり、結果を観察せずに Fake-IP、スニッフィング、上流 DNS を同時に変更したりしないでください。
長い応答やアップロードは、速度テストの数ミリ秒の差よりも出口の変化に影響されやすい
AI の対話では、長時間のストリーミング接続が維持されます。自動グループがノードを頻繁に選び直すと、トップページは常に速くても、回答が途中で切れる可能性があります。テストでは一つの固定ノードを使い、長い応答、再生成、ファイルアップロードを完了してから、自動グループで実際に改善するか比較します。
アップロードに失敗した場合は、リクエストが送信済みかどうかも切り分けます。進捗が 0% から動かないなら、まずアップロード先がルールに一致しているか確認します。途中まで進んで明確な HTTP ステータスが返る場合は、サイズ制限、ファイル形式、サービスの応答を確認してください。Clash が変更できるのはネットワーク経路だけで、製品自体の制限を回避することはできません。
ログイン、長い回答、アップロード、API の実動作テスト
トップページを開くだけより有意義なテスト
もう一度ログインする
認証リダイレクトの完了後にログインページへ戻らず、出口の地域も変わらないことを確認します。
長い会話を送信する
最初の文字が表示されるまでの時間、ストリーミング出力、完了時の状態を観察します。最初の一文が表示されるかだけで判断しないでください。
小さなファイルを一つアップロードする
アップロード用ドメイン、進捗、最終的な処理結果を確認します。
API を一度呼び出す
ホスト、HTTP ステータスコード、クライアントが正しいプロキシ入口を使用したかを記録します。
ログインは安定しているのに会話が途切れる場合は、認証ルールを維持してモデルへのリクエストを確認します。ブラウザーは正常でも API クライアントの接続記録がない場合は、そのプロセスのプロキシ設定を調べます。変更するのは失敗した操作に関係する設定だけにします。