1. ホーム
  2. ブログ
  3. ClashでChatGPTがタイムアウトする原因と直し方｜接続設定を確認

ClashでChatGPTがタイムアウトする原因と直し方｜接続設定を確認

ChatGPTだけがタイムアウトする症状を切り分ける

Clashを有効にすると一般のウェブサイトは開けるのに、ChatGPTだけが読み込み中のまま止まる、ログイン後に画面が更新されない、回答生成の途中で接続が切れるという症状が発生することがあります。この場合、Clash全体が停止しているとは限りません。ChatGPTに必要なドメインの一部だけが誤ったルールにマッチしている、選択中のノードが長時間接続に向いていない、DNSの応答が不安定になっている、といった限定的な問題である可能性があります。

まずブラウザで通常のHTTPSサイトを開き、Clashの管理画面で通信ログを表示します。ChatGPTを再読み込みした直後に、該当するリクエストが DIRECT に送られているのか、特定のプロキシグループに入っているのか、あるいは接続エラーになっているのかを確認してください。単に画面の表示だけを見るより、ログのドメイン名・使用された策略グループ・エラー内容を組み合わせたほうが原因を絞り込めます。

「タイムアウト」という表示は、ChatGPT側の障害だけを意味しません。DNS応答、TLS接続、プロキシノードの混雑、ルールの誤振り分け、TUNの経路設定など、接続のどの段階でも同じような症状が現れます。

動作モードとシステムプロキシを確認する

Clash系クライアントには、通常 Rule、Global、Direct などの動作モードがあります。Direct ではプロキシを通らないため、接続環境によってはChatGPTのページ自体やAPI通信に到達できません。反対に、Global にして一時的に接続できる場合は、ノードそのものよりもルールの振り分けに問題がある可能性が高くなります。

Clash VergeやClash Verge Revでは、メイン画面のモード切り替えとプロキシグループの選択欄を確認します。Clash for WindowsではGeneral画面のシステムプロキシとMode、ClashXではメニューバーのモードとProxy設定を確認します。Android版では、アプリ内のサービススイッチに加えて、AndroidのVPN接続が有効かどうかも見てください。システムプロキシ方式とTUN方式は通信を捕捉できる範囲が異なるため、ブラウザ以外のアプリで発生する問題ではTUN設定も重要です。

  • Clashのサービスが起動していることを確認する。
  • テスト中は動作モードを一時的に Global にする。
  • システムプロキシが有効で、ブラウザが手動設定と自動設定を二重に使っていないか確認する。
  • TUNを使う場合は、仮想インターフェース、ルート設定、DNSハイジャックの状態を確認する。
  • 別のVPN、セキュリティソフト、企業ネットワークのプロキシが同時に動作していないか確認する。

Globalモードでもタイムアウトする場合は、ルールよりもノード、DNS、MTU、または上流ネットワークを優先して調べます。Globalモードだけ成功する場合は、次のルール確認に進みます。

ChatGPT関連ドメインのルール振り分けを調べる

Ruleモードでは、設定ファイルのルールが上から順番に照合され、最初に一致したルールで処理が決まります。ChatGPTの画面は一つのドメインだけで完結するとは限らず、ログイン、画面表示、APIリクエスト、ストリーミング応答などで複数のホストへ接続することがあります。そのため、トップページだけをプロキシに送っても、別の通信が DIRECT や拒否グループへ送られると、画面が途中で止まることがあります。

ログで確認したドメインをそのまま記録し、既存のルールセットがどのグループへ送っているかを見ます。ChatGPT関連のドメインを手作業で無制限に追加するのではなく、利用しているルールセットの設計と重複しない形で管理してください。特定の文字列だけに依存した DOMAIN-KEYWORD は、意図しないドメインまで対象にすることがあります。可能なら実際のログに現れたドメインを基準に、より限定的な DOMAIN または DOMAIN-SUFFIX を検討します。

mode: rule
rules:
  - DOMAIN-SUFFIX,openai.com,ChatGPT
  - DOMAIN-SUFFIX,chatgpt.com,ChatGPT
  - MATCH,PROXY

