Clashのノード接続タイムアウトを解決

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

Clashクライアントに「タイムアウト」と表示されても、通常はテストが制限時間内に完了しなかったことを示すだけで、ノードが使えないとは限りません。遅延テストでは、選択したノード経由でテストURLにアクセスします。ノードのドメイン名解決、接続先ポートへの接続、プロトコルのハンドシェイク、テストサイトへのアクセスのどこで失敗しても、同じような結果になることがあります。まずエラー内容と影響範囲を記録してから設定を変更すれば、テスト先に接続できないだけなのに全ノードの障害と誤認するのを防げます。

3つのポイントで確認の起点を決める

• 失敗するのが1つのノードだけ：現在の設定はそのままに、同じグループ内の別ノードを選んで同じサイトにアクセスします。接続できるようになった場合は、そのノードの稼働状況や設定を優先して確認してください。
• すべてのノードで失敗する：まずネットワーク、システム時刻、サブスクリプションの有効期限、コアのログを確認します。ノードのポートを一斉に変更するのは避けてください。
• 速度テストは失敗するが、Webページは開ける：テストURLにアクセスできるか、Webページの通信が実際にそのノードを経由しているかを確認します。ブラウザーのキャッシュやDIRECTルールによって、接続できているように見えることもあります。

クライアントの「接続」または「ログ」画面で、新しいリクエストの宛先ドメイン、適用されたルール、実際の接続先を確認します。たとえばWebページへのリクエストが DIRECT にマッチしている場合、正常な直接接続を確認できるだけで、選択中のプロキシノードが使える証拠にはなりません。画面の名称はクライアントによって異なります。以降の手順は、実際の画面と現在のコア設定に合わせてください。

2. プロキシをオフにしてネットワークと時刻を確認する

ほかのプロキシやVPNを終了し、現在のクライアントのシステムプロキシとTUNを一時的にオフにします。ブラウザーに個別のプロキシ設定がある場合は、システム設定を使う状態に戻してください。普段直接アクセスできるサイトを開き、基本のネットワーク接続を確認します。公共Wi-Fiに接続している場合は、先にネットワーク認証を完了してください。直接接続もできない場合は、Wi-Fiやルーター、通信事業者の回線の問題を先に解決します。

基本項目を順番に確認する

1. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを確認します。クライアントを終了した状態で、応答しないローカルポートを指すプロキシ設定が残っていないことを確認してください。
2. 「設定」→「時刻と言語」→「日付と時刻」で時刻を自動的に設定する機能を有効にし、「今すぐ同期」を実行します。タイムゾーン表示だけでなく、実際の日付と時刻も確認してください。
3. macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を確認できます。ネットワークプロキシは「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」にあります。
4. ネットワーク接続が戻ったら、プロキシクライアントは1つだけ起動します。まずシステムプロキシで動作を確認し、正常に使えることを確かめてからTUNを有効にしてください。仮想ネットワークアダプターやルーティングの要因を同時に増やさずに済みます。

TLS証明書には有効期間が定められており、システムの日付がずれているとハンドシェイクに失敗することがあります。一方、時刻同期の仕組みはプロトコルによって異なります。「時刻を同期する」のは基本的な確認事項ですが、あらゆるタイムアウトを解決する方法ではありません。

3. サブスクリプションの期限と設定の更新を確認する

サブスクリプションURLをダウンロードできても、アカウントで通信量が残っていることや、すべてのノードが稼働中であることは保証されません。サブスクリプションサービスのアカウントページで、有効期限、残りのデータ量、メンテナンス情報、クライアントの利用制限を確認してください。アカウントが停止中の場合は、まずアカウントの状態を解決します。DNSを何度変更しても、停止中のサービスは復旧しません。

1. クライアントの「サブスクリプション」または「設定」画面で現在使用中の項目を選び、更新を実行します。最終更新日時と更新結果も確認してください。
2. 更新後の設定が選択され、コアに正常に読み込まれていることを確認します。ダウンロードに成功しても解析に失敗している場合、古い設定のまま動作している可能性があります。
3. ポリシーグループで実際に選択されているノードを確認します。自動選択グループやフェイルオーバーグループでは、現在の接続先が前回手動で選択したノードと異なることがあります。
4. ログに不明なプロキシタイプ、必須項目の欠落、存在しないポリシーグループへの参照が記録されている場合は、まず設定の互換性を確認してください。ネットワークタイムアウトとして扱うべきではありません。

4. ノードのドメイン名と接続先ポートを確認する

サブスクリプションに問題がないことを確認したら、「名前解決できない」ケースと「名前解決はできるがポートに接続できない」ケースを切り分けます。ノードの server と port を確認し、ローカルHTTPプロキシの待ち受けポートと接続先ノードのポートを混同しないでください。以下のコマンドにある example.com と 443 は書式の例です。実行時は使用中のノードのサーバードメイン名とポートに置き換えてください。接続可能なノードの例ではありません。

# Windows PowerShell：先にドメイン名を確認し、次にTCPポートをテスト
Resolve-DnsName example.com
Test-NetConnection -ComputerName example.com -Port 443

# macOS：ドメイン名を確認し、TCP接続をテスト
nslookup example.com
nc -vz -G 5 example.com 443

ドメイン名を解決できない場合は、ノードのドメイン名に誤りがないか、すでに無効になっていないかを確認してから、現在のネットワークのDNSサーバーを調べます。mihomo内蔵DNSを有効にしている場合は、ノードのサーバードメイン名がどの経路で名前解決されるかも確認してください。設定の proxy-server-nameserver でプロキシノードのドメイン名を解決するDNSサーバーを指定できますが、実際のバージョンとDNS設定に応じて判断が必要です。項目をコピーして追加しただけで名前解決が正しくなるわけではありません。

