Clashを有効にしているのにChatGPTが開かない、ログイン画面までは表示されるのに応答中のまま止まる、または「接続がタイムアウトしました」と表示されることがあります。この症状は、ノードの品質だけでなく、Clashへ通信が入っていない、ルールが誤ってDIRECTになっている、DNS解決に失敗している、TLS接続やIPv6経路で待ち時間が発生しているなど、複数の原因で起こります。

ChatGPTの通信を安定させるには、最初からDNSやTUNの設定を大きく変更するのではなく、アプリからClash、ルール、DNS、ノード、上流サーバーという順番で確認することが重要です。この記事では、Clash Verge、Clash Verge Rev、Clash for Windows、ClashX、Clash for Android、mihomoを利用している場合に共通する切り分け手順を整理します。画面名はクライアントによって異なりますが、確認する対象はほぼ同じです。

ChatGPTがClashで開けない?タイムアウトの原因と対処法

まずタイムアウトの症状を分類する

「ChatGPTが使えない」という表示だけでは、障害が発生している場所を判断できません。ブラウザーでサイト自体が開かないのか、画面は開くがAPIリクエストが失敗するのかによって、確認すべき項目が変わります。最初に、Clashを停止した状態、システムプロキシだけを有効にした状態、TUNを有効にした状態を比較すると、通信の入口に問題があるかを把握できます。

  • ページが読み込まれず、DNSエラーや接続拒否になる場合は、名前解決、ルール、ノード到達性を確認します。
  • ページは表示されるもののログイン画面や会話一覧が終わらない場合は、関連するAPI、認証、静的コンテンツのルールを確認します。
  • 入力欄から送信した後だけタイムアウトする場合は、長時間接続、ストリーミング応答、選択中ノードの安定性を確認します。
  • ブラウザーでは使えるのにデスクトップアプリやスマートフォンアプリだけ失敗する場合は、そのアプリがシステムプロキシを利用しているか確認します。
  • 特定のノードだけで発生する場合は、Clash全体ではなく、そのノードの出口、帯域、接続制限、地域条件に問題がある可能性があります。

検証では、同じブラウザー、同じアカウント、同じノードを使い、変更した項目だけを記録します。ChatGPTのページが表示されたかだけで判断せず、ログイン、短いメッセージの送信、長めの回答の受信まで確認すると、単純なページ表示と持続接続の違いを区別できます。

システムプロキシとTUNの入口を確認する

Clashのルールが正しくても、ChatGPTの通信がClashカーネルへ入っていなければ、設定は適用されません。システムプロキシ方式では、ブラウザーやアプリがOSのHTTP、HTTPS、SOCKS設定を読み取り、通常は127.0.0.1のローカルポートへ接続します。Clash Vergeなどで「システムプロキシ」をオンにしても、独自のネットワーク処理を使うアプリ、ブラウザー内で別のプロキシを指定している環境、仮想マシン内のアプリには反映されないことがあります。

まずブラウザーのプロキシ設定を確認し、Clashの接続ログにChatGPT関連のホスト名が表示されるかを見ます。ログに対象通信がまったく出ない場合、ルール以前にプロキシ入口を通っていない可能性があります。ブラウザーを完全に終了して再起動し、既存の接続やキャッシュされたプロキシ状態を残さないようにすることも有効です。

TUNモードは仮想ネットワークインターフェースでIP通信を取り込むため、システムプロキシを読まないアプリにも適しています。ただし、TUNは有効にするだけで完了する機能ではありません。TUNのスタック、ルート設定、DNS hijack、IPv4・IPv6の扱い、管理者権限、他のVPNやセキュリティソフトとの競合が関係します。TUNを有効にした直後からすべての通信が失敗する場合は、いったんTUNを無効にしてシステムプロキシで比較してください。

  • Clashのローカル混合ポートが起動しており、他のアプリとポート競合していないか確認する。
  • OSのプロキシ設定が古いポート番号や停止中のアドレスを指していないか確認する。
  • 別のVPN、プロキシソフト、広告ブロッカーが同時に通信を取り込んでいないか確認する。
  • TUN利用時は、管理者権限と仮想インターフェースの状態、DNS hijackのエラーをログで確認する。
  • IPv6を使用している環境では、IPv6だけがDIRECTや失敗するルートへ流れていないか確認する。

実際に通信経路を一つずつテストする

ここでは、設定を大きく変更せずに原因を絞り込みます。最初にClashでログ表示を有効にし、現在のモードを記録します。次に選択中のプロキシグループを確認し、ChatGPTを開いた瞬間にどのホストがどのポリシーへ振り分けられたかを確認してください。画面に表示されるドメイン名はクライアントや時期によって変わるため、単一のホスト名だけを許可するのではなく、ログに現れた関連ドメインを確認しながらルールを見直します。

ブラウザーとは別に、ローカルのHTTPプロキシポートを指定して名前解決と接続をテストします。ポート番号は自分のClash設定に合わせて変更してください。次の例では、混合またはHTTP互換ポートを7890として扱っています。

curl -I --proxy http://127.0.0.1:7890 https://chatgpt.com/

curl -v --proxy http://127.0.0.1:7890 https://chatgpt.com/

nslookup chatgpt.com

curlでローカルプロキシへ接続できない場合は、ChatGPT以前にClashの待受ポート、OSのプロキシ指定、ファイアウォールを確認します。ローカルポートへの接続は成功するものの、TLS確立やレスポンス取得で止まる場合は、ノード、ルール、DNS、上流接続のいずれかに問題があります。ブラウザーの開発者ツールを使える場合は、失敗したリクエストのホスト、ステータス、待ち時間も記録します。

