この記事で分かること
ChatGPT が Clash 経由でタイムアウトする、ログイン画面が開かない、回答の生成中に接続が切れるといった症状は、ノードの品質だけでなく、プロキシモード、ルール分流、DNS、TUN の組み合わせによって起きることがあります。ブラウザでは一時的に動いているのにデスクトップアプリや API クライアントだけ失敗する場合は、通信が同じ経路を通っていない可能性があります。
本稿では、Clash Verge Rev や Mihomo 系クライアントを前提に、ChatGPT のタイムアウトを症状別に切り分けます。単純にノードを何度も入れ替えるのではなく、まずClash が起動しているか、対象ドメインが正しいポリシーへ送られているか、DNS 解決が安定しているか、アプリがプロキシを認識しているかを順番に確認します。設定を一度に変更しないことが、原因を見失わないための重要なポイントです。
最初に確認する症状と原因の候補
「ChatGPT が使えない」という表示だけでは、通信障害、認証エラー、ノードの混雑、ブラウザの保存データなどを区別できません。画面に出るメッセージと、失敗するタイミングを記録すると調査が速くなります。ページ自体が開かないのか、ログイン後に止まるのか、入力した質問を送信した後に止まるのかで、疑うべき層が変わります。
- ページが開かない、接続がリセットされる：選択中のノード、ルール、DNS、または現在のネットワークによる制限を確認します。
- ログイン画面だけがループする：認証関連のドメインが別のルールへ送られている、Cookie が壊れている、システム時刻がずれている可能性があります。
- 回答の生成中にタイムアウトする：長時間接続、ストリーミング通信、ノードの混雑、接続維持時間の短さが関係することがあります。
- ブラウザは動くがアプリや CLI は失敗する：ブラウザだけがシステムプロキシを使い、対象アプリは直接接続している構成が考えられます。
- 成功と失敗が交互に起きる：自動選択されたノードの品質差、複数の Clash クライアントの同時起動、DNS キャッシュの不整合を確認します。
まず同じブラウザで通常のウェブサイトを開き、次に ChatGPT のログインページ、最後に短いメッセージの送信を試します。すべてが失敗するなら経路全体、ChatGPT だけが失敗するならルールや接続先、送信後だけ失敗するなら長時間通信やノードの安定性を中心に見ます。
プロキシモードとシステムプロキシを確認する
Clash の画面でノードを選択していても、通信が自動的にそのノードを通るとは限りません。多くのデスクトップクライアントでは、ルールモード、グローバルモード、ダイレクトモードなどが分かれており、ダイレクトが選ばれていると、ノードを設定していても外部通信は直接接続になります。
通常は、最初にルールモードで確認します。国内サービスや社内サイトを直接接続に残しながら、ChatGPT 関連の通信だけをプロキシへ送れるため、速度と互換性のバランスを取りやすいからです。ただし、ルールの記述が不足している場合は、対象ドメインが DIRECT に落ちます。原因が分からない段階では、一時的にグローバルモードへ切り替えて、ChatGPT が開くかを比較すると、ルール分流の問題かどうかを判定できます。
グローバルモードで改善した場合は、ノードそのものよりもルールに問題がある可能性が高いです。逆にグローバルモードでもタイムアウトするなら、現在のノード、プロキシポート、DNS、または上流ネットワークを調べます。検証後はグローバルモードを常用せず、必要な通信だけを分流する構成へ戻す方が、国内サイトの速度低下や不要な経路変更を防げます。
次に OS のシステムプロキシが有効かを確認します。ブラウザはシステム設定を参照していても、ChatGPT のデスクトップアプリ、ターミナル、IDE、バックグラウンドサービスは独自の設定や環境変数を使うことがあります。Clash の混合ポート番号が表示されている場合は、そのポートが実際に待ち受け中であること、ほかの VPN やプロキシが同じ設定を上書きしていないことも確認してください。
ChatGPT 関連通信が正しいルールに入っているか確認する
ルールモードでは、Clash はアクセス先のドメインや IP、プロセスなどを上から順番に評価します。上位にある広いルールが先に一致すると、下に追加した ChatGPT 向けルールは使われません。そのため、ルールを追加する場合は、最後の MATCH ルールだけを見て判断せず、Clash の接続ログで実際にどのルール名とポリシーへ一致したかを確認します。
ChatGPT のウェブ画面では、サービス本体だけでなく、ログイン、認証、静的ファイル、API、ストリーミングなど複数の接続先が使われることがあります。特定のドメインを固定的に大量登録するより、まず失敗した時刻のログを保存し、繰り返し現れるホストを確認する方が安全です。サービス側の構成変更でドメインが増減することもあるため、古いリストをそのまま信頼しないでください。
接続ログで ChatGPT 関連の通信が DIRECT になっているなら、対象ルールが読み込まれていないか、ルールの順番が適切でない可能性があります。反対に、すべてがプロキシへ送られているのに接続が失敗する場合は、ノードの混雑、TLS 接続、DNS、またはサーバー側の一時障害を調べます。ログにホスト名が表示されない場合は、ログレベルを一時的に上げて確認し、調査が終わったら通常のレベルへ戻してください。
プロキシグループが複数ある場合は、同じグループ内の自動選択だけに任せず、候補を一つずつ試します。低遅延でも長時間通信が不安定なノードがありますし、速度測定が良くても ChatGPT との TLS 接続やストリーミングに向かない場合があります。短いページ読み込みと、回答生成を数分続けるテストを分けて実施すると、単純な遅延と継続接続の問題を区別できます。
DNS 解決と接続先の不一致を調べる
ChatGPT のページが突然開かなくなったときは、プロキシ設定だけでなく DNS も確認します。DNS はドメイン名を IP アドレスへ変換する仕組みで、Clash の DNS 設定と OS、ブラウザ、ルーターの設定が重なると、意図しない解決結果になることがあります。名前解決に時間がかかる、同じドメインが短時間で異なる経路へ変わる、IPv6 だけ失敗するといった症状は、タイムアウトとして表示される場合があります。
まず Clash の DNS 機能を有効にしているか、設定ファイルに記述した DNS サーバーへ実際に到達できるかを確認します。DNS の変更は、ノード変更と同時に行わないでください。ノードと DNS を一度に変えると、改善した理由が分からなくなります。既存設定を保存したうえで、DNS のみを標準構成に戻し、ChatGPT の読み込みを再試行します。
IPv6 を有効にしている環境では、IPv4 と IPv6 のどちらが使われているかも確認します。プロバイダやネットワークによっては IPv6 の名前解決は成功しても、実際の経路が不安定なことがあります。Clash や Mihomo に IPv6 を制御する項目がある場合は、現在のネットワークでの挙動を比較し、片方を一時的に無効にして差を見ます。ただし、会社や学校のネットワークでは管理者のポリシーを優先し、無断で DNS を固定しないようにしてください。
ブラウザの DNS キャッシュや既存の接続が残っていると、設定変更後も古い結果が使われることがあります。Clash の再起動、ブラウザの完全終了、必要に応じた OS の DNS キャッシュ更新を順に行います。再起動を繰り返すだけではなく、再起動前後でログと接続結果を比較することが重要です。
TUN を使うべき場面と注意点
システムプロキシを有効にしても ChatGPT のアプリや CLI が直接接続する場合、TUN モードが有効な解決策になることがあります。TUN は OS のより低いネットワーク層で通信を取り込み、アプリが明示的なプロキシ設定を持っていない場合でも Clash のルールへ渡せる方式です。ブラウザ以外のアプリも同じ経路へ乗せやすい一方、設定を誤ると LAN、社内 VPN、プリンター、銀行サイトなどまで影響します。
TUN を試す前に、Clash が管理者権限やネットワーク拡張の許可を必要としていないか確認します。OS のセキュリティ設定で拡張機能が拒否されている場合、スイッチをオンにしても実際には通信を取り込めません。また、別の VPN、ゼロトラスト製品、仮想マシンのネットワーク、Docker の仮想インターフェースがあると、経路が競合することがあります。検証時は不要な VPN を停止し、LAN 内の重要なサービスへアクセスできるかも確認してください。
安全な手順は、まずシステムプロキシとルールモードでテストし、アプリだけ失敗する場合に TUN を短時間有効にすることです。TUN をオンにした後、ChatGPT のページ、通常の国内サイト、ローカル管理画面の三つを確認します。ChatGPT だけが改善し、他の通信に問題がなければ候補として使えます。すべての通信が遅くなったり、VPN 接続が切れたりする場合は、TUN をオフに戻し、ルールやアプリ側のプロキシ設定を優先して見直します。
実際に行う切り分け手順
ここでは、変更を最小限に抑えながら確認する流れをまとめます。各ステップの結果をメモし、前の状態へ戻せるようにしてください。
- Clash の稼働を確認する：クライアントが起動し、設定画面でコアが実行中になっていることを確認します。混合ポート番号と現在のプロファイル名も記録します。
- ノードを一つに固定する：自動選択を一時停止し、比較的安定している候補を一つ選びます。選択直後に接続が変わる構成は、テスト結果が安定しません。
- モードを比較する：ルールモードで ChatGPT を開き、失敗する場合だけ短時間グローバルモードを試します。グローバルだけ成功するなら、ルールや DNS の確認へ進みます。
- 接続ログを見る：ページを再読み込みし、ChatGPT 関連の接続が表示されるか、DIRECT かプロキシか、エラーが DNS・TLS・タイムアウトのどれかを確認します。
- アプリを分けて試す：同じノードでブラウザ、デスクトップアプリ、必要なら CLI を別々に確認します。ブラウザだけ成功する場合は、アプリ側のプロキシ認識を疑います。
- TUN を最後に比較する：システムプロキシで解決しない場合のみ TUN を有効にし、ChatGPT と通常サイト、LAN サービスへの影響を確認します。
コマンドラインから確認する場合は、環境変数に設定されたプロキシが実際のシェルへ引き継がれているかを確認します。たとえば HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY の値を確認できます。ただし、アプリによって対応する変数名や SOCKS の書式が異なるため、値を設定すれば必ず動くとは限りません。秘密情報を含むプロキシ URL をログや画面共有へ貼り付けないよう注意してください。
直らないときに避けたい設定変更
タイムアウトが続くと、ノードを短時間で何度も切り替えたり、ルールを大量に追加したり、DNS と TUN を同時に有効にしたりしがちです。しかし、これでは改善の条件を再現できません。特に自動テストの結果だけで「最速ノード」を選ぶ方法は、ChatGPT の長時間ストリーミングに適しているとは限りません。遅延、パケット損失、接続維持時間、同時接続数を別々に評価してください。
また、ChatGPT のサーバー側障害やアカウントの制限を Clash の問題と決めつけないことも大切です。Clash を完全に停止した状態で、現在の回線から他の主要サイトが開くか、別のネットワークでは同じアカウントが使えるかを確認します。複数の端末で同時に失敗しているなら、ローカル設定より上流サービスや回線の問題である可能性が高くなります。
ブラウザの拡張機能、Cookie、キャッシュもログインループや画面表示の異常を引き起こします。プライベートウィンドウで同じ操作を試し、そこで改善するなら、Clash のルールを変更する前に拡張機能と保存データを整理します。企業ネットワークの TLS 検査や認証プロキシがある場合は、証明書エラーを無視せず、管理者が指定する方法で対応してください。
再発を防ぐための安定運用
原因が分かったら、設定を必要最小限に戻します。ChatGPT 関連の通信だけを適切なプロキシグループへ送り、国内サイトや社内サービスは必要に応じて DIRECT に残します。ルールの変更履歴をメモし、どのドメインを追加したか、どのノードで成功したか、TUN の有無はどうだったかを記録しておくと、プロファイル更新後の比較が簡単になります。
購読プロファイルを更新した後は、ルール、DNS、プロキシグループの名前が変わっていないかを確認してください。自動更新によってグループ構成やルールの優先順位が変わると、以前は動いていた設定が突然失敗することがあります。更新直後に問題が起きた場合は、現在のプロファイルと直前のバックアップを比較し、更新以外の変更を加えずに検証します。
毎回グローバルモードや TUN に頼るのではなく、ブラウザとアプリのプロキシ経路を揃え、ログで確認できるルールを作ることが安定運用につながります。Clash の利点は、ノードを切り替えられることだけではありません。接続先、ポリシー、DNS、アプリの経路を可視化し、問題を一つずつ説明できる点にもあります。
単純な VPN アプリは設定が少ない反面、ChatGPT だけを別経路へ送れなかったり、アプリごとのプロキシ認識を確認しにくかったりします。一方、Clash はルールログ、プロキシグループ、DNS、TUN を分けて調整できるため、ブラウザは成功するのにアプリだけタイムアウトするケースでも原因を追いやすくなります。複雑な設定を最初から増やさず、今回紹介した順番で段階的に確認したい方は、利用環境に合う Clash クライアントを入手して試してみてください。