Clashのノードがすべてtimeoutになる場合の切り分け手順｜ローカルネットワークからサーバーまで

1. 遅延テストの失敗と実際のプロキシ接続障害を切り分ける

timeoutは、処理が制限時間内に完了しなかったことを示します。「サーバーが停止している」と断定できるものではありません。クライアントの遅延テストでは通常、ノード経由で指定されたHTTPまたはHTTPSのURLにアクセスします。ドメイン名の解決、サーバーへの接続、プロトコルのハンドシェイク、テストサイトへのアクセスのいずれかが滞ると、タイムアウトになることがあります。

まずノード、テストURL、アプリをそれぞれ1つに絞ります。数十件の接続が同時に始まらないよう、一括テストはいったん停止してください。クライアント名、コア名とバージョン、接続中のネットワーク、テスト時刻、ログに記録された最初のエラーを控えます。以降は、1回のテストで変更する条件を1つだけにします。

2. ローカルネットワーク：回線、認証、残存プロキシを確認する

直接接続できる状態に戻す

1. 変更前の設定を記録します。クライアントのシステムプロキシとTUNモードをオフにし、ほかのVPN、通信最適化ツール、プロキシアプリも終了します。
2. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシや自動構成スクリプトが残っていないか確認します。組織の管理下にある端末では、設定を勝手に削除せず、管理者に相談してください。
3. macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開き、HTTP、HTTPS、SOCKSプロキシが終了済みのローカルアプリを参照していないか確認します。
4. ホテル、学校、公共のWi-Fiに接続している場合は、まずネットワーク認証を完了します。ブラウザーにログイン画面が表示されたら、ノード設定を変更する前に認証を済ませてください。

クライアントを終了しただけでは、システムプロキシが解除されないことがあります。システムの接続先が127.0.0.1:7890のままで、そのポートを待ち受けるプロセスがすでに存在しない場合、ブラウザーは接続できません。これはローカルの接続入口で起きている問題で、リモートノードにはまだ到達していません。

プロキシを明示的に迂回してリクエストを確認する

Windows PowerShellではcurl.exeを使用し、旧バージョンのPowerShellで同名コマンドに別名が割り当てられる影響を避けます。次のリクエストは明示的なプロキシを迂回し、接続タイムアウトを5秒、全体の制限時間を15秒に設定します。これらは切り分け用の設定例であり、実測結果ではありません。

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://www.example.com/

macOSとLinuxでは同じオプションを使い、コマンド名をcurlにします。例のドメイン名はリクエスト方法を示すためのものです。現在のネットワークから直接接続できると分かっているサイトに置き換えてください。TUN、透過型ゲートウェイ、上位の透過プロキシが動作している場合、--noproxyではネットワーク層による制御を迂回できません。

直接接続も失敗する場合は、まずネットワークアダプターのIPアドレス、デフォルトゲートウェイ、ルーターの接続状態を確認します。次に同じPCをスマートフォンのテザリングにつないで再テストしてください。テザリングでは成功し、元のネットワークでは失敗する場合、元のネットワークのDNS、経路、アクセス制限に原因がある可能性が高まります。ただし、これだけで特定のポートが遮断されているとは断定できません。

3. システム時刻とDNS：ドメイン名と証明書を確認する

システム時刻を合わせる

TLS証明書の検証には現在時刻が使われ、一部のプロキシ認証にも時刻が関係します。Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、自動設定を有効にして時刻を同期します。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を確認します。

タイムゾーン表示だけでなく、日付、年、実際の時刻も確認します。ログにcertificate has expiredまたはcertificate is not yet validと記録されている場合は、ローカルの時計とリモートの証明書を両方確認してください。証明書検証を無効にして回避するのは避けましょう。

ノードのドメインとテスト先のドメインを分けて確認する

• ノードのドメインを名前解決できない：コアがサーバーのアドレスを取得できず、プロキシ接続を開始できません。
• テスト先のドメインを名前解決できない：サーバーに接続できていても、指定されたテストリクエストが完了しない場合があります。
• コアとシステムで名前解決の結果が異なる：システムで問い合わせに成功しても、コアに設定されたDNSの上流が正常とは限りません。