上の例は構造を示すための簡略例です。実際の設定では、使用中のサブスクリプションが提供するプロキシグループ名に合わせて変更してください。また、既存の拒否ルールや地域別ルールがこれより上にある場合、先にそちらへ一致することがあります。MATCH を途中に置くと、それ以降のルールは評価されないため、必ず最後の受け皿として扱います。

画面を見ながら復旧する手順

ここでは設定を大きく変更せず、原因を一つずつ切り分けます。クライアントによってボタン名は異なりますが、確認する順序はほぼ共通です。

  1. 現在の状態を記録する:Clashのモード、選択中のプロキシグループ、TUNとシステムプロキシの状態、ログに表示されるエラーを控えます。
  2. ノードを一つだけ変更する:同じグループ内で別地域のノードを選び、30秒から1分ほど待ってからChatGPTを再読み込みします。自動選択が不安定な場合は、テスト中だけ手動選択に切り替えます。
  3. Globalで比較する:Globalモードで接続できるなら、ノードは動作しているため、Ruleモードのルールやルールセットを確認します。
  4. ログを再確認する:ページを完全に再読み込みし、タイムアウトしたリクエストがどのプロキシグループへ入ったかを確認します。失敗したドメインが毎回同じなら、ルール対象を見直します。
  5. DNSを更新する:DNSキャッシュ、Fake-IPのマッピング、ルールプロバイダーの状態を更新します。更新後はブラウザも閉じて、再度接続を試します。
  6. 最後にTUNを切り替える:ブラウザだけで試す場合はいったんTUNを無効にし、システムプロキシ方式で比較します。逆に他のアプリでも失敗する場合は、TUNを有効にして経路の違いを確認します。

複数の項目を同時に変更すると、どの設定が改善に効いたのかわからなくなります。モード、ノード、DNS、ルールの順に一項目ずつ変え、接続結果を記録する方法が安全です。

DNS解決とFake-IPが原因になる場合

ChatGPTのドメインが正しいプロキシへ振り分けられていても、DNS解決が失敗すると接続は始まりません。特にTUNモードで、端末のDNS、Clash内蔵DNS、ルーターのDNSが混在すると、アプリが得たIPとClashが保持するドメイン情報に不整合が生じることがあります。その結果、ログには接続先が表示されない、短時間で再接続を繰り返す、TLS確立前にタイムアウトする、といった形で現れます。

Fake-IPを使っている場合は、Fake-IPフィルターも確認します。特定のドメインをフィルターへ入れると、そのドメインだけ実IPを返す動作になり、他のドメインと異なるルール経路を通ることがあります。互換性のために除外する必要があるアプリもありますが、理由がないまま多数のドメインを追加すると、DNS方式が複雑になり、問題の切り分けが難しくなります。

確認対象見直すポイント判断の目安
DNSモードfake-ip、redir-host、上流DNSの設定方式を変更して改善するか比較する
DNSハイジャックTUNのDNSリクエストがClashへ届いているか端末側DNSへ直接抜けていないか確認する
Fake-IPフィルター対象ドメインが除外リストに入っていないか追加・削除は一項目ずつ試す
ルールプロバイダー更新失敗、古いキャッシュ、読み込みエラー更新後にルールのヒット先を再確認する

DNS設定を変更した後は、ClashのDNSキャッシュだけでなく、ブラウザの接続プールやOSのDNSキャッシュも残る場合があります。ブラウザを完全に終了し、必要ならClashのサービスを再起動してから再テストしてください。

ノード品質、TLS、長時間接続を確認する

ChatGPTはページを表示するだけでなく、回答生成中に継続的なストリーミング通信を行います。短いページの読み込みに成功しても、ノードの混雑やパケットロスが大きいと、生成途中で接続が止まることがあります。Clashの遅延テストは、指定URLへの往復時間を測る指標であり、実際の速度、帯域、長時間接続の安定性を完全には表しません。低遅延のノードでも混雑時間帯に失速することがあります。

  • 同じ地域のノードを複数試し、接続開始までの時間と生成中の安定性を比較する。
  • 自動選択グループのテストURLが実際の用途と大きく異ならないか確認する。
  • Hysteria2やTUICなどQUIC系ノードで不安定な場合、TCP系の別ノードも試す。
  • 逆にTCP系で遅延が大きい場合は、利用可能なQUIC系ノードを比較する。
  • 同じノードで他の長時間ストリーミング通信も切れるか確認し、ChatGPT固有の問題か判断する。

