Clash ノードタイムアウトで接続できない場合の切り分け手順と対処法

ノードタイムアウトや接続不能は、Clash およびその派生コア（Clash Meta、mihomo）を使う上で最も頻発するトラブルですが、同じ症状の裏には全く異なる原因が潜んでいることが多くあります。サブスクリプション自体が失効している場合もあれば、ノードのサーバー側が一時的に不安定になっている場合、あるいはローカルのネットワーク設定が競合している場合もあります。手当たり次第に原因を推測すると時間を浪費しやすいため、外側から内側へと決まった順序で切り分けていくことが、問題の特定を早める近道です。本記事の切り分け順序は「まずデータの出所が正常かを確認し、次にソフトウェアが正常に動作しているかを確認し、最後にシステム環境がプロキシ通信を許可しているかを確認する」という原則に基づいています。

切り分け前の基本的な見極め

具体的な手順に入る前に、まず障害の範囲を把握しておきます。クライアントを開き、接続失敗時のエラー表示と影響範囲を観察することで、切り分けの方向性を絞り込めます。

• すべてのノードが接続できない：サブスクリプション、システムプロキシ、ファイアウォールといった全体的な問題である可能性が高いです。
• 一部のノードだけ接続できず、他は正常：ノードのサーバー側自体の問題、あるいは遅延テストの結果自体が異常である可能性が高いです。
• 以前は使えていたのに突然すべて使えなくなった：まずサブスクリプションの期限切れやトラフィック使い切りを確認し、次に新しくインストールしたソフトがポートを占有していないかを確認します。
• 新しいデバイスや新しいOSに移行後に接続できない：まずシステムプロキシとファイアウォールの設定を確認します。新しい環境で最も抜けやすい設定です。

この初期判断を終えたら、以下の5つの手順を順番に確認していきます。多くの場合、2〜4番目の手順の間に具体的な原因が特定できます。

手順1：サブスクリプションが有効かを確認する

サブスクリプションの失効は、ノードが一斉にタイムアウトする最も一般的な原因ですが、見落とされやすいポイントでもあります。クライアント画面上ではノード一覧が表示されたままでも、その裏側のサービス自体が応答を停止していることがあるためです。サブスクリプションの有効性は、以下の観点から確認できます。

1. 有効期限と残りトラフィックを確認する：多くのサブスクリプション提供元はリンクや管理パネルに有効期限と残量情報を用意しており、クライアントのサブスクリプション管理画面でもこれらの情報を確認できます。期限切れやトラフィック使い切りになっていないか確認しましょう。
2. 手動でサブスクリプションを更新する：クライアントのサブスクリプション一覧で手動更新を実行します（更新アイコンや「サブスクリプションを更新」ボタンが一般的です）。更新に失敗しネットワークエラーやリンク無効の表示が出る場合、サブスクリプションのリンク自体に問題があります。
3. 更新日時が異常でないか確認する：自動更新の日時が長期間前のまま止まっている場合、ネットワークの問題で定期更新が失敗し続けている可能性があり、ノード一覧が実際には古いキャッシュデータのままになっていることを示します。
4. サブスクリプションリンクが途切れていないか確認する：手動でリンクを取り込む際、コピー＆ペーストの過程でリンク末尾のパラメータが欠落しやすく、内容が不完全なリンクになってしまうことがあります。リンクを丸ごと再度コピーし直すのが、この可能性を排除する最も簡単な方法です。

手順2：ノードの遅延をテストする

サブスクリプションが有効であることを確認したら、次に具体的にどのノードで問題が発生しているかを判断します。Clash クライアントには通常、ノード一覧の横に遅延テスト機能が用意されており、クリックすると各ノードに対してネットワーク探査を行い、往復時間（ミリ秒）を表示します。テスト結果を見る際は、以下のケースを区別してください。

