最初に「接続済み」の意味を切り分ける

Clashの画面で「接続済み」と表示されても、ChatGPTのページが開くことや、ログイン・会話の送信が成功することまで保証されるわけではありません。サブスクリプションを読み込めたか、mihomoコアが起動しているか、ブラウザーの通信がローカルプロキシへ届いているか、ルールが適切な出口を選んだかは、それぞれ別の確認項目です。まず、症状が「ページを開けない」「ログイン画面で止まる」「会話の送信後にタイムアウトする」のどれに当たるか記録してください。

最初の切り分けでは、ノード、ルール、DNS、TUNを同時に変更しないことが重要です。対象サイトへの通信が直接接続になっているのか、プロキシ経由でノードに到達しているのかを、mihomoの接続履歴やログで確認します。ChatGPTの画面だけでなく、接続履歴に表示されるホスト名、適用ルール、最終的なアウトバウンドも手掛かりになります。

  • ページがまったく読み込まれない：システムプロキシまたはTUNでブラウザーの通信を取り込めているか、コアのログに対象リクエストがあるかを確認します。
  • ページは開くがログインや認証で止まる：ログイン関連の通信が別のルールや別の出口になっていないか、ブラウザーのCookieや拡張機能が影響していないかを調べます。
  • 会話の送信後にタイムアウトする：ノードの安定性、名前解決、TLS接続、長時間の通信が途中で切れていないかを確認します。

モード、ノード、ルールを順に確認する

まずClashを一時的にルールモードにし、ChatGPTのタブを再読み込みして新しい接続を発生させます。接続履歴に chatgpt.com などのリクエストが現れない場合、ブラウザーがClashを経由していない可能性があります。履歴に表示されても、ルールの結果が DIRECT なら、選択中のプロキシノードはその通信に使われていません。

ルールモードで通信を確認する際は、プロキシグループを開き、利用可能なノードを一つ手動で選択します。グループ名が「Proxy」「AI」「海外」などであっても、名前だけで実際の動作は判断できません。グループがさらに別のグループを参照している場合は、最終的に選択されているアウトバウンドまでたどってください。DIRECT は直接接続、REJECT は拒否であり、どちらもプロキシノードではありません。

接続履歴の状態 確認する項目 次の操作
対象のリクエストがない ブラウザーのプロキシ設定、TUNの動作、ほかのVPNや拡張機能 システムプロキシまたはTUNのどちらで取り込むかを一つに絞ってテスト
ルールがDIRECT ルール順序、ドメイン分類、ルールセットの読み込み 適用ルールを確認し、設定の管理方法に沿って例外を調整
プロキシ経由だがタイムアウト 選択ノード、接続ログ、DNSエラー、TLSエラー 同じ条件のまま別ノードを一つ試し、結果を比較
画面の一部だけ読み込まれない 関連するホストへのルールと出口の一貫性 失敗時刻の接続履歴を見て、該当通信を特定

ChatGPTのWeb画面は、メインページだけでなくログイン、静的リソース、APIなど複数のホストへ接続します。接続履歴に chatgpt.com が見えても、関連通信すべてが同じルールで処理されているとは限りません。特定のドメインをルールに追加する場合は、現在有効な設定に対して行い、ルールの上から順に評価されることを踏まえて配置します。サブスクリプション本体を直接編集すると更新時に変更が失われる場合があるため、クライアントのオーバーライドやマージ機能が使えるか確認してください。

操作手順：システムプロキシで一つずつテスト

ここでは原因を絞るため、TUNや他のVPNをいったん停止し、システムプロキシだけでブラウザーを試します。以下の 7890 はポート番号の例です。実際にはClashクライアントの現在の設定にあるHTTPまたはmixed-portの値を使ってください。テスト中はノードを固定し、同時にDNSやルールを編集しないでください。

  1. コアと設定を確認：選択中の設定が有効で、mihomoのログにYAML解析エラーやポートの待ち受け失敗がないことを確認します。
  2. システムプロキシを有効化：Clashのシステムプロキシをオンにし、OSやブラウザー側のプロキシ設定が別のアドレスを指定していないか確認します。
  3. ノードを固定：利用可能なノードを一つ選択します。自動選択グループのままだと、テスト中に出口が変わって比較しにくくなることがあります。
  4. 明示的なプロキシ接続を試す：ターミナルから次のコマンドを実行し、ローカルポートへの接続とHTTPS応答を確認します。