TLSエラーがログに出る場合は、端末時刻が正しいか、HTTPS通信を検査するセキュリティソフトがないか、プロキシの証明書関連設定が適切かを確認します。証明書検証を無条件に無効化する設定は安全性を下げるため、タイムアウト対策として常用しないでください。

TUN、MTU、他のネットワーク機能の競合

Webブラウザだけでなくデスクトップアプリやモバイルアプリでもタイムアウトする場合、TUN経路の問題を疑います。TUNは仮想ネットワークインターフェースで通信を捕捉するため、別のVPN、企業用セキュリティエージェント、Dockerや仮想マシンのネットワーク、OSの特殊なルート設定と競合することがあります。Clashの画面でTUNが有効に見えても、実際のルーティングが正しく適用されているとは限りません。

一時的にTUNを無効にしてシステムプロキシだけでChatGPTを試し、結果を比較してください。システムプロキシでは成功し、TUNでだけ失敗するなら、TUNのスタック方式、ルート自動設定、DNSハイジャック、MTUを順番に確認します。MTUが経路に対して大きすぎると、特定サイズのパケットだけが破棄され、ページは開くのにストリーミング通信が止まることがあります。値を変更する場合は一度に大幅に変えず、元の値を記録してから少しずつ比較します。

再発を防ぐための安定設定

原因を解消した後は、動作モードを必要以上に複雑にしないことが重要です。通常は Rule モードを基本とし、ChatGPT関連の通信が意図したグループへ入ることをログで確認します。プロキシグループには応答速度だけでなく、混雑時間帯の安定性や長時間接続の維持も反映させてください。自動選択が頻繁にノードを変更する場合、回答生成中の経路が変わらない手動選択のほうが安定することがあります。

また、サブスクリプション更新後にルールやグループ名が変わることがあります。更新のたびにChatGPTの通信がどのグループへ送られているかを確認し、古いグループ名を参照した手書きルールが残っていないか点検してください。ルールプロバイダーを使う場合も、更新日時と読み込み状態を定期的に確認します。設定をバックアップしておけば、変更後に問題が出た際に直前の状態へ戻して比較できます。

安定性を優先する基本方針は、Ruleモードでログを確認する、ChatGPTの通信を一つの安定したグループへ送る、DNS経路を一つに整理する、TUNと他のVPNを同時に使わないことです。これだけでも原因不明のタイムアウトは大幅に切り分けやすくなります。

ノードリストの表示情報が示すもの

クライアントのプロキシグループ画面を開くと、各ノード名の後ろに数値やマークが表示されます。レイテンシの数値、倍率のバッジ、地域コードなどです。これらの情報は一見シンプルですが、解釈を誤ると「速そうに見える」ノードを選んでも実際には頻繁にカクつくことになります。ノードを正しく選ぶには、まずこれらの指標がそれぞれ何を測っているのかを理解する必要があります。各指標は測る軸が異なり、互換性はありません。

ノードリストの本質はサブスクリプションが提供する設定ファイルであり、各項目は config.yaml の proxies フィールド下にある1つのアウトバウンド設定に対応し、サーバーアドレス、ポート、プロトコル種別、認証パラメータを含みます。クライアントが行っているのは、これらの項目を選択可能なリストとして描画し、その上に自前で実装した速度測定と状態検知のロジックを重ねることです。そのため同じサブスクリプションでも、クライアントが異なればノード数やパラメータは一致していてもレイテンシの数値が変わることがあります。測定先のアドレス、測定頻度、タイムアウトの閾値がクライアントごとに統一されていないためです。

レイテンシ測定が示す意味と、低レイテンシが高速度を保証しない理由

