まず症状を分け、Clashが通信を処理しているか確認する

Clash経由でChatGPTを開いたとき、画面が白いまま、読み込み表示が続く、ログイン後に戻される、会話の送信だけ失敗する、といった症状が起こることがあります。これらは同じ原因とは限りません。トップページが開かない場合はDNS、ルール、ノードへの接続を優先して確認し、ログイン画面だけ失敗する場合は認証用ドメインの経路やブラウザーのCookie設定も確認します。画面は表示されるのに応答が止まる場合は、接続一覧にWebSocketなどの長時間通信が残っていないかも見てください。

最初に、同じ端末の別のサイトがプロキシ経由で開くか確認します。どのサイトも開かないなら、ChatGPT固有のルールを追加する前に、Clashコア、ローカル待ち受けポート、選択中のノードを調べます。ChatGPTだけ失敗するなら、ルールの適用先やOpenAI関連ドメインの名前解決を切り分けます。可能であれば、同じノードを別のブラウザーでも試し、ブラウザー拡張機能や保存済みセッションによる影響を分けてください。

症状から確認する箇所
症状 最初に確認する項目 見分け方
すべてのサイトが開かない コアの起動、プロキシポート、ノード ローカルポートに接続できるか、別のHTTPSサイトも失敗するかを確認
ChatGPTのトップページだけ失敗 ルール、DNS、接続先ノード 接続一覧で該当ドメインに適用されたルールとポリシーを確認
ログインや画面表示の途中で止まる 認証関連ドメイン、ブラウザー、時刻 失敗したリクエストのドメインとログのエラーを照合
画面は開くが送信や応答が失敗 長時間接続、ノードの安定性、TUN経路 接続一覧で再接続やタイムアウトが繰り返されていないか確認

サービス側のドメインや配信経路は変更されることがあるため、特定のドメイン一覧を永久に完全なものとして扱わないでください。接続一覧に表示される実際の宛先、クライアントのログ、現在のルール設定をもとに、必要な範囲だけ調整します。

システムプロキシとノードを個別に確認する

Clashクライアントが起動していても、ブラウザーの通信が自動的にプロキシへ入るとは限りません。通常のシステムプロキシは、OSのプロキシ設定に従うアプリの通信をローカルのHTTPプロキシへ送ります。一方、独自のプロキシ設定を持つアプリやシステム設定を参照しないアプリは、その経路を使わない場合があります。まずクライアント画面でシステムプロキシが有効か確認し、OSのプロキシ設定にローカルアドレスと実際のポートが表示されているかを見ます。

よく例に使われるポートは127.0.0.1:7890ですが、これは全クライアント共通の固定値ではありません。設定でmixed-port、port、またはHTTPプロキシの待ち受け先を変更している場合は、その実際の値を使ってください。クライアントの接続一覧に通信が一件も現れないなら、リモートノードを入れ替えるより先に、システムプロキシ、ブラウザーのプロキシ設定、ローカルポートを調べる方が効率的です。

ローカルポートとノードを別々にテストする

WindowsではPowerShell、macOSやLinuxではターミナルから、実際のポートを指定して確認できます。次の例はポート7890をHTTPプロキシとして使う例です。利用中のクライアントが別のポートを設定している場合は、両方のコマンドのポート番号を置き換えてください。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://chatgpt.com/
  • 「プロキシに接続できない」場合は、コアが停止している、ポート番号が違う、またはHTTPプロキシではないポートを指定している可能性があります。
  • ローカル接続後にタイムアウトする場合は、Clashの接続一覧とログを開き、実際に選ばれたルール、プロキシグループ、ノードを確認します。
  • 明示的なプロキシでは開くのに通常のブラウザー操作で失敗する場合は、システムプロキシが無効、ブラウザー独自のプロキシ設定が優先、または拡張機能が介在している可能性があります。

ノードを変更して比較するときは、同じブラウザー、同じURL、同じルールモードで一つずつ試します。ノード一覧の遅延が低くても、ChatGPTへの接続や長時間の応答が安定するとは限りません。複数ノードで同じ症状が続く場合は、ノードだけに原因を決めつけず、ルールとDNSも確認してください。

ルールとDNSを確認し、関連ドメインを意図した経路へ送る

ルールモードでは、設定内のrulesが上から順に評価され、最初に一致したルールのポリシーが使われます。OpenAI関連ドメインをプロキシへ送りたいのに、それより前に広い範囲を対象とするDIRECTルールが一致していれば、後ろに追加したルールは適用されません。反対に、広いキーワードルールを安易に追加すると、無関係なドメインまで同じグループへ送ることがあります。

次の例は、設定にプロキシという名前のプロキシグループが存在する場合の記述例です。実際には、自分の設定にあるグループ名と完全に一致させてください。ChatGPTの画面、認証、API、静的コンテンツが同じドメインだけを使うとは限らないため、接続一覧で失敗した宛先を特定し、必要なドメインを個別に追加します。

rules:
  - DOMAIN-SUFFIX,chatgpt.com,プロキシ
  - DOMAIN-SUFFIX,openai.com,プロキシ
  - MATCH,プロキシ

