Clashの全ノードがタイムアウトするときの原因と対処法｜サブスクリプション・時刻・ポートの確認手順

速度テストの失敗と実際の接続障害を切り分ける

Clashクライアントで表示される「タイムアウト」は、リクエストが所定の時間内に完了しなかったことを示します。サブスクリプションが無効になったとは限りません。遅延テストでは、指定したノード経由でテスト先にアクセスします。ノードとのハンドシェイク、名前解決、テストサイトの応答のいずれかに失敗すると、タイムアウトになることがあります。Clashはクライアント群を指す一般的な呼称で、画面や機能は利用中のクライアントと実行カーネルによって異なります。mihomoは、Clash Metaの名称を使った設定説明でもよく登場します。

まず障害の範囲を記録します。全ノードの速度テストが失敗するのか、特定のプロキシグループだけなのか。速度テストは失敗してもウェブページは開けるのか、それともプロキシ経由の通信がすべて失敗するのか。設定更新後に発生したのか、Wi-Fiの切り替え後なのか。何度も速度テストを繰り返すより、こうした情報を残すほうが原因究明に役立ちます。

一括速度テストを中断し、ノードを1つ手動で選択します。ルールモードの場合は、対象の通信がそのノードを含むプロキシグループに振り分けられていることを確認してください。
クライアントの「接続」と「ログ」画面を開き、利用可能と分かっているHTTPSサイトにアクセスします。同じ時刻の宛先、適用されたルール、エラーを記録してください。
ウェブページにアクセスできるのに速度テストがすべて失敗する場合は、クライアントを再インストールする前に、テスト先、タイムアウト時間、同時実行数を確認します。

手順1：ローカルネットワークとサブスクリプションを確認

まずログイン認証とネットワーク切り替えを確認

システムプロキシとTUNを一時的に無効にし、通常の直接接続でウェブサイトを開けるか確認します。ホテル、学校、公共のWi-Fiでは、先にブラウザーで認証が必要な場合があります。認証が済んでいないと、Wi-Fiのアイコンが正常でもノード接続がすべて失敗することがあります。比較用にスマートフォンのテザリングも試してください。設定、ノード、宛先は同じまま、接続先ネットワークだけを切り替えます。テザリングでは接続でき、元のネットワークではできない場合は、元のネットワークのDNS、外向き通信の制限、ルーターを引き続き確認します。

サブスクリプションの更新成功は、サービスが現在も使えることを意味しない

アカウントの状態：サービス提供元のページで、有効期限、残りデータ量、デバイス数や同時接続数の制限を確認します。ページに表示される時刻のタイムゾーンにも注意してください。
更新結果：サブスクリプションの更新履歴とノード数を確認します。HTTP 401や403は認証情報またはアクセス制限、429はリクエスト頻度の制限を示すことがあります。詳しい原因はサービス側のメッセージも確認してください。
設定の読み込み：ダウンロードに成功しても、ファイルを取得できただけです。新しい設定が現在有効になっているか、設定項目のエラーでカーネルが読み込みを拒否していないかを確認してください。
ノードの接続先：複数地域のノードが同じ入口ドメインを共有している場合があります。「全ノードがタイムアウト」していても、すべてのサーバーが同時に故障したのではなく、共通の入口に障害が起きている可能性があります。

サブスクリプションの更新にプロキシが必要な場合、回線が使えなくなると更新も繰り返し失敗することがあります。サービス提供元が対応しているネットワークから更新するか、提供されているローカル設定のインポート方法を利用してください。サブスクリプションURLには通常、アクセス情報が含まれます。公開の速度テストサイト、変換サービス、掲示板などには貼り付けないでください。

手順2：システム時刻を合わせ、ハンドシェイクの条件を確認

TLS証明書の有効期間の確認や、一部プロトコルの認証にはシステム時刻が使われます。スリープ復帰後に時計がずれたり、日付を誤って手動設定したりすると、複数のノードが同時に接続できなくなることがあります。タスクバーの時刻だけでなく、日付、年、タイムゾーン、自動同期の結果も確認してください。

Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。タイムゾーンを確認してから、「今すぐ同期」をクリックしてください。
macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にします。システムのバージョンによって、項目名が多少異なる場合があります。
Linux：timedatectl statusを実行し、システム時刻の同期状態を確認します。systemdを使用する環境では、各システムの運用方針に従って時刻同期サービスを有効にしてください。

たとえば、ログにx509: certificate has expired or is not yet validと表示される場合は、まずシステム時刻を信頼できる時刻情報と照合します。時刻を合わせても同じエラーが出る場合に、サーバー証明書を確認してください。証明書検証を無効にして問題を隠さないでください。skip-cert-verifyを設定しても、誤ったパスワード、接続できないポート、プロトコル設定の不一致は解決しません。