クライアントに表示されるレイテンシの数値は、多くの場合1回のHTTPまたはTCP探測の往復時間(RTT)です。探測対象は通常固定のテストアドレスで、軽量なエンドポイントにリクエストを送り、最初のバイトが返るまでの時間を記録するのが一般的な方式です。この数値は「接続を確立して最初のレスポンスを得る」までにかかる時間をミリ秒単位で表したもので、数値が小さいほど端末からプロキシサーバー、テスト対象までのハンドシェイクが速いことを意味します。

しかし低レイテンシは高いダウンロード速度を意味しません。これは別々の指標です。レイテンシは往復時間を測るもので、速度は単位時間あたりに転送できるデータ量を測るものであり、後者は帯域幅、同時接続数、サーバーの現在の負荷、経路の混雑状況など複数の要因に左右されます。典型的な例として、あるノードのレイテンシが80msと理想的に見えても、サーバーの出口帯域が多数のユーザーに占有されており実際のダウンロード速度は数百KB/sしかない、というケースがあります。一方でレイテンシ250msのノードでも出口帯域に余裕があれば、ダウンロード速度は帯域上限まで出ることもあります。つまりレイテンシは選別の最初のふるい(タイムアウトやレイテンシ1000ms超えなど明らかに使えないノードを除外する)にしか使えず、唯一の並べ替え基準にはできません。

ノードの良し悪しを判断するより確実な方法は、レイテンシと実測ダウンロード速度の2指標を組み合わせて検証することです。まずレイテンシで候補プールを絞り込み、次に候補の中から2〜3件を選んで同じテストファイルをダウンロードし実速度を比較、最後に速度が安定しているものを常用ノードとして固定します。

また、測定頻度がノードの生存状態に与える影響にも注意が必要です。自動測定機能を備えたクライアントもありますが、間隔を短く設定しすぎるとサーバーに無用なリクエスト負荷をかけ、サーバー側のレート制限に異常なトラフィックと誤認されて一時的に制限されることもあります。手動測定、あるいは10数分ごとの自動測定で十分であり、数秒おきに間隔を設定する必要はありません。

流量倍率の計算方法と実際の消費量への影響

ノード名の後ろにある倍率表示(x0.5、x1、x2やパーセント表記が一般的)は、そのノードがサブスクリプションの流量をどれだけ消費するかを示す係数です。倍率は速度の速さを示すものではなく、課金の重みです。x0.5倍率のノードで1GBダウンロードすると、実際に流量パッケージから減るのは0.5GBのみです。x2倍率のノードで1GBダウンロードすると、2GB分が減算されます。

倍率が異なる主な原因には、ノードが位置する地域の帯域コストが高い(海外の主要出口など)、ピーク時間帯限定の割引措置である、あるいは事業者が倍率を使って負荷が軽い拠点にユーザーを誘導し負荷を分散させている、といったケースがあります。低倍率ノードは負荷が重かったり回線が混雑している拠点に対応することが多く、高倍率ノードは回線品質が良い分コストも高くなる傾向があります。これはトレードオフの関係であり、「倍率が低くて回線も良い」という都合の良い話は基本的に存在しません。

  • 日常のWebブラウジング・メッセージアプリ: 速度への要求は高くないため、低倍率ノードを優先すれば月間流量パッケージの利用期間を大きく延ばせます。
  • 大容量ファイルのダウンロード・高画質動画・クラウド同期: 倍率が中程度でもレイテンシと速度の実測が良好なノードを優先し、流量を節約しようとして接続を長時間占有し体感が悪化するのを避けましょう。
  • 緊急対応・短時間の優先タスク: 倍率を気にせず、最も安定して動作するノードを直接選んで構いません。

プロキシグループでは、低倍率ノードを「日常グループ」、高倍率・高品質のノードを「高負荷グループ」としてまとめ、ルールベースの振り分けと組み合わせてアクセス先のドメインやアプリの種類に応じて適切なグループへ自動的に割り振るのがおすすめです。すべての通信を同一ノードに通す必要はありません。

