トラブル対処 読了時間 約8分

Clash ノードがタイムアウトして接続できない時の調べ方:サブスク・ポート・プロトコルの確認順序

ノード全滅は必ずしもノード故障ではありません。サブスク有効性・ポート占有・システムプロキシ設定・プロトコルとコアの対応・DNS汚染の5段階を順に確認し、設定の問題か経路の問題かを特定して対処法を示します。

確認前に問題の範囲を見極める

遅延欄が「timeout」ばかりになっていると、まずノードの故障やサブスクの期限切れを疑いがちですが、それは数ある原因のひとつにすぎません。実際にはローカル環境側の問題であることが多く、ポートが占有されている、システムプロキシが有効になっていない、コアのバージョンとプロトコルが噛み合っていない、DNS解決が汚染されている、といったケースです。これらは遅延テストを一括で失敗させるため「ノード全滅」とほぼ同じ見え方になりますが、ノード自体には何の問題もありません。

まずは最小限の切り分けをおすすめします。システムのブラウザで海外サイトに直接アクセスし、繋がらずかつプロキシを経由している様子もなければ、経路そのものが通っていない可能性が高いです。一方、クライアント画面では「接続済み」と表示されているのにページが読み込まれない場合は、下の各段階を順に確認していきます。すぐにサブスクを変更したりノードを削除したりするのは避けてください。単純な問題をこじらせるだけです。

第1段階:サブスクの有効性確認

サブスクリンク自体が失効しているケースは特に見落とされがちで、無料プランや更新切れのサブスクでよく起こります。確認方法は簡単です。

  • クライアント上で「サブスクを更新」を手動で実行し、ノード数の変化やエラー表示が出るか確認する。
  • サブスクリンクをブラウザのアドレスバーに貼って直接アクセスし、空のテキストや404、エラーJSONが返ってくる場合は、サーバー側が失効していることを示しており、ローカル設定の問題ではない。
  • サブスクの有効期限と残り通信量を確認する。多くのパネルはこの2項目を Subscription-Userinfo レスポンスヘッダーに含めており、クライアント画面上に表示される。

サブスクが実際に失効している場合、以降の段階をいくら確認しても結果は出ません。まずサービス提供元に連絡するか、有効なサブスクリンクに切り替えるしかありません。サブスクが正常なのにノードが依然タイムアウトする場合は、次の段階に進みます。

第2段階:ローカルポートの占有とリスニング状態

Clash のコアは複数のローカルポートをリスニングします。HTTPプロキシポート、SOCKS5ポート、パネル通信用の外部コントロールポート(デフォルト9090)などです。これらのポートが他のプログラムに占有されると、コアの起動失敗やプロキシ機能の不完全動作が起こり、見た目上ノードはオンラインでも実際には通信が全く経由していない状態になります。

確認方法:

  1. クライアント設定でポート番号を確認し、HTTPポート(一般に7890)と混合ポート(一般に7891)をメモする。
  2. システムコマンドで該当ポートが他プロセスに占有されていないか確認する。Windows では netstat -ano | findstr 7890、macOS/Linux では lsof -i:7890 を使う。
  3. 占有が見つかった場合は競合しているプログラムを終了するか、クライアント設定でポートを未使用の番号帯に変更し、クライアントを再起動して再試行する。

同じPC上で2つのプロキシツールを同時に動かしているケースは典型的な原因のひとつです。例えば別の海外アクセスツールのプロセスが完全に終了しておらず、バックグラウンドに残ってポートを占有し続けていることがあります。

第3段階:システムプロキシと TUN モードのスイッチ

ポートが正常にリスニングされていても、通信が実際に Clash を経由しているとは限りません。システム側のプロキシ設定も同様に重要です。

  • システムプロキシモード:クライアントはシステムのHTTP/HTTPSプロキシ設定を自動的に書き込みますが、この設定が誤って無効化されると、ブラウザや大半のアプリは Clash を経由せず、直接ネットワークに出て行きます。クライアント画面の「システムプロキシ」スイッチが有効になっているか確認しましょう。
  • TUN モード:TUN モードは仮想ネットワークアダプタを通じてシステムのネットワーク層で全通信を引き継ぐ方式で、個別アプリのプロキシ設定に依存せず、システムプロキシに従わないプログラムの通信も処理できます。TUN モードを有効化するには一部のシステムで追加の権限(ネットワーク拡張の権限、管理者権限)が必要で、許可が拒否されると起動に失敗しますが、画面上に明確な通知が出ないこともあります。
  • システムプロキシを無視するアプリ:CLIツールや一部のゲームクライアントはシステムプロキシ設定を読み取らないため、こうしたケースでは TUN モードに頼るか、そのプログラム個別にプロキシパラメータを設定する必要があります。