手順3：カーネルの起動とポート競合を確認

ノード一覧が表示されていても、プロキシカーネルが正常に動作しているとは限りません。GUIが設定を読み込めていても、起動時のポート競合によってカーネルが終了している場合があります。まずクライアントのログで、起動失敗、設定の解析エラー、address already in useを探し、実際に待ち受けているポートを確認してください。

以下ではローカルの混合プロキシポート7890を例にします。これはサンプル値で、すべてのクライアントに共通する設定ではありません。まずクライアントのポート設定または適用中の設定から、mixed-port、port、socks-portの値を確認してください。コントロール用インターフェースには9090が使われる場合もあります。これはカーネルの管理用で、ブラウザーのHTTPプロキシポートには指定しません。

7890を使用しているプロセスを確認

Windowsでは、PowerShellで待ち受けアドレスとプロセスIDを確認し、該当するプログラムを特定できます。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

2つ目のコマンドにある1234は説明用の値です。1つ目のコマンドで実際に返されたプロセスIDに置き換えてください。macOSや一般的なLinuxでは、次のコマンドを使用できます。

lsof -nP -iTCP:7890 -sTCP:LISTEN

別のプロキシクライアントがポートを使用している場合は、先にそのソフトを通常の方法で終了してから、現在のクライアントを起動します。用途が分からないシステムプロセスを強制終了しないでください。ポートを7891に変更した場合は、アプリ側の手動プロキシ設定も同じ値に変更します。通常は自分の端末だけで使うため、ループバックアドレスでの待ち受けを維持してください。トラブルシューティングのためにLANからのアクセスを有効にする必要はありません。

手順4：プロキシを明示したリクエストで原因を絞り込む

TUNを一時的に無効にし、ノードを1つ手動で選択します。ローカルプロキシのアドレスを明示してリクエストを送ると、アプリがシステムプロキシに従っているかどうかという不確定要素を避けられます。ただし、リクエストはカーネルの現在のモードとルールの影響を受けます。テスト中は接続パネルを開き、通信がルールによってDIRECTに振り分けられていないことを確認してください。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null --write-out "%{http_code}\n" \
  https://cp.cloudflare.com/generate_204

このコマンドはmacOSまたはLinuxのシェル向けです。Windows PowerShellでは、curl.exeを明示して次の1行を実行できます。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output NUL --write-out "%{http_code}\n" https://cp.cloudflare.com/generate_204

204が返る：このリクエストでは、ローカルプロキシ経由で宛先へのアクセスに成功しています。接続パネルで実際のポリシーと出口も確認してください。
すぐに接続が拒否される：まずローカルポート、待ち受けアドレス、カーネルプロセスを確認します。ローカル接続が確立した後に拒否される場合もあるため、ログを確認して発生箇所を特定してください。
待機後にタイムアウトする：リモート接続、DNS、ハンドシェイク、テスト先を確認します。curlの結果だけで、特定のプロトコル障害と判断しないでください。

テスト先への通信が特定の回線で制限される場合もあるため、利用可能と分かっている別のHTTPSサイトでも検証してください。テストのタイムアウトが1,000ミリ秒なら、一時的に5,000ミリ秒へ延ばし、順番に2回テストできます。これはトラブルシューティングの例で、推奨値を一律に示すものではありません。タイムアウトを延ばしても待ち時間が増えるだけで、認証エラーや使えない入口は直りません。

手順5：ログのキーワードからDNS・認証・プロトコルを特定

ログレベルを一時的にinfoに設定し、情報が足りない場合に限ってdebugを使います。リクエストを1回だけ再現し、時刻を手がかりに関連ログを絞り込んでください。確認後はログレベルを元に戻し、大量のログが出続けないようにします。ログを共有する前に、サブスクリプションURL、パスワード、トークンなどのアカウント情報を削除してください。

ログの手がかり	優先して確認する項目	次に行うこと
`lookup`、`no such host`	ノードの入口ドメインまたは宛先ドメインの名前解決に失敗	どちらのドメインの名前解決かを切り分け、DNSの上流サーバーに到達できるか、ノードのドメインが有効かを確認します。
`i/o timeout`、`context deadline exceeded`	接続またはリクエストがタイムアウト	前後のログからDNS、TCP、TLSなどの段階を特定し、ネットワークを切り替えて比較します。
`connection refused`	宛先のポートが接続を受け付けない	拒否されたのがローカルかリモートかを確認し、ポート設定とサービスの状態を調べます。
`authentication failed`	認証情報またはプロトコル設定が一致しない	元のサブスクリプションを更新して認証情報を確認します。ノードの表示名だけを手動で変更しても解決しません。
`TLS handshake`、`x509`	時刻、証明書、SNI、またはハンドシェイク経路	まず時刻を合わせ、設定したサーバー名とサービス側の要件を確認します。
`unsupported`、`unknown proxy type`	カーネルがプロトコルまたは設定項目に対応していない	実際に動作しているカーネルの種類とバージョンを確認し、サブスクリプションに対応したクライアントを使います。

