Clashのノードがタイムアウトして接続できない?この順序で確認すれば原因が見つかる

NT-04.1まずは現象の範囲を見極める、すぐにノードを切り替えない

「ノードがタイムアウトする」というのは大まかな表現で、その裏には全く異なる原因が潜んでいる場合があります。手を動かす前に1分だけ現象の範囲を確認しておくと、無駄な作業をかなり減らせます。ポイントは次の3点です。すべてのノードがタイムアウトしているのか、それとも一部だけか。すべてのソフトが接続できないのか、それともブラウザは繋がるがコマンドラインツールだけ繋がらないのか。遅延テスト(Latency)は数値が表示されるのか、それともそのままタイムアウトの記号が出るのか。

一部のノードだけタイムアウトし、残りは正常であれば、そのノード自体のサーバー側の問題や回線混雑の可能性が高いので、遅延が正常な別のノードに切り替えれば十分で、それ以上深追いする必要はありません。一方、すべてのノードが同時にタイムアウトし、遅延テストの欄が空白のままかタイムアウト表示になる場合は、ローカルネットワーク、サブスクリプションデータ、クライアント設定側に問題があることが多いため、以下の順序で一つずつ確認していきます。

NT-04.2ステップ1:ローカルネットワークとシステムプロキシの設定

確認手順は「近い所から遠い所へ」の原則に沿っています。まず自分の手元で最も検証しやすい部分を確認し、その後サブスクリプションやプロトコルなど、より手間のかかる部分へ進みます。最初のステップは常にローカルネットワーク自体です。

1. デバイス自体がインターネットに正常にアクセスできることを確認します。Clashクライアントのプロキシスイッチを一時的にオフにして、システムのネットワークで直接任意のウェブページを開き、断線やローカルネットワークの障害でないことを確認してください。
2. クライアントのシステムプロキシスイッチがオンになっているか確認します。一部のクライアントは初期設定でシステムプロキシを自動設定しないため、プロキシサービス自体は動いていても実際のトラフィックは経由しておらず、ブラウザのリクエストが直接接続のままになっていることがあります。
3. プロキシモードの設定を確認します。ルールモード(Rule)では、一部の直接接続ルールによってトラフィックがノードを回避することがあります。ルールが原因だと疑われる場合は、一時的にグローバルモード(Global)に切り替えて確認してください。グローバルモードで正常であれば、問題はルール設定側にあり、ノード自体ではないと判断できます。
4. ローカルのファイアウォールやセキュリティソフトがクライアントのネットワークリクエストをブロックしていないか確認します。特に導入直後のウイルス対策ソフトやOS標準ファイアウォールの送信規則には注意してください。

このステップだけで「見せかけのタイムアウト」の多くを排除できます。クライアントは動いていても、トラフィックがそもそもプロキシを経由していないため、遅延テストで正常な結果が出ないだけということが少なくありません。

NT-04.3ステップ2:サブスクリプションがまだ有効か

ローカルネットワークに問題がないことを確認したら、次はサブスクリプション自体を確認します。サブスクリプションリンクが指す先は設定ファイルで、ノード一覧、サーバーアドレス、ポート、認証情報が含まれています。このデータが期限切れや誤っている場合、ノードのサーバー状態とは無関係に、すべてのノードがタイムアウトします。

1. クライアント上に表示されているサブスクリプションの最終更新時刻を確認します。提供元が示す有効期間をすでに超えている場合、この設定は失効している可能性があるため、手動でサブスクリプションを更新してください。
2. サブスクリプションの通信量や有効期限が残っているか確認します。多くのサブスクリプションプランには通信量や期間の上限があり、超過するとサーバー側が新規接続を拒否するため、ノード全滅のタイムアウトとして表れます。
3. クライアントの自動更新に頼らず、サブスクリプションリンクを手動で再インポートしてください。クライアントによっては自動更新の間隔が長いため、手動で強制更新すればすぐに最新設定を取得できます。
4. 設定ファイルの詳細を開き、ノード数と名称が提供元のページに記載された内容と一致しているか確認します。数が急に減ったり名称が文字化けしている場合、サブスクリプションリンク自体に問題が生じていることが多いです。

NT-04.4ステップ3:プロトコル設定とハンドシェイクの詳細

サブスクリプションデータとノード一覧に問題がないことを確認してもタイムアウトが解消しない場合は、プロトコル層の確認に進みます。Clashが対応するノードプロトコル(Shadowsocks、VMess、Trojan、Hysteria2など)はそれぞれ独立したハンドシェイク手順を持ち、どの設定項目でも1つ誤っていると接続確立に失敗します。クライアント側ではまとめてタイムアウトとして表示され、具体的なエラー原因は提示されません。