ヒント

通信が実際に Clash を経由しているかどうかは、クライアントの接続パネル(Connections)を開き、ページにアクセスしたときに対応する接続記録が出るかで確認できます。記録が全く出ない場合は、通信がそもそも Clash に入っていないことを意味し、この段階に問題があります(ノード自体の問題ではありません)。

第4段階:プロトコルとコアの対応

Clash のオリジナルコアは限られた数のプロキシプロトコルにしか対応していませんが、Clash Meta(mihomo)は Hysteria、Hysteria2、TUIC、VMess の一部変種などより多くのプロトコルに対応しています。サブスクにオリジナルコアが認識できないプロトコルのノードが含まれていると、そのノードは即座に利用不可扱いになるか、遅延テストが常にタイムアウトになります。これはネットワークの問題ではなく、コアの機能不足によるものです。

確認方法:

  1. クライアントが内部で使用しているコアのバージョンを確認する。多くの現代的なクライアント(Clash Verge Rev、FlClash、Clash Plus など)はデフォルトで Meta/mihomo コアに切り替わっている。
  2. サブスクのノード一覧にあるプロトコル欄を確認し、hysteria2、tuic などのキーワードが出ているのにクライアントが依然旧来のオリジナル Clash コアを使っている場合は、これらのプロトコルに対応したクライアントに変更する必要がある。
  3. プロトコル自体がネットワーク環境に依存する面もある。例えば QUIC ベースのプロトコルは一部のネットワークで通信事業者による意図的な速度制限や遮断を受けることがあり、その場合はそのプロトコルのノードだけが軒並みタイムアウトし、他のプロトコルのノードは正常という状況になる。この場合は他のプロトコルのノードに切り替えるべきで、ローカル設定を追い続ける必要はない。

第5段階:DNS汚染と解決異常

前の4段階が全て正常でも、DNS解決の段階で問題が起きればノードはやはりタイムアウトとして表示されます。理由は、クライアントが速度測定や接続確立の前にノードのドメイン名をIPアドレスに解決する必要があり、この段階が汚染されていると、解決結果は誤ったIPまたは空になり、その後の接続は当然失敗するためです。

よくある対処方法:

  • 設定ファイルの dns 欄で enhanced-mode: fake-ip を有効化し、信頼できる上流DNS(暗号化された DoH/DoT サーバーなど)を設定して、汚染される可能性のある端末デフォルトのDNSを避ける。
  • nameserver リストに国内通信事業者のデフォルトDNSが含まれていないか確認し、含まれている場合は独立した暗号化解決アドレスに置き換える。
  • TUN モードを有効化すると DNS リクエストも同様に引き継がれるが、それでも解決が異常な場合は、TUN 設定ブロック内の dns-hijack 設定が53番ポートへのリクエストを正しくハイジャックしているか確認する。
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-range: 198.18.0.1/16

上流DNSを設定したらコアを再起動して反映させ、再度速度測定を行ってノードの遅延が正常な数値に戻るか確認します。

5段階の確認順序まとめ

一言でまとめると、まずサブスク自体がデータを取得できるか確認し、続いてポートが占有されていないか、システムプロキシまたは TUN が実際に通信を引き継いでいるかを確認し、次にプロトコルが現在のコアで対応しているかを調べ、最後に DNS解決が汚染されていないかを確認する、という順序です。この5段階は「外部データソース」から「ローカルのネットワークスタック」へと段階的に進んでいき、どの段階に問題があっても表面上は同じ「全滅タイムアウト」に見えますが、対応する解決方法は全く異なります。順序通りに確認することで、間違った方向で設定ファイルを何度も触るような無駄を避けられます。

以上の5段階を一通り確認してもノードが依然タイムアウトする場合は、別のネットワーク環境(スマホのテザリングなど)でテストしてみましょう。端末自体と、接続しているネットワーク環境どちらに原因があるのかを切り分けやすくなり、問題の範囲をさらに絞り込めます。

クライアントをダウンロード