ClashでChatGPTがタイムアウトする？接続を直す設定ガイド2026

まず確認：タイムアウトはノード障害だけが原因ではない

Clash経由でChatGPTを開いたときに、ページが読み込み中のまま止まる、ログイン画面へ進まない、または「接続がタイムアウトしました」と表示される場合があります。この症状は、利用中のノードが停止している場合だけでなく、Clashの動作モード、ルールの判定、DNS、システムプロキシ、TUNの経路が一致していない場合にも発生します。

特にChatGPTは、単一のドメインだけへ接続するサービスではありません。画面表示にはchatgpt.comやopenai.com、ログインや認証には関連する認証ドメイン、会話の更新には長時間接続やストリーミング通信が使われます。そのため、トップページだけをDIRECTにしても、ログイン後のAPI通信や認証用リクエストが別のルールで処理されると、画面の一部だけが止まることがあります。

症状	優先して確認する場所	最初に行う操作
ページ自体が開かない	システムプロキシ、Clashの待受ポート、現在のノード	プロキシを一度切り替え、`https://example.com`を開く
ログイン画面で止まる	認証関連ドメインのルール、Cookie、DNS	ブラウザーのプライベートウィンドウで再試行する
会話一覧は見えるが返信が終わらない	ノードの長時間接続、ルール、接続の安定性	別地域のノードへ変更して新しい会話を送る
ブラウザーは動くがアプリやAPIが失敗する	アプリごとのプロキシ設定、TUN、HTTPS_PROXY	Clashの接続ログで対象ドメインの経路を見る

Clashの稼働状態とポートを確認する

最初に確認するのは、クライアントの画面で「起動しているように見えるか」ではなく、Mihomoなどのコアが実際に待受を開始しているかです。Clash Verge Rev、Clash for Android、Mihomo系クライアントでは、サイドバーの「設定」「一般」「ポート」などに、HTTP、SOCKS、混合ポートの項目があります。クライアントによって表記は異なりますが、現在のポート番号とコアの稼働状態を確認できます。

代表的な設定では、mixed-port: 7890がHTTPとSOCKS5の両方を受け付けます。古い設定ではport: 7890とsocks-port: 7891を分けることもあります。ここで表示されるポートは端末上のローカル入口であり、リモートノードのポートではありません。ブラウザーやコマンドラインから127.0.0.1へ接続できなければ、ノードを変更しても通信は改善しません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-portは、Clashが端末上で待ち受けるHTTP・SOCKS共通ポートです。
allow-lan: falseは、同一LAN上のほかの端末から管理せず、自分の端末だけで利用する基本設定です。
mode: ruleでは、ルールに従ってDIRECT、REJECT、プロキシグループを選択します。
log-level: infoは通常運用に適したログ量です。障害を再現するときだけ短時間debugへ変更します。

設定を編集した後は、必ずクライアントの「設定を適用」「再起動」「Reload」などの操作を実行します。ファイルを保存しただけでは、現在動作中のコアへ反映されないことがあります。また、別のアプリが7890番ポートを使用している場合、Clashの起動ログにポート競合が記録されます。ログにaddress already in useやbind: permission deniedがあれば、ポート番号と権限を先に直してください。

動作モードとChatGPT向けルールを見直す

ChatGPTの接続確認では、まず「Rule」モードを使い、対象通信がどの出口へ送られているかを確認します。「Global」モードでプロキシグループを固定すると、原因の切り分けは簡単になりますが、すべての通信が同じノードへ送られます。一方、「Direct」モードではノードが正常でもChatGPTへの接続はプロキシを経由しません。

ルールモードでChatGPTがタイムアウトする場合は、Clashの「接続」「Connections」「ログ」画面を開き、chatgpt.com、openai.com、認証関連のホスト名がDIRECTやREJECTになっていないかを確認します。対象の通信が意図したプロキシグループへ入り、実際に選択されたノード名が表示されていることが重要です。

rules:
  - DOMAIN-SUFFIX,chatgpt.com,AI
  - DOMAIN-SUFFIX,openai.com,AI
  - DOMAIN-SUFFIX,oaistatic.com,AI
  - DOMAIN-SUFFIX,oaiusercontent.com,AI
  - MATCH,DIRECT

上の例では、先にAIグループへ振り分け、どのルールにも一致しない通信は最後のMATCH,DIRECTへ送ります。実際に必要なドメインはサービスの構成や時期、クライアントの機能によって変わるため、すべての認証ドメインを推測して追加するのではなく、ログに現れたホスト名と利用中のルールセットを照合してください。ルールは上から順に評価されるため、広すぎるDOMAIN-SUFFIX,com,DIRECTのような項目が前にあると、後ろのプロキシルールへ到達しません。

手を動かして切り分ける：5分で行う確認手順

ここでは設定を大きく変更せず、ブラウザーとClashのログを使って原因を絞り込みます。作業中は動画再生や大容量ダウンロードを停止し、テストする通信を一つにしてください。クライアントの表示名は異なる場合がありますが、考え方はClash Verge、Clash Verge Rev、ClashX、MihomoのGUIで共通します。