1. サーバーアドレスとポートが提供元の最新情報と一致しているか確認します。一部のサービス提供者は不定期に出口IPやポートを変更するため、古いキャッシュ設定のまま同期されていないケースがあります。
2. 暗号方式(cipher)や伝送プロトコル(ws、grpc、tcpなど)といった項目がサーバー側の設定と一致しているか確認します。これらのいずれか1つでも合っていないと、ハンドシェイク段階で処理が止まりタイムアウトになります。
3. ノードがTLSやSNI偽装を使用している場合、証明書のドメインとSNI項目が正しく設定されているか確認してください。証明書検証の失敗は、明確な証明書エラーではなく、接続タイムアウトや切断として表れることが多いです。
4. クライアントのログパネル(多くのクライアントでは設定やツールのメニューからリアルタイムログを確認できます)を確認します。ログには dial tcp: i/o timeout や context deadline exceeded といった生のメッセージが記録されていることが多く、画面上の「タイムアウト」アイコンよりも参考になります。

time="2026-07-10T14:02:11+08:00" level=warning msg="[TCP] dial ss-node-hk failed: dial tcp 203.0.113.10:443: i/o timeout"

このようなログが見つかった場合、そのサーバーとのネットワーク到達性、または設定項目の不一致が原因であると考えてほぼ間違いありません。クライアント自体の故障ではないと判断できます。

NT-04.5ステップ4:ポート競合とローカルの衝突

プロトコル設定を確認してもすべてのノードがタイムアウトしたままの場合は、ローカル側のポート競合を確認します。Clashおよびそのコアプログラムは、HTTPプロキシポート、SOCKS5プロキシポート、Mixedポート、コントロールパネルポート(よくある7890、7891、9090など)といった複数のローカルポートを使用します。これらのポートが他のプログラムに使われていたり、システム権限によって遮断されていると、プロキシサービスが実際には正しくリスニングしておらず、結果として接続タイムアウトとして表れます。

1. 別のプロキシソフトやVPNクライアントが同時に動いていないか確認してください。同じポートを取り合っている場合、後から起動した側が静かに失敗することがあります。
2. ポート番号が他のシステムやサービスに占有されていないか確認します。システムのコマンドラインでポート使用状況を確認できます(Windowsは netstat -ano、macOS/Linuxは lsof -i:ポート番号)。リスニングしているプロセスが実際に現在のClashコアであるか確認してください。
3. 最近設定ファイルのポート設定を変更した場合、クライアント画面に表示されているポートと設定ファイル内のポートが一致しているか確認し、一度クライアントを再起動して変更を反映させてください。
4. TUNモードでタイムアウトが発生する場合は、仮想ネットワークアダプタが正常に作成されているか、ルーティングテーブルが他のネットワークツールによって上書きされていないかを追加で確認してください。この部分の確認方法は、サイト内のTUNモード関連チュートリアルも参考にしてください。

NT-04.6ステップ5:ポリシーグループとノード選択のロジック

ここまで進んで前の4項目すべてに問題がなかった場合、最後に見落としがちなのがポリシーグループ(Proxy Group)の選択ロジックです。Clashのポリシーグループは実際のトラフィックがどのノードを通るかを決定するもので、一般的な種類には select(手動選択)、url-test(自動測定による最適選択)、fallback(フェイルオーバー)、load-balance(負荷分散)があります。現在ポリシーグループで選択されているノードがすでに使えないノードだった場合、ブラウジング体験としてはタイムアウトとして表れますが、ノード一覧内の他のノードは正常に測定されるという状態になります。

1. ポリシーグループのパネルを開き、ポリシーグループ名だけでなく、現在実際に有効になっているノードそのものを確認してください。
2. url-test タイプのポリシーグループは設定された測定用アドレスと間隔で自動的に切り替わりますが、その測定用アドレス自体が特定のネットワーク環境で到達不可の場合、自動選択の結果が不正確になることがあります。一時的に手動選択に切り替え、遅延が正常だとわかっているノードと比較してみてください。
3. ルールセットの中で、ドメインやアプリケーションが誤って空の、または失効したポリシーグループに割り当てられていないか確認してください。カスタムルールが多い設定ではよく見られるケースです。
4. 複数のサブスクリプションを結合した設定を使用している場合、ノード名の重複によってポリシーグループが誤ったノードを参照していないか確認してください。

この5つのステップをすべて確認すれば、Clashにおける「ノードタイムアウト」の原因のほとんどをカバーできます。近い所から遠い所へという順序で設計しているのは、無駄な手間を避けるためです。多くの人はまずノードやサブスクリプション提供元を疑いますが、実際にはローカルネットワークの設定やポート競合といったローカル側の問題が意外と多くの割合を占めており、しかもこうした問題は数分で確認・排除できることが多いのです。

NT-04.7確認手順のまとめ

上記の順序で一通り確認しても問題が解決しない場合は、クライアントのログパネルに記録されている生のエラー情報を残しておくことをおすすめします。これは画面上の「タイムアウト」表示よりも具体的で、ネットワーク環境側の問題なのか設定側の問題なのかをさらに特定しやすくなります。