Clashのノードがタイムアウトして接続できないときの対処法

1. ノードの速度テスト失敗と実際の接続失敗を切り分ける

ClashのTimeoutは、処理が制限時間内に完了しなかったことを示すだけで、ノードが使えなくなったとは限りません。ノードの遅延テストでは通常、ノード経由でテスト用URLにリクエストを送り、サーバーまでの通信遅延だけでなく、リクエスト全体の経路を測定します。テスト先に接続できない、名前解決に失敗する、TLSハンドシェイクに問題がある場合も、タイムアウトになることがあります。

この記事では、Clash Verge Revとmihomoコアを例に説明します。まず「プロキシ」画面で現在のモード、対象のプロキシグループ、選択中のノードを確認します。次に「接続」と「ログ」の画面を開き、問題が発生したときの記録を残してください。画面上の名称はバージョンによって異なる場合があります。ポートや設定は、実際に動作している値を確認してください。

特定のノードだけ失敗する場合：そのノードのアドレス、ポート、プロトコル設定、サーバーの稼働状況を確認します。
すべてのノードが失敗する場合：まずローカル側の接続経路、サブスクリプションのアカウント、DNS、現在のネットワークを確認します。すぐに全ノードの設定を変更しないでください。
速度テストは失敗するが、Webサイトは開ける場合：テストURLとタイムアウトのしきい値を確認します。テスト結果の色だけを見てノードを削除しないでください。
速度テストは正常だが、Webサイトが開けない場合：アプリの通信がコアに届いているか、どのルールに一致したか、実際にどのプロキシ経路が選ばれたかを確認します。

2. システムプロキシ、リッスンポート、ローカル側の接続を確認する

アプリからコアへリクエストが渡っているか確認する

まず「設定」で「システムプロキシ」の状態と現在のプロキシポートを確認し、次にOSのネットワーク設定で実際に設定されているアドレスを確認します。Windows 11の場合は、「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」の順に開きます。ローカルプロキシのアドレスは通常127.0.0.1です。ポートはクライアントのリッスンポートと一致している必要があります。

ポートが必ず7890や7897だと思い込まないでください。以下では、現在の設定がmixed-port: 7897の場合を例にします。mixed-portはHTTPとSOCKSの両方を受け付ける混合プロキシの接続口です。Windows PowerShellでは、次のコマンドを実行できます。

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

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

macOSまたはLinuxでは、次のコマンドで同じ接続口を確認できます。設定したポートが異なる場合は、コマンド内の数字を変更してください。

lsof -nP -iTCP:7897 -sTCP:LISTEN
curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

ローカルポートへの接続にすぐ失敗する場合：コアが起動していないか、ポート番号が異なる可能性があります。まずローカルでリッスンできる状態にし、リモートノードの調査はその後に行います。
ログにaddress already in useと表示される場合：ポートが別のプロセスに使用されています。プロセス名を確認し、重複して起動しているプロキシクライアントを終了するか、クライアントのポートを変更してシステムプロキシを再設定してください。
コマンドでは接続できるが、ブラウザーでは使えない場合：ブラウザーのプロキシ拡張機能、個別のプロキシ設定、古い接続のキャッシュを確認します。既存の接続を閉じてから再試行してください。

このcurlコマンドで確認できるのは、リクエストがローカルプロキシに届くことだけです。最終的にルールでリモートノードが選ばれるとは限らず、DIRECTに振り分けられる場合もあります。「接続」画面も併せて確認してください。HTTPレスポンスが返っても、目的のサービスが利用できるとは限りませんが、少なくともリクエストが応答段階まで進んだことは確認できます。

TUNとシステムプロキシを分けて確認する

システムプロキシが影響するのはOSの設定に従うアプリです。一方、TUNは仮想ネットワークアダプターとルーティングを使って通信を取り込みます。TUNを有効にしたときだけ問題が起きる場合は、まず現在の設定を記録してからTUNを無効にし、システムプロキシと前述の明示的なプロキシコマンドで基準となる状態を確認してください。問題がなければ、TUNのサービス権限やルーティング、ほかのVPNとの競合を調べます。

変更前に設定のバックアップを取ってください。調査の代わりにシステムファイアウォールを長期間無効にしたり、用途が分からないまま仮想ネットワークアダプターを削除したりしないでください。企業の管理下にある端末では、ルーティングやセキュリティポリシーについて先に管理者へ確認してください。

