まず「ChatGPTだけ使えない」状態を切り分ける
ブラウザーで一般のWebサイトは開けるのに、ChatGPTだけが読み込み中のままになる、ログイン画面で止まる、または「接続がタイムアウトしました」と表示される場合、ノード全体が停止しているとは限りません。ChatGPTでは、Webページ本体だけでなく、認証、API、ストリーミング応答、WebSocketに近い長時間通信など複数の接続が使われます。そのため、単純な遅延測定に成功していても、特定のドメインや通信経路だけが失敗することがあります。
最初に確認するのは、Clashクライアント自体が起動しているか、現在のProfileが有効か、プロキシグループで利用可能なノードが選択されているか、そしてブラウザーの通信が本当にClashを経由しているかです。Clash Verge、Clash Verge Rev、Mihomo対応クライアントでは、画面名が「Profiles」「設定」「プロキシ」など異なる場合がありますが、確認する順番はほぼ同じです。
| 症状 | 可能性の高い原因 | 最初に見る場所 |
|---|---|---|
| すべてのサイトが開かない | システムプロキシ、TUN、ノード、ポートの問題 | Clashのログとプロキシモード |
| ChatGPTだけタイムアウトする | ルール、DNS、特定ノード、ストリーミング通信 | 接続ログとChatGPT関連ドメイン |
| ログインだけ失敗する | 認証ドメインの分岐、Cookie、ブラウザー拡張 | 認証ページのリクエスト先 |
| ページは表示されるが回答が止まる | 長時間接続、経路切断、ノードの混雑 | 別ノードとClashの接続ログ |
| アプリ版だけ失敗する | アプリがシステムプロキシを使わない | TUNモードまたはアプリのプロキシ設定 |
クライアントとProfileの状態を確認する
Clashを起動しただけでは、通信が自動的にプロキシへ切り替わるとは限りません。現在のProfileにノードとプロキシグループが存在することを確認し、「更新」後に設定が読み込まれているかを見ます。購読更新に失敗して古い設定が残っていると、表示上はノードが存在していても、期限切れのサーバーや削除済みのグループを参照していることがあります。
次に「プロキシ」画面でメインのプロキシグループを開き、select型のグループからノードを1つ手動で選択します。url-testやfallbackの自動選択は便利ですが、原因調査中は選択先が変化するため、結果を比較しにくくなります。
プロキシモードとルールでChatGPTの通信先を確認する
ChatGPTだけ接続できないときは、まず一時的にモードを変更して、ルールによる振り分けが原因かどうかを確認します。一般的なClashの動作モードには「ルール」「グローバル」「直接」があります。「ルール」では設定されたドメインやIPルールに従って、通信ごとにプロキシまたは直接接続を選びます。「グローバル」では多くの通信を選択中のプロキシグループへ送ります。「直接」ではノードを使わず、通常のネットワークから接続します。
| モード | ChatGPT確認時の意味 | 注意点 |
|---|---|---|
Rule |
ドメインごとのルール結果を確認できる | 認証やAPIのドメインが別経路になる場合がある |
Global |
選択したプロキシグループへまとめて送る | すべての通信が同じ出口になるとは限らない |
Direct |
Clashを経由しない比較用の状態 | 地域制限や回線側の遮断を受ける可能性がある |
まずモードを「グローバル」にしてChatGPTを再読み込みします。これで接続できるなら、ノードそのものよりもルールの振り分けが疑われます。グローバルでも失敗する場合は、同じノードで一般サイト、証明書を使うHTTPSサイト、別の検索サービスを確認し、ノードの品質や地域制限を切り分けます。
「ルール」モードへ戻した後は、Clashの接続ログを開いた状態でChatGPTを再読み込みしてください。ログには、接続先のホスト名、使用された策略グループ、最終的な出站方式が表示されます。ChatGPTの画面を開いたときに、関連する通信が DIRECT へ流れているなら、該当ドメインが意図せず直結になっています。反対に、広告や分析用のドメインまで同じプロキシグループへ送る必要はありません。
ドメイン単位のルールを確認する
設定内では、ChatGPTのWebページ、認証、API、静的ファイルが複数のホスト名に分かれていることがあります。特定の1つのドメインだけを手作業で追加すれば必ず直るとは限らず、サービス側の変更にも弱くなります。購読設定に既存のAIサービス用ルールがある場合は、そのルールがどのプロキシグループを参照しているかを確認し、グループ名が現在のProfileに存在するかも見てください。
YAMLを直接編集する場合は、インデントとルールの順番に注意します。Clashのルールは上から評価され、最初に一致したルールが使われます。広すぎる DOMAIN-SUFFIX や先に置かれた GEOIP のルールが、後ろに追加した個別ドメインの指定を無効にすることがあります。変更前にProfileを複製するか、元の購読設定を保存しておくと安全です。
mode: rule
rules:
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- MATCH,DIRECT上の例はルールの考え方を示す簡略例です。実際の設定では、利用中のProfileに定義されているプロキシグループ名へ置き換えてください。存在しない PROXY という名前を指定すると、設定検証に失敗したり、期待した分岐にならなかったりします。変更後は設定を再読み込みし、ログに反映されたルールを確認します。
DNSとTUNが原因になるケースを切り分ける
ブラウザーがChatGPTのドメインを正しいIPアドレスへ解決できなければ、ノードが正常でも接続は始まりません。DNSの問題では、ページが完全に開かないだけでなく、ログインボタンが反応しない、静的ファイルだけ読み込めない、応答のストリームが途中で切れるといった症状になることがあります。特に、ローカルDNSが返した結果とプロキシ側で解決した結果が異なる構成では、ルールとDNSの組み合わせを確認する必要があります。
| 確認項目 | 見る内容 | 異常時の対応 |
|---|---|---|
| DNSモード | 通常のDNS、fake-ip、redir-hostのどれか | 現在のクライアントと設定の対応を確認する |
| DNSリクエストログ | 対象ホストが解決されているか | DNSサーバー、ルール、暗号化DNSを確認する |
| TUNモード | アプリ通信が仮想インターフェースへ入っているか | システムプロキシとの二重利用を避ける |
| IPv6 | IPv6経路だけがタイムアウトしていないか | 一時的にIPv6を無効化して比較する |
Clash Verge RevやMihomoクライアントでDNSの「fake-ip」を使っている場合、アプリやブラウザーとの互換性を確認します。fake-ipはドメインを仮想IPへ対応付けてルール処理を行う方式で、通常のドメイン解決とは動作が異なります。特定アプリで不具合が出る場合は、対象ドメインをfake-ip-filterへ無計画に追加するのではなく、DNSログと接続ログを見ながら1項目ずつ比較してください。
TUNを有効にしている場合は、システムプロキシとTUNが同時に同じ通信を取り込んでいないかも確認します。二重経路になると、アプリによっては接続がループしたり、DNSだけ別経路へ流れたりします。切り分けでは、いったんTUNを無効にしてシステムプロキシだけでブラウザーを試し、次にシステムプロキシを無効にしてTUNだけで試すと、問題の層を分離できます。
実際に5分で行う確認手順
ここでは、原因を増やさないために、ノードを固定して順番に確認します。Clash Verge、Clash Verge Rev、Mihomo対応クライアントのいずれでも、項目名を読み替えれば実行できます。テスト中はブラウザーのプライベートウィンドウを使うと、古いCookieや拡張機能の影響を減らせます。
- 現在のProfileを開き、購読更新が直近で成功していることを確認します。更新直後に設定エラーが表示された場合は、まず元の設定へ戻します。
- 「プロキシ」画面で自動選択を一時停止し、遅延テストが成功したノードを1つ手動で選びます。ノード名ではなく、実際の接続ログを基準にします。
- 「設定」または「一般」からシステムプロキシを有効にし、TUNは一度無効にします。ブラウザーで一般のHTTPSサイトを開き、Clashのログにリクエストが表示されるか確認します。
- 動作モードを一時的に「グローバル」へ変更してChatGPTを再読み込みします。ページ、ログイン、メッセージ送信の3段階を別々に確認します。
- グローバルで成功したら「ルール」へ戻し、ChatGPTを再読み込みしながら接続ログを確認します。関連ホストが
DIRECT、失敗状態、または意図しないグループへ送られていないかを見ます。 - DNSログで対象ホストの解決を確認します。解決失敗がある場合だけDNS設定を変更し、変更後にMihomoコアを再起動して同じテストを行います。
- 最後にTUNを有効にして、システムプロキシを使わないアプリでもChatGPTへ接続できるか比較します。TUN使用時だけ失敗するなら、仮想インターフェース、DNSルート、IPv6、ファイアウォールを調査します。
コマンドラインから比較する場合は、プロキシポートを明示してHTTPS接続を試します。混合ポートが 7890 で動作している例では、次のように実行できます。
curl -I -x http://127.0.0.1:7890 --connect-timeout 10 https://chatgpt.com/このコマンドが成功してブラウザーだけ失敗する場合、ノードよりもブラウザーの拡張機能、キャッシュ、ブラウザー独自のDNS、またはブラウザーが別のプロキシ設定を使用している可能性があります。逆にコマンドもタイムアウトする場合は、Clashの接続ログでノードへの接続、TLS接続、リモートサーバーからの応答を順番に確認します。
安定運用のために設定を戻して確認する
原因が分かったら、常時グローバルモードに固定するのではなく、必要な通信だけを適切なプロキシグループへ送る構成へ戻します。グローバルは切り分けには便利ですが、更新、銀行、社内サービス、地域判定が必要なサイトまで同じ出口を使うため、日常運用ではルールモードの方が管理しやすい場合があります。
プロキシグループは、ChatGPTの確認用に固定選択を残し、普段の通信には自動選択を使うと比較しやすくなります。自動グループのテストURL、測定間隔、許容遅延を変更する場合も、ChatGPTの実際の応答時間とは別の指標であることを理解してください。遅延が低くても、混雑、帯域、長時間接続の安定性によって回答生成が止まることがあります。
| 運用方法 | 向いている場面 | 避けたい状態 |
|---|---|---|
| 手動ノード固定 | 原因調査、安定性の比較、出口地域の固定 | 期限切れノードを長期間使い続ける |
| 自動速度測定 | 多数のノードを日常的に切り替える | ChatGPTの接続中に頻繁に出口が変わる |
| フォールバック | 主ノード停止時に予備へ切り替える | 利用可能でも応答品質が低いノードを選ぶ |
| TUN運用 | システムプロキシを使わないアプリを取り込む | システムプロキシとの二重経路やDNS漏れ |
最終確認では、Clashの接続ログを閉じずに、ページ表示、ログイン、短いメッセージ送信、長めの回答受信を順番に試します。ブラウザーだけでなくアプリ版を使う場合は、アプリがシステムプロキシに対応しているかを確認し、対応していなければTUNが必要です。どのモードでも失敗し、複数のノードで同じタイムアウトが発生するなら、サブスクリプション側の障害、アカウント側の制限、サービス側の一時障害も候補になります。
ChatGPTの接続障害は、ノードを何度も切り替えるだけでは解決しないことがあります。Profile、プロキシモード、ルール、DNS、TUN、アプリの通信方式を一つずつ固定して確認すれば、どの段階でタイムアウトしているかを特定できます。最後に変更した設定を記録し、正常に動作したノードとモードを控えておくと、次回の障害でも短時間で復旧できます。