入口の名前解決と宛先の名前解決は別の処理

ノードサーバーのドメインが正しく名前解決されて初めて、カーネルは入口に接続できます。一方、ブラウザーで開くサイトのドメインは、その後の宛先の名前解決にあたります。この2つは異なる経路で名前解決されることがあります。ノードの入口の名前解決に失敗している場合、サイトの振り分けルールを何度も変更しても解決にはつながりません。nslookupで自分の入口ドメインを調べられますが、システムからの名前解決に成功しても、カーネルのDNS設定が正常だとは限りません。

mihomoのDNS設定では、nameserver、default-nameserver、proxy-server-nameserverが関係することがあります。実際の対応範囲は、使用中のカーネルのドキュメントを確認してください。まだ接続できないプロキシにすべてのDNSリクエストを無理に送ると、名前解決と接続が互いに依存するループが発生することがあります。

プロトコル設定は関連項目をまとめて確認

古いClashカーネルの機能範囲を、mihomoと同じだと考えないでください。Hysteria2などを含む設定を使う場合は、実行中のカーネルがそのプロトコルに対応しているか確認します。UDPベースの通信は、現在のネットワークで制限されている場合もあります。TCP系ノードは使えるのにUDP系ノードがすべて失敗するなら、パスワードをむやみに変更するより、テザリングで比較するほうが原因究明に役立ちます。サーバーポート、認証、SNI、通信方式などは元のサブスクリプションを基準にしてください。設定の変換時に項目が抜けることがあります。

手順6：基本のプロキシ接続を復旧してからTUNとルールを確認

プロキシを明示したリクエストが成功し、TUNを有効にしたときだけ失敗する場合は、ルーティング、権限、DNSの制御、他の仮想ネットワークアダプターを確認します。TUNはシステムのネットワーク通信を取り込む機能で、ノードへの接続性を高めるスイッチではありません。期限切れのアカウントを復旧したり、サーバーの誤ったポートを修正したりする機能もありません。

ほかのVPN、プロキシクライアント、ルートを書き換える可能性のあるソフトを終了し、複数の通信制御機能が同時に動作しないようにします。
クライアントの要件に従ってサービスモードやシステム権限を確認し、接続ログを残したままTUNだけを有効にします。
DNSリクエストが正しく取り込まれているか、プロキシサーバー自身への接続が誤って再びトンネルに送られていないかを確認します。
TUN使用時に一部のHTTPSサイトだけが止まる場合は、パスMTUなども確認します。現在の値を記録してから1項目ずつテストし、すべてのタイムアウトに対する最初の対策としてMTUを変更しないでください。

ルールモードでは、実際に選択されているプロキシグループも確認してください。selectグループが別の自動選択グループを選び、その自動選択グループが古いテスト結果を使っている場合があります。具体的なノードを直接選び、接続経路を確認すると、グループの入れ子による判断の曖昧さを減らせます。一時的にグローバルモードに切り替えて比較する方法もありますが、他のアプリの通信経路を変えないよう、テスト後は元のモードに戻してください。

調査結果の記録と設定の復元手順

障害が解決しないとき、「全ノードがタイムアウト」とだけ伝えても原因を特定するのは困難です。以下の情報をまとめておくと、サービス提供元に入口の状態を確認したり、クライアントの開発者にカーネルやシステムの通信制御の問題を判断してもらったりする際に役立ちます。

OSのバージョン、クライアントのバージョン、実際に使われているカーネルの名称とバージョン。本体の「バージョン情報」または起動ログから確認します。
障害の発生時刻と、その前にサブスクリプションの更新、OSのアップグレード、ネットワークの切り替え、TUNの有効化を行ったかどうか。
同じノードを元のネットワークとスマートフォンのテザリングで試した結果、およびプロキシを明示したリクエストの結果。
エラーの前後が分かる、個人情報を削除したログ。対象リクエストの時刻、TUNの使用有無、実際に適用されたプロキシグループも記載します。

復旧時は、まず1つのノードを使い、プロキシを明示したリクエストを成功させます。次にシステムプロキシを確認し、必要な場合に限ってTUNと自動選択グループを有効にしてください。「ローカルネットワークとアカウント → システム時刻 → カーネルとポート → DNSとハンドシェイク → 通信制御とルール」の順に確認すると、入口の障害、テストの誤判定、端末側の設定問題を切り分けられます。対応クライアントを選び直す場合はClashクライアントダウンロードセンターをご覧ください。インポート方法と基本設定は使い方ガイドで確認できます。