Clashのコアが起動していること、待受ポートが7890など現在の表示と一致していることを確認します。
システムプロキシを一度有効にし、ブラウザーでhttps://example.comを開きます。これも失敗するなら、ChatGPT固有の問題ではありません。
「接続」または「ログ」を開き、example.com:443がDIRECTかプロキシのどちらで処理されたかを確認します。
プロキシグループを手動選択に変更し、現在のノードとは異なる地域のノードを一つだけ選びます。url-testの結果だけでなく、実際の接続結果も比較します。
ブラウザーのプライベートウィンドウでhttps://chatgpt.comを開き、ログイン前のページが表示されるか確認します。
ログ画面でchatgpt.comとopenai.comのルール、ポリシーグループ、実ノード名を記録します。
ログイン後に新しい短いメッセージを一度だけ送信し、返信ストリームが始まる前後のログを確認します。

端末からローカルプロキシを直接検証する場合は、HTTP混合ポートを明示して次のコマンドを実行できます。-Iはヘッダーだけを取得するため、通常のページ全体をダウンロードするよりテスト通信量を抑えられます。

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

example.comは成功し、ChatGPTだけが失敗するなら、ChatGPT関連のルール、ノードの出口、TLSまたはサービス側の応答を確認します。両方が失敗するなら、システムプロキシ、Clashの待受、ノード接続のいずれかが共通原因です。コマンドの結果がCould not resolve hostならDNS、Connection refusedならローカルポート、Operation timed outなら出口または経路を優先して調べます。

DNSとTUNモードを調整する

ChatGPTだけが開かないとき、DNSの名前解決がプロキシ経路と一致していないケースがあります。システムDNSで名前を解決し、通信だけを別のノードへ送る構成では、地域やネットワーク環境によって誤った応答、遅延、接続先の不一致が起きることがあります。Mihomoではdns設定、Fake-IP、保留中のDNSリクエスト、DNSモードなどが関係します。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://8.8.8.8/dns-query

この例をそのまま使用するのではなく、現在のコアが対応するフィールドと、ネットワーク環境の要件を確認してください。DNSサーバーへ到達できない環境でDoHだけを指定すると、名前解決自体がタイムアウトします。まずログにDNSエラーがあるかを確認し、DNS変更後は既存の接続を閉じてからブラウザーを再起動します。

TUNモードを使っている場合は、システムプロキシとは別の経路で通信が取り込まれます。TUNを有効にした状態でさらにシステムプロキシも有効にすると、アプリによっては二重処理、ループ、仮想NICの競合が発生します。問題の切り分けでは、最初にTUNを無効にしてシステムプロキシだけでChatGPTを確認し、次にシステムプロキシを無効にしてTUNだけで比較します。

ブラウザーだけを検証する場合は、システムプロキシ単独から始めます。
システムプロキシを使わないアプリも対象にする場合は、TUNを検討します。
VPN、仮想マシン、Docker、企業ネットワークを併用する場合は、TUNのルート競合を確認します。
TUNでDNS hijackやFake-IPを使う場合は、ブラウザーのDNSキャッシュを消去して再接続します。

ログから最後の原因を特定し、修復後に再テストする

ログでは、エラーの最後の一行だけで判断しないでください。ChatGPTへの接続は、DNS解決、ルール判定、プロキシグループ選択、ノードへのTCP接続、TLSハンドシェイク、HTTPS通信という順番で進みます。どこまで進んだかによって対策が変わります。

ログの例	考えられる原因	対処
`DNS resolution failed`	DNSサーバー、Fake-IP、DNS経路	DNS設定と名前解決のログを確認する
`connection refused`	ローカルポートまたはノード側ポートの拒否	待受ポートとノード状態を確認する
`i/o timeout`	出口ノード、経路混雑、接続先からの応答遅延	別ノードで比較し、同じ失敗が続くか調べる
`tls handshake timeout`	TLS経路、MTU、ノード品質、干渉	別地域のノードとTUN無効状態で再試行する
`using DIRECT`または`REJECT`	ルールが意図した出口と異なる	ルールの順番とグループ名を見直す

修復後は、ブラウザーのタブを再読み込みするだけでなく、Clashの接続一覧から古い接続を閉じ、プライベートウィンドウでログイン前のページ、ログイン、短いメッセージ送信の順に確認します。ノードを切り替えた場合、既存のWebSocketやストリーミング接続は古い出口に残ることがあるため、新しい接続を作り直す必要があります。

検証が終わったら、ログレベルをdebugからinfoへ戻し、使わないシステムプロキシやTUNを無効にします。設定ファイルを変更した場合は、YAMLのインデント、グループ名、ルールで参照するポリシー名が一致しているか確認してください。最後に、ChatGPT以外の一般サイト、通常のDNS、普段使うアプリも確認し、必要以上にすべての通信をAI用ノードへ固定していないことを確かめると、日常利用時の遅延や接続不安定を抑えられます。