地域別ノードの選び方と、解除できるコンテンツの違いが生じる理由

ノード名にある地域コード(HK、SG、JP、USなど)は、サーバーが物理的に設置されている地域を示しています。これは2つの点に直接影響します。よく使うサービスまでの物理的な経路距離と、アクセスできるコンテンツライブラリのバージョンです。地理的に近いほど経路のホップ数は少なくなり、レイテンシの基礎値も低くなる傾向があります。これが近隣地域のノードがレイテンシランキングの上位によく登場する理由です。

解除できるコンテンツの違いの本質は、対象サービスがアクセス元の出口IPから地域を判定し、地域ごとに異なるコンテンツライブラリや機能を提供している点にあります。つまり、サブスクリプション上の地域コードがある国を示していても、サーバーの実際の出口IP帯が対象サービスに別の地域と判定されたり、データセンター/プロキシのIP帯としてマークされていたりすれば、解除は失敗します。逆に言えば、同じ地域コードでも事業者が調達しているIP帯の品質はまちまちであり、名前だけを見て解除効果が同じだと判断することはできません。

地域ノードを選ぶ実践的な考え方:

  1. まず主な用途が「近い地域でレイテンシを下げること」か「特定地域のコンテンツにアクセスすること」かを明確にします。両者の優先順位は異なります。
  2. レイテンシ重視の場合は、地理的に近くレイテンシの基礎値が低い地域を優先します。
  3. コンテンツアクセス重視の場合は、候補ノードで実際にアクセステストを行い、対象コンテンツが正常に表示されることを確認します。ノード名の地域タグだけを見て判断してはいけません。
  4. 同じ地域に複数のノードがある場合は、順番に速度と安定性を実測し結果を記録しておくと、毎回感覚だけで試行錯誤するのを避けられます。

各プロトコルの安定性と速度のトレードオフ

ノード項目のプロトコル種別は、接続の実装方式を決定します。プロトコルごとに耐干渉性、伝送効率、ハンドシェイクコストの重視点が異なるため、選択時にはネットワーク環境と組み合わせて判断する必要があり、あるプロトコルが絶対的に他より優れているとは言えません。

プロトコルトランスポート層特徴適した場面
ShadowsocksTCP/UDP実装がシンプルでハンドシェイクコストが小さく、暗号方式を選択可能ネットワーク制限が緩く低レイテンシを重視する場合
VMess / VLESSTCP/WS/gRPC複数のトランスポート層カプセル化に対応し、TLS偽装と組み合わせ可能検閲が厳しいネットワーク環境
TrojanTCP + TLS通信の特徴が通常のHTTPSに近く、ハンドシェイクコストはやや高いより高い耐干渉性が必要な環境
Hysteria / TUICQUICベースUDPベースで実装され、通信品質が悪い状況での再送効率が高いパケットロス率が高く不安定な回線

選択の原則を簡単にまとめると次のとおりです。ネットワーク制限が少ない環境であれば、Shadowsocksはハンドシェイクが速くCPU負荷も低いため、レイテンシの面で最も直接的な選択肢になります。回線が干渉を受けやすい、あるいはディープパケットインスペクションが存在する環境では、TLS偽装ベースのプロトコル(Trojan、VLESS+TLSなど)の方が安定しますが、ハンドシェイク段階で数十ミリ秒のコストが増えます。パケットロス率が高いネットワーク(基地局の切り替えが頻繁なモバイル回線など)では、QUICベースのプロトコルの方が純粋なTCP方式より再送回復効率が高い傾向があり、予備グループとして採用する価値があります。

mihomoカーネル(Clash Metaブランチ)はプロトコル対応の範囲がより広く、Hysteria2、TUIC、VLESS、Shadowsocks 2022といった比較的新しい実装をカバーしています。サブスクリプションがこれらのプロトコルのノードを提供しているのにクライアントで接続が常に失敗する場合は、まずクライアントに内蔵されているのがmihomoカーネルかどうかを確認してください。オリジナルのClashカーネルはこれらの新しいプロトコルに対応していません。