curl --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://chatgpt.com

# Windows PowerShellでは curl.exe を使用
curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://chatgpt.com

このテストはブラウザーのプロキシ設定を使わず、指定したローカルポートへ明示的に接続します。接続拒否なら、コアの起動状態、ポート番号、待ち受けアドレスを先に調べます。ローカル接続後にタイムアウトするなら、mihomoの接続履歴でルールとアウトバウンドを確認してください。HTTPのステータスコードが返った場合は、少なくともこのリクエストに対するHTTPS通信が応答したことを示しますが、ログインや会話機能まで正常である証明ではありません。環境によってはHEADリクエストへの応答が異なることもあります。

システムプロキシとTUNを別々に切り分ける

システムプロキシは、OSのプロキシ設定を参照するアプリがClashのローカルポートへ接続する方式です。ChromeやEdgeなどで利用できる場合が多い一方、ブラウザー独自のプロキシ設定、拡張機能、組織のポリシーが優先されることがあります。Firefoxでは「設定」→「一般」→「ネットワーク設定」を開き、システムのプロキシ設定を使うか、Clashのアドレスとポートを指定しているか確認してください。

TUNは仮想ネットワークインターフェースを使い、システムプロキシを参照しないアプリのIP通信も取り込める方式です。ただし、TUNをオンにしただけでChatGPTの通信が必ずプロキシへ送られるわけではありません。取り込まれた後もルールが適用され、DIRECT に一致すれば直接接続します。また、OSの権限、他のVPN、ルート設定、DNSの構成によって結果が変わります。

  • システムプロキシでは開かず、TUNで開く場合は、ブラウザーまたはOSがシステムプロキシを参照していない可能性があります。
  • システムプロキシでは開くのにTUNで失敗する場合は、TUNの権限、ルート、DNS、他のVPNとの競合を確認します。
  • 両方で同じタイムアウトが起き、接続履歴が同じノードを示す場合は、ノード側や宛先までの経路を優先して調べます。
  • 履歴に対象通信がなく、ブラウザーだけ失敗する場合は、別プロファイルや拡張機能を使った最小構成でも比較します。

方式を比較するときは、最初にシステムプロキシだけを有効にしてテストし、記録後にそれを停止してからTUNを有効にします。両方を同時に動かすと、通信の取り込み元やDNS経路が分かりにくくなり、原因を誤認しやすくなります。ほかのVPNやプロキシアプリも、切り分け中は停止しておくのが安全です。

DNS、ブラウザー、サービス側の状態を確認する

接続ログでルールとノードが正しく見えるのに読み込みが止まる場合は、エラー内容を確認します。名前解決の失敗、TLSハンドシェイクの失敗、接続確立後のタイムアウトは原因が異なります。DNS設定を変更する前に、ログにDNS関連のエラーがあるか、ほかのHTTPSサイトは同じノードで開くかを比較してください。DNSを変更するとルール判定やキャッシュにも影響するため、変更前の値を記録します。

ページの一部だけが表示されない場合は、接続履歴で失敗時刻を絞り込み、対象ホストごとのルールとアウトバウンドを見ます。利用する設定やルールセットの更新状況によって、ホストの分類は変わることがあります。ChatGPT関連の通信をすべて一律に書き換えるのではなく、実際に失敗したリクエストを確認してから、必要な範囲だけ調整してください。

ブラウザー側の状態も切り分けます。プロキシ拡張機能を一時停止し、新しいプライベートウィンドウで再試行します。ただし、プライベートウィンドウでも拡張機能が許可されていれば影響は残ります。Cookieやサイトデータを削除する場合は、保存されたログイン状態が失われる可能性があるため、まず別のブラウザープロファイルで試す方法が安全です。

複数のノードで同じ症状が続くときは、クライアントのログ、発生時刻、使用したモード、テスト結果を整理し、プロキシサービスの提供元やサービス側の状態も確認します。ChatGPTの利用可否は、ネットワーク以外にアカウント状態、サービス側の障害、地域ごとの提供条件にも左右されます。ネットワーク設定だけで解決できるとは限らず、利用地域やサービスの規約・案内に従ってください。

原因を絞る基本順序は、コアとポート、通信の取り込み、適用ルール、プロキシグループとノード、DNSとブラウザー、サービス側の状態です。調査中に変更した設定は一つずつ戻せるよう記録し、最後に動作した組み合わせを基準として、次の変更を試してください。