Clashのノードがタイムアウトして接続できないときの対処法｜サブスクリプションからDNSまで順番に確認

速度テストのタイムアウトと実際の接続失敗を切り分ける

Clashクライアントに「Timeout」と表示される場合、通常はテストリクエストが制限時間内に完了しなかったことを意味します。サーバーが必ずオフラインというわけではありません。テスト先に接続できない、DNSクエリに失敗する、ノードの認証情報が無効になっているなど、複数の原因で同じような結果になります。反対に、速度テストで遅延が表示されても、その時点でテストリクエストが成功したことを示すだけです。すべてのWebサイト、UDP通信、アプリが正常に使えるとは限りません。

原因の切り分けでは、設定の取得、ローカルの待ち受け、名前解決、ノードとのハンドシェイク、ルール選択のどの段階で失敗したかを確認します。まず現在の設定とログを保存し、ノード、接続先サイト、接続方式をそれぞれ一つに固定してください。サブスクリプションの更新、DNSの変更、TUNの有効化を同時に行うと、どの変更が有効だったのか判断できません。

最小限のテスト記録を作る

• 環境：OS、Clashクライアントのバージョン、カーネルのバージョンを記録し、Wi-Fi、モバイル回線、有線LANのどれを使っているかも残します。画面のバージョンとmihomoカーネルのバージョンは分けて記録してください。
• 設定：現在のProfile名、サブスクリプションの最終更新成功日時、プロキシモード、選択中のノードを記録します。
• 症状：「すべてのノードがタイムアウト」「特定のノードだけ失敗」「速度テストは成功するがブラウザーは失敗」「ブラウザーは使えるが特定のアプリは失敗」のように分けて記録します。
• 時刻：たとえば14:30:00にリクエストを実行し、その前後30秒のログを保存します。これは記録方法の例であり、テスト結果を示すものではありません。

手順1：サブスクリプションの有効性と設定の反映を確認する

サブスクリプションURLは設定を取得するためのもので、ノードへの接続そのものではありません。更新が成功しても、ノードが使えるとは限りません。取得した設定に有効期限切れのアカウント情報が含まれている場合や、提供元が回線をメンテナンスしている場合があります。Clashクライアントの設定一覧を開き、現在有効なProfileを確認してから、その設定を更新し、結果と更新日時を確認してください。

1. アカウントの状態を確認する。サブスクリプション提供元のアカウントページで、有効期限、残りの通信量、デバイスの利用制限を確認します。通信量の超過やアカウントの停止が原因なら、ローカルのポートを変更しても解決しません。
2. サブスクリプションの応答を確認する。HTTP 401または403は通常、認証やアクセス制限に関係します。404はURLの無効化、429はリクエスト制限を示す場合があります。設定データではなくログインページが返された場合、それをYAMLとして読み込まないでください。
3. 読み込み結果を確認する。更新後にノード一覧が想定どおり変化したかを確認し、YAMLの構文エラー、未知のフィールド、未対応プロトコルの警告がないか調べます。更新に失敗しても、以前の設定を保持し続けるClashクライアントもあります。
4. 最終的に適用された設定を確認する。設定のマージ、オーバーライド、スクリプトによって、ポート、DNS、ルールが変更されることがあります。その後の確認はサブスクリプションの元データだけでなく、実際に読み込まれた設定に基づいて行ってください。

すべてのノードが失敗する場合と一部だけ失敗する場合

特定のノードだけ失敗する場合は、まず同じプロキシグループの別ノードを選んで再テストし、失敗するノードのサーバーアドレス、ポート、認証情報を確認します。すべてのノードが失敗する場合は、共通の依存要素であるローカルネットワーク、システム時刻、DNS、ローカルカーネルを優先して確認してください。複数のノードが実際には同じサーバードメイン名を使っている場合、同じ名前解決エラーの影響を受けることもあります。