4つの指標を組み合わせた再現可能なノード選択フロー

レイテンシ、倍率、地域、プロトコルのいずれか1つだけを見ても、ノードの良し悪しを決定するには不十分です。実際の運用では以下の順序で一通り確認し、主観的な感覚を再現可能な判断ステップに置き換えることをおすすめします。

  1. ステップ1:レイテンシで一次選別する。 プロキシグループを開き、全体の速度測定を一度実行し、レイテンシが1000msを超えるまたはタイムアウトを示すノードを除外します。残る候補プールは通常全ノードの3〜5割程度になります。
  2. ステップ2:用途に応じて地域範囲を絞る。 今回解決したいのが「日常アクセスのレイテンシを下げる」ことか「特定地域のコンテンツにアクセスする」ことかを明確にし、用途に応じて候補プールを対応する地域に絞り込みます。
  3. ステップ3:プロトコルとネットワーク環境が合っているか確認する。 現在のネットワークに明らかな干渉や高いパケットロスがある場合は、TLS偽装系またはQUIC系プロトコルのノードを優先して残し、現在の環境で接続失敗を繰り返すプロトコル種別を除外します。
  4. ステップ4:流量予算に応じて倍率の方針を決める。 月間の流量パッケージに余裕があれば倍率を気にする必要はありません。逼迫している場合は低倍率ノードをデフォルトグループに設定し、高倍率ノードは重要なタスク用に残しておきます。
  5. ステップ5:実測ダウンロード速度で最終確認する。 残った2〜3件の候補それぞれでテストファイルを1回ダウンロードし、速度が安定していて変動が小さいものを常用ノードに選びます。レイテンシの数値が最も小さいものを選ぶわけではありません。

このフローを毎日繰り返す必要はありません。サブスクリプションが更新されたときや、明らかにカクつきを感じたときに一通り実行すれば十分です。結果をプロキシグループに固定し、ルールベースの振り分けと組み合わせて異なる種類の通信を適切なグループに自動的に落とし込む方が、毎回手動でノードを切り替えるより手間がかかりません。

よくある誤解とトラブルシューティングの考え方

ノード選択で陥りやすい誤りは、いくつかのタイプに集中しています。

  • レイテンシランキングの1位だけを信じる。 ランキング1位は多くの場合短時間の探測結果であり、継続的な負荷下での実際のパフォーマンスを表すものではありません。前述の実測ダウンロード速度と合わせて判断することをおすすめします。
  • プロキシグループの策略種別を無視する。 プロキシグループ自体にも策略の種類があり、たとえば自動選択グループはレイテンシに応じて自動的に切り替わり、フェイルオーバーグループはノードが失活すると次のノードへ自動的に切り替わります。手動で特定のノードを固定選択したのに常に自動的に切り替えられてしまう場合は、まずこのグループの策略種別を確認してください。何度も手動で選び直す必要はありません。
  • 地域コードを解除の保証だと思い込む。 前述のとおり地域コードはサーバーの設置場所を反映するだけで、実際の解除効果は出口IP帯によって決まります。解除に失敗した場合はまず同じ地域の別のノードに切り替えて試し、いきなりその地域を諦めないようにしましょう。
  • 倍率が低ければ低いほど良いという誤った直感。 低倍率は通常負荷の重さを伴うため、長期的に最低倍率のノードだけを使うとピーク時の混雑に遭遇する回数が増えます。用途に応じてグループを使い分けることをおすすめします。画一的に扱わないようにしましょう。

あるノードが長期間にわたって異常な状態(レイテンシが不安定、頻繁に切断される)を示す場合は、まずノードや回線自体の問題を疑い、同じ地域の別のノードに切り替えて検証してみてください。それでも解決しなければ、ローカルのネットワーク環境やクライアントの設定を確認することを検討しましょう。

Clash クライアントを入手する

ノード選択の方針が決まったら、プロキシグループを正しく認識し、ルールベースの振り分けに対応したクライアントで設定を実際に反映させる必要があります。

ダウンロードセンターへ 入門ガイド →
クライアントをダウンロード