TcpTestSucceeded: True は、TCP接続が1回成功したことを示すだけで、認証やTLS、プロキシプロトコルのハンドシェイクが成功した証明にはなりません。Hysteria2やTUICなどUDPを使うプロトコルは、TCPポートのテストでは利用可否を判断できません。通常の ping はICMPを使用します。サーバーがICMPに応答しなくても、プロキシサービスは正常に動作している場合があります。

スマートフォンのテザリングで比較する

クライアント、サブスクリプション、ノードはそのままにし、PCの接続先だけを現在のWi-Fiからスマートフォンのテザリングに切り替えて、もう一度接続します。テザリングでは正常で、元のネットワークではタイムアウトが続く場合、元のネットワーク経路、UDPの制限、ルーティング設定、または外向き通信のフィルタリングが原因として考えられます。ただし、特定のポートがブロックされているとはまだ断定できません。同じ時間帯のログとサーバーの状態を照らし合わせて判断してください。企業や学校のネットワークでは利用規則を守り、管理されているセキュリティ設定を無断で変更しないでください。

5. コアの互換性とプロトコル設定を確認する

Clashはクライアントのエコシステムやコア設定で広く使われる名称ですが、すべてのコアが同じプロトコルに対応しているわけではありません。Clash Metaはその後、mihomoという名称で開発されています。古いコアでは、新しいプロトコルや設定項目を認識できないことがあります。まず「バージョン情報」、コア情報、起動ログでクライアントとコアのバージョンを記録し、サブスクリプションサービスの要件と照らし合わせてください。画面上のアプリだけを更新して、実際に動作するコアを切り替えていない場合、互換性の問題が残ることがあります。

設定値はサービス提供元から入手した最新の設定に合わせてください。経験だけを頼りにポートを一律 443 に変更したり、トランスポートの種類をむやみに変えたりしないでください。サーバー名とノードの接続先ドメイン名は同じとは限りません。また、server をIPアドレスに変更すると名前解決の動作が変わり、証明書の検証にも影響することがあります。証明書エラーが出た場合は、時刻やサーバー名、サーバー側の証明書を修正し、証明書検証のスキップを安易な対処法にしないでください。

6. ノードに接続できるのにアプリで失敗する場合は通信経路を確認する

内蔵テストには成功するのに、ブラウザーや特定のアプリでタイムアウトする場合は、その通信がクライアントに取り込まれているか、どのルールにマッチしたか、誤ったポリシーグループに送られていないかを確認します。システムプロキシとTUNは異なる通信の取り込み方式です。どちらかを有効にしても、すべてのアプリが想定どおり同じ接続先を使うとは限りません。

まずローカルの待ち受けを確認し、次にルールを確認する

現在の設定に mixed-port: 7890 と明記されている場合、次のコマンドを使うとHTTPSリクエストをローカルHTTPプロキシ経由で送信できます。7890 はこの例で使う値で、すべてのクライアント共通のポートではありません。実際の設定または構成ファイルで待ち受けポートを確認してください。

# Windows PowerShellでは、コマンドの別名による違いを避けるためcurl.exeを使用
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

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

• ローカルポートへの接続が拒否される：コアが動作しているか、待ち受けポートが一致しているか、ほかのプログラムがそのポートを使用していないかを確認します。Windowsでは netstat -ano | findstr :7890 を実行すると、待ち受け状態とPIDを確認できます。
• リクエストはクライアントに届くが、接続先とのハンドシェイクに失敗する：ノードのアドレス、プロトコル設定、接続先ネットワークを確認します。ブラウザーのプロキシ設定を調整し続ける必要はありません。
• リクエストがREJECTにマッチする：ルールの順序と内容を確認します。ルールは上から順に評価され、最初にマッチしたルールで処理が決まります。ノードを変えるだけではなく、ルールを修正してください。
• TUNを有効にした場合だけ失敗する：サービスの権限、仮想ネットワークアダプター、DNSの取り込み、ほかのVPNとのルーティング競合を確認します。まず動作確認済みのシステムプロキシ経由に戻し、その後TUNの機能を1つずつ有効にしてください。

コマンドがHTTPレスポンスを返しても、そのリクエストが完了したことしか分からないため、ログで実際の接続先を確認してください。接続が再利用され、ノードを変更しても古い接続が残ることがあります。ノード変更後は新しいリクエストを送信し、必要な場合だけ該当する古い接続を閉じてください。設定全体を消去する必要はありません。

7. 最小限の再現情報をまとめて問い合わせる

ここまでの確認で原因を特定できない場合は、「タイムアウト」と表示された画面だけを送るより、比較できる記録をまとめると役立ちます。テストでは一度に1つの条件だけを変え、変更前と変更後の結果を記録してください。サブスクリプション、DNS、コア、ネットワークを同時に変更すると、どの変更が効果をもたらしたのか分からなくなります。

1. 環境：OS、クライアントのバージョン、実際に動作しているコアのバージョン、システムプロキシまたはTUNの有効状態。
2. 影響範囲：失敗するのは1つのノードかすべてのノードか、速度テストだけか実際のHTTPSリクエストも失敗するか、特定のアプリに限られるか。
3. 比較結果：同じノードを元のネットワークとスマートフォンのテザリングで試した結果、テスト時刻、失敗した段階。例示された数値を実測結果として扱わないでください。
4. ログ：一時的にログレベルを上げて1回再現し、該当する時間帯のログを抜き出します。個人情報を伏せてから提出し、確認が終わったら通常のログレベルに戻してください。