リモートのルールセットやプロキシプロバイダーは、rule-providersやproxy-providersで個別に取得する場合があります。メインのサブスクリプションを更新できても、これらのリソースのダウンロードに成功したとは限りません。ログでリソースのダウンロードエラーを確認してください。特に、リソース取得にはプロキシが必要なのに、起動時点で利用可能なプロキシがないという依存関係に注意が必要です。

手順2：システム時刻を合わせ、基本的なネットワーク接続を確認する

システムの日付や時刻が大きくずれていると、TLS証明書の有効期間を正しく判定できず、時刻に依存する認証処理にも影響する場合があります。この種のエラーは、ノードとのハンドシェイク時にもサブスクリプションのダウンロード時にも発生します。タスクバーの時刻だけでなく、年月日と実際の時刻を確認してください。

• Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。「時計を同期する」で「今すぐ同期」を実行してください。
• macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にします。項目名はシステムのバージョンによって多少異なる場合があります。
• Linux：timedatectl statusで時刻と同期状態を確認します。systemdを使用し、時刻同期に対応しているシステムでは、sudo timedatectl set-ntp trueで同期を有効にできます。

ClashクライアントのシステムプロキシとTUNを一時的に無効にし、現在のネットワークから直接アクセスできるWebサイトを開いて、基本的な接続を確認します。公共Wi-Fiでログインが必要な場合は、先に認証を済ませてください。ネットワーク自体に接続できない状態でプロキシルールを変更しても、原因の切り分けが難しくなるだけです。

別のネットワークと比較する

同じデバイスと設定で、元のネットワークとスマートフォンのテザリングをそれぞれ使ってテストします。元のネットワークだけで失敗する場合は、そのネットワークのDNS、外部接続の制限、ファイアウォールが原因である可能性が高くなります。両方で失敗する場合は、デバイスや設定を確認してください。この比較で原因の範囲は絞れますが、特定のブロック方式を証明できるわけではありません。

pingに応答がないことだけでは、ノードがオフラインである証拠にはなりません。サーバーがICMPに応答しない場合があるためです。ノードがTCP、UDPなど別の通信方式を使っている場合は、実際のプロトコルの接続ログも確認してください。

手順3：プロキシポートと接続経路を確認する

ブラウザーがローカルプロキシに接続できない問題と、リモートノードがタイムアウトする問題は別です。前者は、カーネルが起動していない、待ち受けポートが使用中、システムプロキシが古いポートを参照しているといった原因がよくあります。現在有効な設定でmixed-portを確認するか、portとsocks-portをそれぞれ確認してください。以下では混合ポート7890を例にします。これはあくまで例なので、実際に待ち受けているポートに置き換えてください。

待ち受けプロセスを確認する

WindowsではPowerShellで次のコマンドを実行し、出力のOwningProcessからプロセスを調べて、想定したカーネルが待ち受けているか確認します。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890 -State Listen).OwningProcess

macOSではlsof、Linuxではssを使えます。権限が不足していると、プロセス情報を確認できない場合があります。

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

待ち受けが確認できない場合は、まずカーネルの起動ログを調べます。address already in useと表示されたら、同じポートを使用している古いプロセスを終了するか、現在のClashクライアントの待ち受けポートを変更してください。見慣れないシステムプロセスを安易に終了せず、名前と提供元を確認してください。変更後はシステムプロキシのアドレスも確認します。更新しないと、ブラウザーが古いポートに接続し続けることがあります。

明示的なプロキシ接続テスト：システムプロキシ設定を経由しない

次のコマンドはローカルのHTTPプロキシを直接指定し、待ち受けポート、プロキシ経由の転送、接続先へのリクエストが通るかを確認します。Windowsでは、PowerShell環境によってcurlが別のコマンドとして解釈されることがあるため、curl.exeを使ってください。macOSとLinuxではコマンド名をcurlに置き換えられます。

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