• 具体的なミリ秒数が表示される（例：80ms）：そのノードは現在通信可能であり、タイムアウトの原因はそのノードにはありません。システム側の原因の切り分けを続けましょう。
• タイムアウトまたは無応答と表示される：ノードのサーバー側が現在利用不可であることを示します。サーバーメンテナンス、回線の不安定化、あるいはそのノードが広範囲で規制されている可能性があります。同じグループ内の別ノードへの切り替えを試してください。
• すべてのノードでタイムアウトが表示される：遅延テスト自体もネットワーク接続に依存しています。テストリクエストすら送信できない場合、問題はノードのサーバー側ではなくローカルのネットワーク環境にある可能性が高く、以降のポート、システムプロキシ、ファイアウォールの切り分けに進むべきです。

遅延テストのURLは通常設定で変更できます。デフォルトのテスト先が現在のネットワーク環境からそもそも到達不可能な場合（例えば特定のサイトがデフォルトで使われている場合など）、テスト結果全体が異常になることがあります。テスト先アドレスを別のものに変更して再テストし、テスト経路自体の問題を排除してみてください。

特定のノードだけ長期的に高遅延、あるいは頻繁にタイムアウトし、同じサブスクリプション内の他のノードは正常な場合、通常はそのノードの回線品質の問題です。そのノードだけを何度も切り分けるより、素直に別のノードに切り替えるのが最も直接的な解決策です。

手順3：ポート競合を確認する

遅延テストすら完了しない場合、次に Clash が使用するローカルポートが他のプログラムに占有されていないかを確認します。Clash コアは起動時に、プロキシ要求を受け付けるための一連のローカルポートをリスンします。HTTPプロキシポート、SOCKS5プロキシポート、混合ポート（mixed-port）などが代表的です。これらのポートが他のプログラムに既に占有されていると、コアが正常にリスンを開始できず、すべてのトラフィックが転送不能になります。

ポート競合の確認は、以下の方法で行えます。

1. クライアントのログパネルを開き、コア起動時に「ポートが既に使用されています」「bind: address already in use」のようなエラーが出ていないか確認します。
2. システムのコマンドラインでポートの使用状況を調べます。Windowsではコマンドラインツールで指定ポートに対応するプロセスを確認できます。

netstat -ano | findstr 7890

macOS と Linux では以下のコマンドを使用できます。

lsof -i :7890

3. 他のプログラムが Clash に必要なポートを占有していることが分かった場合、そのプログラムを終了するか、クライアントの設定で Clash が使用するポート番号を変更して競合を避けます。
4. ポート番号を変更した後は、設定を反映させるためコアを再起動する必要があります。またシステムプロキシ設定に記録されているポート番号も同期して更新されているか確認してください。両者が一致していないと、システムプロキシが誰もリスンしていないポートを指し続けることになります。

手順4：システムプロキシの状態を確認する

ポートが正常にリスンしているにもかかわらず、ブラウザなどのアプリケーションがプロキシ経由でネットワークにアクセスできない場合、システムプロキシが本当に有効になっているかを確認する必要があります。システムプロキシは、どのアプリケーションのトラフィックを Clash に処理させるかを決定する設定です。この層の設定が誤っていると、ノードとポートが正常でもトラフィックが Clash を経由しません。

• クライアント内のシステムプロキシスイッチを確認する：クライアント設定内の「システムプロキシとして設定」またはそれに類する項目がオンになっているか確認します。一部のクライアントは再起動後にこのスイッチの状態を自動的に復元しないため、手動で再度オンにする必要があります。
• OSのプロキシ設定を確認する：システムのネットワーク設定でプロキシアドレスとポートが、クライアントが現在使用しているポートと一致しているか確認します。特にポート番号を手動で変更した後は、システム側のプロキシ設定が自動的に同期されない場合があります。
• システムプロキシとTUNモードを区別する：システムプロキシはシステムプロキシ設定に従うアプリケーションにのみ有効です。コマンドラインツールや一部のゲーム、バックグラウンドサービスはシステムプロキシ設定を読み込まないことがあり、この場合はシステムプロキシがオンになっていても、これらのアプリケーションは接続不能と表示され続けます。システムプロキシ層での切り分けを続けるのではなく、TUNモードに切り替えてすべてのトラフィックを引き受ける必要があります。
• ブラウザやアプリ自体のプロキシ設定：一部のブラウザにはシステムプロキシとは独立したネットワーク設定項目があります。ブラウザ側で「システムプロキシを使用しない」と設定されている場合、システムプロキシが正常に動作していても、そのブラウザは Clash 経由でネットワークにアクセスできません。