次に、同じ設定で別のノードへ切り替えます。1つのノードだけで失敗し、複数の別ノードで成功するなら、ルール全体を変更する必要はありません。反対に、すべてのノードで同じホストだけが失敗する場合は、DNSやルールの設定を優先して確認します。Clashのログにtimeoutconnection resetno such hostcontext deadline exceededなどの内容があれば、エラーの種類をそのまま記録しておくと判断しやすくなります。

ルールとDNSの不整合を修正する

ChatGPTの通信がDIRECTへ送られていると、利用中のネットワークによってはページやAPIへ到達できないことがあります。一方で、すべての通信を無条件にPROXYへ送る設定も、必要なログインサービスや地域サービスとの組み合わせによっては別の問題を起こします。ルールは「ChatGPTの画面を開くドメイン」だけでなく、ログイン、静的ファイル、API、認証処理に使われる複数の接続を考慮して確認します。

ルール画面で対象通信がどのルールに一致したかを確認し、意図しないDIRECTREJECT、または利用不能なポリシーグループへ送られていないか調べます。ルールプロバイダーを使っている場合は、更新に失敗して空のルールセットになっていないか、ルールの順序が広すぎるMATCHやGEOIPルールに先に一致していないかも確認してください。修正後は設定を保存するだけでなく、ルールプロバイダーとカーネルを再読み込みします。

DNSでは、ドメインが解決できない、古いアドレスが返る、IPv6アドレスだけが到達不能、またはDNS問い合わせ自体がローカルネットワークへ漏れるといった問題が起こります。ClashのDNS機能を利用する場合は、DNSポート、fake-ipまたはredir-hostの方式、fallback、nameserver-policy、IPv6設定の組み合わせを確認します。fake-ipを利用している環境で特定のドメインが正常に動かない場合は、むやみにfake-ip全体を無効にせず、そのドメインがfake-ip-filterに入っているか、アプリがIPアドレスの固定や証明書検証を行っていないかを調べます。

ノード、TLS、接続維持を確認する

ChatGPTでは、トップページの取得よりもログイン処理や会話応答のほうが長い接続を必要とする場合があります。そのため、ページが開いたことだけを基準にノードを評価すると、実際の利用時にタイムアウトを見逃します。ノードを選ぶときは、遅延値だけでなく、TLS接続の安定性、連続通信時の切断、混雑時間帯のパケットロスを確認してください。

Clashの遅延テストが成功しても、対象サイトへの接続が成功するとは限りません。遅延テストは指定URLへの短いHTTPリクエストであることが多く、ChatGPTで必要になる複数のホスト、認証、ストリーミング応答を完全には再現しないためです。候補ノードを2つ以上試し、同じブラウザー操作でログインとメッセージ送信まで比較します。

  • ノードの遅延は低いが、長い回答の途中で切断される場合は、出口側の接続維持や混雑を疑う。
  • TLS handshakeで停止する場合は、ノードの到達性、時刻設定、SNI処理、ネットワーク側の干渉を確認する。
  • 接続直後にリセットされる場合は、ノード側の同時接続制限や地域制限を確認する。
  • 自動選択グループが不安定なノードへ切り替え続ける場合は、手動選択で固定して比較する。
  • 同一ノードを複数のクライアントや端末で共有している場合は、混雑と接続数の影響を考慮する。

再発を防ぐための安定した構成

原因を特定した後は、変更した設定を整理します。最初から複雑なルールや多数のDNS上流を採用するより、動作確認できる最小構成を基準にして、必要な機能だけを追加するほうが安全です。デスクトップでは、まずシステムプロキシとTUNのどちらか一方を選び、ChatGPTが安定してからもう一方を検証します。両方を同時に使うと、二重取り込みやループが発生する環境があります。

運用時には、カーネルとクライアントを別々に記録してください。Clash Verge Revを更新しても、内蔵されているmihomoのバージョンや設定の読み込み結果が同じとは限りません。設定を更新した後にChatGPTだけが使えなくなった場合は、まず設定解析エラーと未対応フィールドを確認し、古いバックアップとの差分を調べます。

また、ブラウザーのキャッシュ、Cookie、拡張機能、独自のセキュアDNSも切り分け対象です。シークレットウィンドウで動作する場合、Clashのルールだけでなく、ブラウザー拡張機能や保存された認証状態が影響している可能性があります。逆に、すべてのブラウザーとアプリで同時に失敗する場合は、クライアント、ノード、DNS、ネットワーク側を優先して確認します。

症状 優先して確認する項目 次の切り分け
ChatGPTのページ自体が開かない プロキシ入口、DNS、対象ルール ログとcurlでローカルポートを確認する
ログインだけが終わらない 認証関連ドメイン、Cookie、ノード 別ブラウザーと別ノードで比較する
送信後にタイムアウトする ノードの安定性、長時間接続、TLS 手動選択した別ノードで長文応答を試す
TUNを有効にした後だけ失敗する ルート、DNS hijack、IPv6、権限 TUNを停止し、システムプロキシで再現する

タイムアウト対策の基本は、ChatGPT専用の設定を無制限に増やすことではありません。通信がClashへ入っているか、正しいルールに一致しているか、DNSが期待したアドレスを返しているか、選択したノードが長時間通信を維持できるかを順番に確認することです。証拠をログに残し、1回に1項目だけ変更すれば、Clashの種類やOSが変わっても同じ手順で原因を追跡できます。

Clashの設定を確認する

利用中のOSに合ったクライアントを選び、プロキシモード、DNS、TUNの設定を順番に見直してください。

Clashをダウンロード