まずログを見て、どのドメインの名前解決に失敗したか特定します。WindowsではResolve-DnsName www.example.com、macOSまたはLinuxではnslookup www.example.comを実行し、例のドメインをログに記録された接続先に置き換えてください。システムからの問い合わせ結果は比較材料にすぎません。コア側でDNS resolve failed、上流への接続タイムアウト、名前解決のループが記録されていないかも確認します。

4. テストURL：数値だけでなくリクエスト先を確認する

クライアントで現在使われているテストURLを確認します。画面上の設定から指定されている場合もあれば、設定内のurl-testプロキシグループやproxy-providersのヘルスチェックで指定されている場合もあります。これらが同じURLを使うとは限りません。画面上の設定を変更しても、バックグラウンドのヘルスチェックが古いURLにアクセスし続けることがあります。

応答が簡潔で、URLが安定しており、現在の回線からアクセスできるHTTPSの接続先を選びます。204を返すURLは疎通確認によく使われますが、「204が返らない」ケースをすべてノード障害と判断してはいけません。リダイレクト、認証画面、サイト側のアクセス制限、クライアントのステータスコード判定方法も結果に影響します。

同じ接続先に対して2種類のリクエストを行う

以下ではローカルのHTTPプロキシポートを使って、例のURLにアクセスします。7890はあくまで例です。実際にクライアントがHTTPまたはmixedで待ち受けているポートに置き換えてください。現在のルールでこのリクエストがテスト対象のノードに送られることも確認します。そうでなければ、リクエストに成功してもDIRECTが選ばれているだけかもしれません。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://www.example.com/

1. 同じ接続先に対して直接接続とプロキシ経由のリクエストをそれぞれ実行し、エラーメッセージを保存します。
2. クライアントの接続ログで、接続先ドメイン、適用されたルール、最終的に選択されたアウトバウンドノードを確認します。
3. テスト先だけが失敗する場合は、ノードを変えずに、利用できると分かっている別の接続先で試します。
4. 5秒のテストでは失敗し、15秒以内ならリクエストが完了する場合は、応答の遅さを示す手掛かりとして記録し、ハンドシェイクやパケットロスを調べます。タイムアウト値を際限なく延ばすだけでは解決になりません。

curl -IはHEADリクエストを使いますが、一部のクライアントはGETで疎通を確認します。接続先がHEADに対応していない場合は-Iを外し、-o NUL（Windows）または-o /dev/null（macOS、Linux）を指定してレスポンス本文を破棄してください。比較するときはリクエストメソッドをそろえます。

5. ローカルポート、ルール、TUN：通信がテスト対象のノードを通っているか確認する

まず明示的なプロキシ入口を1つ検証する

Windowsでは次のコマンドで、例のポートが待ち受けているか確認できます。結果が表示されない場合は、クライアントのコアが起動しているか、設定の読み込みに成功しているか、ポートを別のプログラムが使用していないかを確認してください。

Get-NetTCPConnection -State Listen -LocalPort 7890

macOSではlsof -nP -iTCP:7890 -sTCP:LISTEN、Linuxではss -lntpを使って待ち受け状態を確認できます。ポートが存在するだけでは不十分です。現在のクライアントのコアが所有していることも確認してください。HTTPプロキシのリクエストをコントローラーのポートに送らないでください。コントローラーはプロキシ通信の入口ではありません。

接続ログで適用されたルールを確認する

• ルールモード：接続先に適用されたルールとプロキシグループを確認し、最終的な経路がDIRECT、REJECT、別のノードになっていないことを確かめます。
• 自動選択グループ：切り分け中は特定のノードを固定し、テスト中の自動切り替えで結果が混在しないようにします。
• チェーンプロキシ：途中のどこか1段でも失敗すると、最終リクエストがタイムアウトすることがあります。まず1段の接続に簡略化して比較してください。

明示的なHTTPプロキシでは正常で、TUNを有効にしたときだけ失敗する場合は、ルーティング、DNS制御、権限、ほかのVPNとの競合を重点的に確認します。TUNは通信がコアに入る経路を変える機能であり、誤ったパスワードやリモートポートへの接続不能を解決するものではありません。まずログと設定のコピーを保存し、項目ごとに確認してください。デフォルトルートを制御するツールを複数同時に有効にするのは避けましょう。