• すぐに接続拒否される：最初にノードを変更するのではなく、ローカルの待ち受けアドレス、ポート、カーネルの状態を確認します。
• HTTPレスポンスが返る：このリクエストが完了したことを示します。それでもブラウザーが失敗する場合は、システムプロキシ、ブラウザーのプロキシ設定、拡張機能を確認してください。
• しばらく待ってタイムアウトする：同じ時刻のログを確認し、ノードサーバーへの接続失敗、TLSハンドシェイクの失敗、接続先サイトの応答タイムアウトを切り分けます。

ここでの10秒は接続段階の上限、20秒はリクエスト全体の上限であり、遅延の測定値ではありません。テスト結果は現在のルールにも左右されます。接続先がDIRECTに一致した場合、確認できるのは直接接続の経路だけです。特定のノードを検証するには、対象のプロキシグループを一時的に選び、接続履歴を確認してください。テスト後は元のモードに戻します。

手順4：実際のDNS経路に沿って名前解決を確認する

DNSの問題は、少なくとも二つに分けて確認する必要があります。ノードサーバーのドメイン名を解決できるか、接続先サイトのドメイン名を解決できるかです。前者に失敗するとノードへの接続自体を確立できません。後者に失敗すると、ノードの速度テストは正常でも特定のサイトにアクセスできないことがあります。ログにあるno such host、DNSクエリのタイムアウト、リゾルバーへの接続失敗は、画面に一律で表示される「タイムアウト」より原因の特定に役立ちます。

まずOSの名前解決を確認し、次にカーネル側の名前解決を確認する

# Windows PowerShell：システムDNSの応答を確認
Resolve-DnsName example.com

# 一般的なデスクトップOSで使える基本的な名前解決テスト
nslookup example.com

例のドメイン名を、ログで実際に失敗しているドメイン名に置き換えてください。OSの名前解決が成功しても、Clashクライアントのカーネルが使うリゾルバーも成功するとは限りません。カーネル独自のDNS、TUNによるDNS制御、アプリ側の暗号化DNSを使っている場合は、名前解決の経路が異なることがあります。有効な設定のdns.enable、nameserverとログを照らし合わせて確認してください。

これらのフィールドが使える範囲や動作はカーネルのバージョンによって異なります。変更前に該当バージョンのドキュメントを確認してください。未対応の古いカーネルにmihomoの設定をそのまま適用しないでください。複数のパブリックDNSを一度に設定しただけで解決したと判断するのも避けましょう。リゾルバーへの接続性、振り分け方針、初期DNSによる名前解決をそれぞれ確認する必要があります。

Fake-IPアドレスはノードサーバーのアドレスではない

Fake-IPを有効にすると、DNSの応答として設定済みのマッピング用アドレス範囲（例：198.18.0.0/16）が返されることがあります。これはドメイン名と接続を関連付けるための内部マッピングです。このようなアドレスが表示されても、DNSが汚染されているとは限りません。重要なのは、その後の接続が同じカーネルに戻り、ドメイン名が正しく復元されることです。

DNSモードを切り替えた後もアプリが古いキャッシュを使っている場合は、まず対象アプリを再起動し、必要に応じてOSの方法でDNSキャッシュを消去してください。Windowsではipconfig /flushdnsを実行できますが、ブラウザー独自のキャッシュやカーネルのマッピングは自動で消去されません。Fake-IPと実際に互換性のないLANサービスについては、ログを確認して対象を絞り、fake-ip-filterを設定できます。すべてのドメインを先に除外する必要はありません。

手順5：ルールの適用先とプロキシグループの選択を確認する

ノードに遅延が表示されるのにWebページを開けない場合、想定したノードをリクエストが通っていないことがよくあります。ルールモードでは設定順にルールが適用されます。ドメインルール、IPルール、プロセスルール、最後のフォールバックルールによって、リクエストごとに異なるポリシーが選ばれる場合があります。Clashクライアントの接続履歴を開き、接続先ドメイン、一致したルール、最終的なポリシー経路、実際の出力ノードを確認してください。