3. サブスクリプションの更新、アカウント状態、現在の設定を確認する

「設定」画面を開き、古いローカル設定ではなく、想定したサブスクリプションを使用していることを確認します。そのサブスクリプションを更新し、結果を確認してください。サブスクリプションのダウンロードに成功しても、設定ファイルを取得できたことを示すだけです。アカウントの残り通信量や全ノードの稼働状況、取得した設定が現在有効になっていることまでは保証されません。

プロバイダーのアカウント画面で有効期限、残り通信量、同時接続数の上限を確認します。通信量が表示されない場合は、アカウント画面の情報を優先してください。
更新前後のノード数と名前を比較し、プロバイダーが接続先やプロトコルを変更していないか確認します。
設定が有効化されていることを確認してから、「プロキシ」画面でプロキシグループの選択状態をもう一度確認します。
更新に失敗した場合は、サブスクリプション取得時のHTTPエラー、ダウンロードのタイムアウト、設定の解析エラーを切り分けます。これらをすべてノードのタイムアウトとして扱わないでください。

HTTP 401や403は、認証情報の期限切れ、アクセス制限、アカウント状態などが原因の可能性があります。プロバイダーの案内を確認してください。YAMLの解析エラーは通常、コアが設定を読み込む前に発生します。この場合は速度テストを繰り返すのではなく、サブスクリプションの内容や互換性を修正してください。

4. DNSを確認する：ノードのドメインと接続先のドメインを切り分ける

プロキシ接続では、少なくとも2種類の名前解決が関係する場合があります。1つはノードサーバーのドメイン、もう1つはアクセス先のWebサイトのドメインです。前者の名前解決に失敗すると、コアはリモートサーバーのアドレスを取得できません。後者で失敗した場合は、ノード自体は正常でも特定のWebサイトだけ開けないことがあります。ログに記録された具体的なドメインは、「DNSに問題がある」という情報よりも原因の特定に役立ちます。

まずシステムの名前解決を確認し、次にコアの名前解決を確認する

WindowsではResolve-DnsName example.com、macOSまたはLinuxではnslookup example.comを実行し、システムの名前解決結果を確認します。実際のノードを調べる場合は、サブスクリプションのサーバー項目にあるドメインを使用してください。認証情報を含むサブスクリプションURLをノードのドメインとして使わないでください。

これらのコマンドで確認できるのは、通常、システムの名前解決経路です。mihomo内部のDNSが正常であることを直接証明するものではありません。設定でdns.enableが有効な場合は、実際の設定にあるnameserver、proxy-server-nameserverと関連するポリシーも確認してください。後者はノードのドメインを解決する上流DNSを指定します。DoHを使う場合は、DoHサービスのドメインを最初にどう解決するかも確認が必要です。

ログにlookupまたはno such hostと表示される場合：ドメイン名の入力と上流DNSへの接続を確認し、システム側とコア側のどちらで名前解決に失敗しているかを切り分けます。
名前解決でアドレスが返るのにタイムアウトする場合：そのアドレスとポートへの接続を引き続き確認します。すべてのタイムアウトをDNSの問題と決めつけないでください。
198.18.0.0/16のアドレスが表示される場合：Fake-IPモードでは正常なマッピングの可能性があります。アドレスだけで名前解決のエラーと判断せず、リクエストがコアに取り込まれているか確認してください。

公共DNSのアドレスを大量に一度に追加しないでください。まず現在の設定を残し、使用中のネットワークから上流DNSに接続できるか確認します。DNSリクエストにプロキシが必要で、ノードの起動時にも同じ経路での名前解決が必要な場合、依存関係が循環することがあります。DNSとルールによる振り分けの基本はプロトコルガイドを参照してください。

5. ログの段階から接続が途切れた箇所を特定する

「ログ」画面を開き、再現する前に表示をクリアするか時刻を記録し、リクエストを1回だけ実行します。通常のログだけでは情報が足りない場合は、一時的にログレベルをdebugに変更してください。調査後はinfoに戻し、ログが増え続けないようにします。ログにはアクセス先のドメインやサーバーアドレスが含まれる場合があるため、共有前に伏せてください。