この例では、該当するサフィックスルールが既存の広いルールより前にある必要があります。すでに同じドメイン向けのルールがある場合は、重複行を増やすのではなく、現在のポリシーと並び順を確認してください。サブスクリプション由来の設定を直接編集すると更新時に上書きされることがあるため、クライアントのルール上書き機能や、設定生成側のルール管理方法に従います。

DNSの失敗とルールの失敗を区別する

DNSの名前解決が失敗すると、接続先のIPアドレスを取得できず、ブラウザーではサイトがタイムアウトしたように見えることがあります。クライアントのログに名前解決エラーがあるか、接続一覧に接続先が作成されているかを確認します。端末側のDNSキャッシュを消すことは一つの確認手段ですが、それだけでClash側のDNS設定や上流DNSの問題が解消するとは限りません。

mihomoでは、DNSの動作はdns設定、上流サーバー、fake-IPまたはredir-host方式、ルールとの組み合わせに左右されます。トラブル対応としてDNS設定全体を別の例へ置き換えると、LAN内ドメインや既存ルールに影響する可能性があります。まずログで名前解決エラーを確認し、端末が使うDNSとClashのDNS処理のどちらで問題が起きているかを分けてください。

実作業：変更を一つずつ行って原因を絞り込む

原因を短時間で切り分けるには、症状、設定変更、結果を同じ条件で記録します。以下はWindows、macOS、Linuxのデスクトップクライアントで共通して使える考え方です。画面の名称やボタンの配置はClash Verge、Clash Verge Revなどで異なるため、該当する機能名を読み替えてください。

  1. 状態を記録する。クライアント名、バージョン、利用中のコア、選択中のノード、ルールモードかどうか、実際のプロキシポートを控えます。設定を変更する前に、現在のプロファイルやルールをバックアップしてください。
  2. 通常のブラウザーで再現する。ChatGPTを開き、失敗する操作と時刻を記録します。別の一般的なHTTPSサイトも同じブラウザーで開き、問題がChatGPTだけかどうかを確かめます。
  3. 明示的なプロキシで比較する。前述のcurlコマンドを実行します。ここで成功しブラウザーだけ失敗するなら、まずシステムプロキシまたはブラウザー側を調べます。両方失敗する場合は、Clashの接続一覧とログを確認します。
  4. 接続一覧で失敗した宛先を探す。クライアントの接続画面を開き、該当するドメイン、適用ルール、使用されたポリシー、接続状態を確認します。ログの時刻と照合し、ページを一度読み直したときに同じ接続が失敗するかも見ます。
  5. 一つだけ変更して再テストする。まずノード、次に必要なルール、続いてDNS設定のように、変更を分けます。変更後は同じURLと同じ手順で再テストし、改善がなければ直前の変更を戻してから次へ進みます。
  6. 変更結果を保存する。改善した場合も、設定がサブスクリプション更新で消えない場所に反映されたか確認します。うまくいかなかった場合は、元に戻してログと接続情報を残し、複数の設定を同時に変えた状態で放置しないでください。

ブラウザーのプライベートウィンドウで試すと、拡張機能や保存済みセッションの影響を一部切り分けられます。ただし、すべての拡張機能が無効になるとは限らず、ログイン情報やCookieの状態も通常のウィンドウと異なります。プライベートウィンドウで成功した場合は、拡張機能を一つずつ無効にするか、対象サイトの保存データを確認します。アカウント情報や認証コードをログ共有に含めないでください。

システムプロキシで届かない場合はTUNを検討する

システムプロキシを有効にしても、すべてのアプリや通信がプロキシへ送られるわけではありません。アプリがOSのプロキシ設定を無視する場合や、ブラウザー以外のプロセスが独自の通信方式を使う場合は、TUNモードが候補になります。TUNは仮想ネットワークインターフェースを介して、ルーティング対象となるIP通信を取り込む方式です。機能を有効にしただけで、すべての通信が必ず正しくプロキシされるわけではありません。

TUNを試す前に、クライアントとコアがTUNをサポートしているか、OS側で必要な権限が許可されているか、仮想アダプターが作成されているかを確認します。WindowsではUACによる権限確認、macOSではネットワーク拡張の許可が必要な場合があります。TUNの有効化で接続が変わらないときは、同時にシステムプロキシやDNSを変更せず、まずクライアントログにTUNの初期化エラーがないかを確認してください。

システムプロキシとTUNの使い分け
方式 主な対象 確認する点
システムプロキシ OSのプロキシ設定に従うアプリ 有効状態、ローカルポート、アプリ独自設定との競合
TUN 仮想インターフェースとルーティングで取り込まれる通信 権限、アダプター、ルート、DNS、除外設定

不明なプロファイル設定をまとめて置き換えたり、証明書検証を無効にしたりする方法は、通常の接続対処として使わないでください。まずコアのバージョンとログ、接続一覧、適用ルールを確認し、最小限の変更で同じ症状が解消するかを検証します。クライアントの導入や設定を見直す場合は、OSに合った配布物と手順を選んでください。