1. ノードを固定する。手動選択のプロキシグループでノードを指定し、切り分け中に自動テストグループが出口を切り替えないようにします。
2. 接続をやり直す。古いタブを閉じるか、アプリを再起動してから再テストします。既存の長時間接続は、ポリシーを切り替えてもすぐに新しいノードへ移行するとは限りません。
3. DIRECTとREJECTを確認する。リクエストが直接接続または拒否のルールに一致している場合、プロキシノードを変更しても結果は変わりません。先に該当するルールを確認してください。
4. 一時的にグローバルモードと比較する。グローバルモードでも、テスト対象のノードが選択されていることを確認してください。グローバルモードでは使えてルールモードで失敗する場合は、ルールとプロキシグループを重点的に確認します。テスト後はルールモードに戻してください。

グローバルモードでも、すべてのアプリが自動的にプロキシ経由になるわけではありません。システムプロキシだけを有効にしている場合、システムプロキシに従わないアプリは直接接続することがあります。明示的なプロキシコマンドでは接続できるのに、ゲーム、コマンドラインツール、メッセージアプリなど特定のアプリで失敗する場合は、そのアプリがHTTP/SOCKSプロキシに対応しているかを確認してからTUNの使用を検討してください。

TUNとUDPは個別に確認する

TUNはシステムのIPトラフィックを仮想ネットワークインターフェースに渡して処理します。そのため、適切な権限、ルーティング、DNS制御の設定が必要です。ブラウザーでは接続できるのにTUNでは失敗する場合は、サービスのインストール状態、管理者権限、仮想インターフェース、ほかのVPNとのルート競合を確認してください。すべてをノードの障害と決めつけないでください。

HTTPSのWebテストで主に確認できるのはTCP経路であり、UDPが使えることの証明にはなりません。ゲーム、音声通話、一部のQUIC接続では、ノードのプロトコル対応、サーバー側の転送機能、ローカルネットワークの状態も関係します。対象アプリごとにテストし、UDP関連のログも確認してください。設定でUDPを有効にしただけでは、UDP転送に対応していないサーバーで利用できるようにはなりません。

最後に、ログからハンドシェイクとサーバーの問題を特定する

サブスクリプション、時刻、ポート、DNS、ルールを確認した後で、ノードとのハンドシェイクやサーバー側の問題を調べます。一時的にログレベルをdebugに変更して一度再現し、確認後は通常のレベルに戻してください。ログの開き方はClashクライアントによって異なります。決まった保存先を推測せず、まずログ画面でエクスポート機能を探してください。

ポート、パスワード、UUID、SNI、WebSocketパス、Realityパラメーターなど、サーバー側との整合が必要な項目は、サブスクリプション提供元の有効な設定に従ってください。項目を一つでもむやみに変更すると、正常に使えていたノードがハンドシェイクできなくなることがあります。2つのネットワークで特定のノードだけが常に失敗し、ほかのノードは正常な場合は、まず使えるノードに切り替え、提供元に不具合を報告してください。

問い合わせ時に残しておく4つの情報

• OS、Clashクライアント、カーネルの正確なバージョンと、障害が始まった時刻。
• すべてのノードで失敗するか一部だけか、システムプロキシとTUNのどちらで問題が起きるか。
• 明示的なプロキシ接続テストの結果、適用されたルール、ネットワークを変えたときの比較結果。
• 「Timeout」と表示された画面だけでなく、失敗したリクエスト前後の機密情報を伏せたログ。

設定の読み込みや接続手順を確認したい場合は利用ガイドをご覧ください。DNS、ルール、TUNのパラメーターについては詳細設定ガイドを参照してください。一度に変更する項目は一つに絞り、元に戻せるよう設定を保存しておくと、何度も再インストールするより原因を特定しやすくなります。