この層に問題がないかを確認する簡単な方法は、クライアントの接続ログやトラフィックパネルを開き、リアルタイムの接続記録が発生しているかを観察することです。ブラウジングを開始してもパネルに新しい接続が全く現れない場合、トラフィックが Clash に入っていないことがほぼ確定し、原因はシステムプロキシ設定の層にあります。

手順5：ファイアウォールによる遮断を確認する

システムプロキシの設定に問題がないと確認でき、トラフィックが Clash に入っているにもかかわらずタイムアウトが報告される場合、最後にファイアウォールやセキュリティソフトが Clash のネットワークアクセスを遮断していないかを確認します。この現象は新規セットアップしたOS、企業管理下のPC、あるいはセキュリティソフトを更新した直後に特によく見られます。

1. OS標準のファイアウォールを確認する：Clash 本体とそのコアプロセスが、ファイアウォールの受信・送信ルールで許可されているか確認します。初回起動時に遮断された場合、OSが通常許可の確認ダイアログを表示するので、拒否ではなく許可を選択する必要があります。
2. サードパーティ製セキュリティソフトを確認する：一部のセキュリティソフトは、プロキシ系ツールをリスクのあるプログラムと判定し、明確な通知なしにネットワークリクエストを静かに遮断することがあります。この場合、セキュリティソフトのログやホワイトリスト設定で Clash の実行ファイルを手動で追加登録する必要があります。
3. ルーターやゲートウェイ側の制限を確認する：家庭用ルーターや社内ネットワークのゲートウェイ層でポート制限やプロトコル識別が行われている場合があります。端末側のすべての切り分け手順が正常なのに接続できない場合は、別のネットワーク環境（例：スマートフォンのテザリング）に切り替えて比較テストを行い、問題範囲を絞り込むことができます。
4. ノードが使用する通信プロトコルが特定的に規制されていないか確認する：一部のネットワーク環境では特定のプロトコルの特徴を識別して妨害することがあります。同じサブスクリプション内で特定のプロトコル種別のノードが全般的にタイムアウトし、別のプロトコル種別のノードは正常な場合、ネットワーク環境が特定のプロトコルを規制していることを示します。正常に動作するプロトコル種別のノードを優先的に選択してください。

それでも解決しない場合の追加チェック

以上の5つの手順を試しても問題が解決しない場合、以下の追加チェックを行ってみてください。比較的稀ですが、実際に接続失敗を引き起こすケースをカバーしています。

• 設定ファイル内のルール競合：カスタムルールセットを設定している場合、本来プロキシ経由にすべきトラフィックが誤って直接接続グループに振り分けられていないか、あるいはプロキシグループのセレクター設定に誤りがあり、実際に選択されているノードと画面表示が一致していないかを確認します。
• DNS解析の異常：プロキシ接続自体は正常でも、DNS解析に問題があるとブラウザはアクセス不能と報告します。設定内のDNS項目を確認するか、fake-ipモードに切り替えて、DNS解析が原因の見かけ上の接続失敗かどうかを切り分けてみてください。
• コアのバージョンと設定形式の不一致：クライアントやコアのバージョンを更新した後、古い設定ファイルのフィールドが変更または廃止されている場合があります。ログに設定解析関連の警告やエラーが出ていないか確認してください。
• システム時刻のずれ：一部のノードの暗号化プロトコルはシステム時刻のずれに敏感で、システム時刻と実際の時刻の差が大きいとハンドシェイクに失敗し、接続タイムアウトとして現れることがあります。システム時刻を確認・校正することで、このケースを排除できます。

これら5つの手順と追加チェックを順番に試せば、ほとんどのノードタイムアウトの問題は、いずれかの段階で明確な原因が見つかります。まずログを確認し、それから段階的に切り分けるという習慣をつけることが、ソフトウェアの再起動やノードの変更を繰り返すよりも、安定して問題を解決する近道です。