ゲーム、音声通話、QUICだけが失敗する場合は、UDPへの対応を個別に確認します。ブラウザーからTCPで接続できても、ノードのプロトコル、サーバー、ローカルネットワークがUDPを許可しているとは限りません。アプリのQUICを一時的に無効にして復旧した場合も、UDP経路に問題がある可能性を示す手掛かりにとどまります。

6. プロトコル設定とリモートサーバー：到達性からハンドシェイクまで順に確認する

使用中のコアがノードのプロトコルに対応しているか確認する

Clashの設定形式が似ていても、すべてのコアが同じプロトコルや項目に対応しているとは限りません。mihomo用の設定を使う場合は、クライアント画面のバージョンだけでなく、実際に動作しているコアの名前とバージョンを記録してください。ログに未対応のプロキシタイプ、未知の項目、設定の解析エラーがある場合は、ネットワーク速度を測る前に互換性の問題を解消します。

信頼できる配布元から元のサブスクリプションを再取得し、アカウントの通信量、期限、ノード一覧に変更がないか確認します。server、port、プロトコルの種類、認証項目を1つずつ確認してください。TLSまたはWebSocketを使う場合は、servername、パス、Hostも確認します。REALITYを使う場合は、公開鍵やshort IDなど、サービス提供元が指定した項目も照合してください。

これらの設定値をドメイン名の見た目から推測してはいけません。ノードのドメインをIPアドレスに直接変更すると、TLS SNI、証明書検証、サーバー側の振り分け結果が変わることがあります。TCP接続が成功しても、プロトコル全体が確立したとは限りません。

ポート確認の結果は一部の証拠として扱う

WindowsではTest-NetConnectionを使い、サーバーのTCPポートを確認できます。次の変数を設定ファイルに記載された実際のサーバーアドレスとポートに置き換えてから実行してください。例の443がすべてのノードに共通するわけではありません。

$server = Read-Host "ノードのserverアドレスを入力"
$port = [int](Read-Host "ノードのportを入力（例：443）")
Test-NetConnection -ComputerName $server -Port $port

• TCP接続に成功：TCP接続が確立できることを示すだけで、認証、TLS、WebSocket、プロキシ転送の成功までは証明しません。
• TCP接続に失敗：ルーティング、アクセス制限、サーバーの待ち受け状態、アドレスの誤りなどが考えられます。1回の結果だけで原因の所在を断定することはできません。
• UDPプロトコル：Hysteria2やTUICなど、UDPを使う接続の利用可否は、TCPポートの確認結果では判断できません。
• pingに失敗：接続先がICMPに応答しない可能性があります。その結果だけでプロキシのポートが使えないとは判断できません。

同じノードが独立した2つのネットワークで失敗し、設定値とアカウントの状態も確認済みの場合は、サービス提供元に連絡して、待ち受けポート、ファイアウォール、証明書、サーバーの稼働状況を確認してください。複数のノードが同じ入口ドメインや中継経路を共有している場合、すべてのノードが失敗しても、共通の依存先に原因があり、各サーバーが同時に故障したとは限りません。

7. ログで原因を絞る：全ノードが赤い画面だけでなく最初のエラーを確認する

ログレベルを一時的にdebugに上げ、古い記録を消してから失敗を1回だけ再現します。リクエスト開始からエラーまでの前後関係を確認し、接続先ドメイン、選択されたノード、名前解決の結果、ハンドシェイクの段階を見ます。切り分けが終わったらログレベルを元に戻し、記録が大量に生成され続けないようにしてください。

1回の切り分けで確認する項目

1. プロキシをオフにし、ローカルから直接接続できるか確認した。
2. ノードを1つに固定し、実際のアクセスと遅延テストをそれぞれ確認した。
3. システム時刻、ノードのドメイン解決、ローカルの待ち受けポートを確認した。
4. 接続ログで適用ルールと最終的なアウトバウンドを確認した。
5. 別のネットワークで比較した、または比較できない理由を記録した。
6. 失敗した段階を特定し、機密情報を削除したログをまとめた。

この順番で確認すれば、「全ノードがtimeoutになる」問題を、ローカルの接続入口、DNS、テスト先、プロトコルのハンドシェイク、リモート経路のいずれかに絞り込めます。設定用語を確認するには用語クイックガイドを、システムプロキシやルール設定を引き続き確認するにはトラブル対処ガイドをご覧ください。