ログの手がかり	考えられる段階	次に行うこと
`connection refused`	接続が明示的に拒否された	エラーに表示されたアドレスを確認します。ローカルアドレスならリッスン状態を、リモートアドレスならサーバーとポートを調べます。
`i/o timeout`	ネットワーク処理がタイムアウトした	前後のログを見て、DNS、TCP、TLS、読み書きのどの段階かを判断します。
`network is unreachable`	ルーティングまたはアドレスファミリー	デフォルトルート、IPv6での到達性、VPNのルートとの競合を確認します。
`x509`関連のエラー	証明書の検証	システム時刻、証明書名、SNI、サーバー側の証明書設定を確認します。
`EOF`または`connection reset`	接続が途中で切断された	プロトコル設定、サーバー側のログ、途中のネットワーク機器を確認します。

エラー1件だけでは、原因の責任箇所を特定できないことがほとんどです。たとえばEOFは、プロトコルの不一致でもリモート側からの切断でも発生します。最後の「リクエスト失敗」ではなく、関連するエラーが最初に現れた箇所を確認してください。設定の読み込み時にすべてのリクエストが失敗する場合は、まず設定エラーを解消してからネットワークを調べます。

6. ノードのプロトコル設定とリモートポートを確認する

ローカル側の接続、サブスクリプション、DNSに問題がない場合は、ノードのserver、port、プロトコルの種類を確認します。TCPポートの疎通確認で分かるのは接続を確立できるかどうかだけで、認証や暗号化、プロキシ転送が成功することまでは証明できません。WindowsではTest-NetConnectionに実際のサーバーとポートを指定してTCP接続をテストできます。UDPプロトコルの判断に同じテスト結果は使えません。

Shadowsocks：暗号化方式、パスワード、プラグインの要件を確認します。方式名はサーバー側の設定と一致している必要があります。
VMess / VLESS：UUID、転送方式、TLS関連の設定を確認します。VLESSのflowなどの項目はサーバー側の設定と一致させてください。
TLS / WebSocket：SNI、Host、パスを確認します。サーバーへの接続アドレス、TLS名、HTTP Hostが異なる場合もあります。すべてを同じIPアドレスに変更しないでください。
REALITY：プロバイダーから提供された公開鍵、short-id、server-nameなどの設定を確認します。サーバーアドレスだけをコピーしても接続できるとは限りません。
Hysteria2 / TUIC：通常はUDPを使用します。同じネットワーク上でTCPのノードは使えるのにこれらのノードが失敗する場合は、ネットワークでUDPが制限されていないか、端末のセキュリティポリシーが通信をブロックしていないか確認します。

証明書エラーが出た場合は、まずシステムの日付、時刻、タイムゾーンを合わせ、サーバー証明書と名前が一致しているか確認します。証明書検証のスキップを恒久的な対処にするのは避けてください。設定にコアがサポートしていない項目が含まれる場合は、クライアントとコアの実際のバージョンを記録し、プロバイダーの要件に沿って互換性を確認します。画面に表示されたクライアントのバージョン番号だけで、すべてのプロトコルに対応しているかを判断しないでください。

7. ルールの適用結果と比較テストを確認する

最後に「接続」画面に戻り、対象のWebサイトを開いて、適用されたルール、プロキシグループ、最終的に選ばれたノードを確認します。Ruleモードでは、一部のリクエストがDIRECTになるのは想定どおりの場合があります。REJECTはルールによる拒否を示し、ノードのタイムアウトではありません。プロキシグループの中に自動選択グループが含まれることもあるため、外側のグループを選んだだけでは特定のノードに固定されません。

変更範囲を広げず、最小限の条件で比較する

同じノードと接続先に固定して、システムプロキシと明示的なプロキシリクエストを比較し、アプリの通信が取り込まれているか確認します。
利用規約とネットワークポリシーに従える環境で、現在のネットワークとスマートフォンのテザリングを比較します。一方のネットワークだけで失敗する場合は、そのネットワークのDNS、ポート、UDPの制限を優先して確認してください。
ネットワークを変えずに、正常に動作することが分かっている別のノードに切り替えます。1つのノードだけ失敗する場合は、そのノードと発生時刻をプロバイダーに連絡してください。
ルールの影響を一時的に切り分けるためにGlobalモードを使う場合は、テスト後に元のモードへ戻し、接続経路を改めて確認してください。

サポートへ問い合わせる際は、OS、クライアント、コアの各バージョン、発生日時とタイムゾーン、ノードのプロトコル、TUNの使用有無、個人情報を伏せたログ、2組の比較テスト結果を伝えてください。すべて赤く表示された速度テストのスクリーンショットだけでは、どの段階でリクエストが失敗したのか分かりません。