Clash ノード全滞留時のトラブル対処:サブスク有効期限からポート競合まで順番に特定

まず「全滞留」か「一部だけ滞留」かを見分ける

トラブル対処に入る前に、まずこの分類判断をしておくと、後の作業時間が半分に短縮されます。

• 一部のノードだけタイムアウトし、残りは正常:高確率でノード自体か着地回線側の問題です。ほかの正常なノードに切り替えれば済み、ローカル設定を疑う必要はありません。
• 普段安定していた古いノードも含め、すべてのノードが同時にタイムアウト:これが本記事で扱うケースです。数十個のノードが同時に一斉に故障するとは考えにくく、原因はほぼローカル環境かサブスク側にあります。

測定画面に「タイムアウト」と表示されたり数値が 0ms のまま変化しない場合、慌ててノードを削除したりサブスク業者を変えたりせず、まず以下の順番で確認していきましょう。

ステップ1:サブスクが期限切れになっていないか確認する

サブスクリンクの背後には、機場(海外プロキシ業者)やサービス提供元が生成した設定スナップショットが存在します。多くのサービスは期限切れ後もリンクをすぐには削除せず、アクセス自体は可能なまま、返されるノードをすべて無効化するか空リストを返す仕組みになっています。この「表面上は動いているように見える」状態が最もクライアント側の不具合と誤認されやすいポイントです。

1. 機場・サービス提供元のユーザーパネルを開き、プラン契約期限を確認しましょう。サブスクリンクが開けるかどうかだけで判断しないことが大切です。
2. クライアント側で手動で「サブスク更新」を実行し、ノード数やノード名に変化があるか確認してください。更新前後でノード一覧が一字一句変わらない場合、サーバー側から新しいデータが送られてきていないことを意味します。
3. サブスクに通信量上限による速度制限や通信停止の規約がないか確認しましょう。一部のサービスは通信量を使い切った後もリンクは残しつつ、サービス自体は停止するという運用をしています。

ステップ2:ローカルのシステム時刻を確認する

このポイントはよく見落とされますが、コストパフォーマンスが最も高い確認項目です。多くのプロキシプロトコル(特に AEAD 暗号を使う Shadowsocks や VMess、TLS 証明書の有効期限チェックに依存するプロトコル)は、ハンドシェイク段階でタイムスタンプを検証します。ローカルのシステム時刻が実際の時刻から大きくズレていると、サーバー側がリクエストを不正と判定して接続を拒否し、「すべてのノードがタイムアウトする」という症状として現れます。これはネットワークが通じているかどうかとは無関係です。

• Windows ユーザーは画面右下の時刻設定で「時刻を自動的に設定する」が有効になっているか、タイムゾーンが正しいかを確認してください。
• macOS/Linux ユーザーはターミナルで date コマンドを実行し、スマートフォンのネットワーク時刻と一致しているか比較しましょう。
• 仮想マシン、古いルーター、長期スリープから復帰した端末は時刻のズレが起きやすいので、ネットワーク時刻(NTP)を再同期してから再テストしてください。

時刻のズレは秒単位まで厳密である必要はありませんが、数分以上ズレていると暗号ハンドシェイクが失敗する可能性があります。この確認は非常に手軽なので、サブスク確認の次に優先して実行することをおすすめします。

ステップ3:ポートが占有・競合していないか確認する

Clash / Clash Meta(mihomo コア)は起動時に混合ポート、HTTP ポート、SOCKS5 ポート、およびコントロールパネル用ポートを監視します。これらのポートが他のプログラムに占有されていると、クライアントは「正常に動作しているように見えるが、すべてのリクエストがタイムアウトする」という状態になり、エラーで即座に終了するわけではありません。

1. 同じ端末で他のプロキシソフト、旧バージョンのクライアントの残留プロセス、あるいは以前正常終了しなかった同種のプログラムが動作していないか確認してください。
2. Windows では netstat -ano | findstr 7890(ポート番号は実際の設定値に置き換え)で、そのポートが他のプロセスに使われていないか確認できます。
3. macOS/Linux では lsof -i:7890 でポートの占有状況を確認できます。
4. 競合が見つかった場合は、占有しているプロセスを終了するか、設定で別の空いているポートに変更し、クライアントを再起動してから再テストしてください。

ステップ4:プロトコルとコアバージョンが合っているか確認する

一部のノードは比較的新しいプロトコル機能(例えば Hysteria2、一部の VMess の AEAD バリエーション、特定の Trojan 拡張パラメータなど)を使用しています。クライアントのコアバージョンが古く、これらのフィールドを認識できない場合、明確なエラーは出さずに、そのノードを利用不可またはタイムアウトとして扱うことがあります。この種の問題の典型的な特徴は、同じサブスクが新しいコアのクライアントでは正常に動作し、古いコアのクライアントではすべて失敗することです。

• 現在使用しているクライアントのコアが、更新が停止している Clash Premium か、それとも Clash Meta / mihomo コアかを確認してください。新しいプロトコルは基本的に Meta 系コアでしかサポートされていません。
• クライアントの「バージョン情報」画面や設定画面でコアのバージョン番号を確認し、公式が公開している最新版と比べて明らかに古くないか確認しましょう。
• サブスク業者が新しいプロトコルへの対応を明記しているにもかかわらず、ローカルのコアバージョンが古い場合は、まずクライアントを最新版にアップデートしてから再テストしてください。

逆に、設定ファイル内に現在のコアが対応していないフィールドやプロキシ種別が含まれている場合、一部のクライアントはそのノードをエラー表示せずスキップする仕様になっており、これも「ノードがすべて消えた、またはタイムアウトした」という誤解を生みます。実際には解析段階でフィルタリングされているだけです。

ステップ5:測定・遅延テストの正しいやり方

前の4ステップに問題がなければ、遅延テスト自体を見直しましょう。遅延テストで使われる測定用アドレス(例:http://www.gstatic.com/generate_204 のようなもの)自体が特定のネットワーク環境で不安定になることがあり、この測定用アドレスへのアクセスが阻害されると、すべてのノードがタイムアウト表示になってしまいますが、ノード自体は実際には利用可能な場合があります。

1. クライアントの設定画面で現在使用している測定用アドレスを確認し、別の一般的なアドレスに変更してみてください。
2. 手動でひとつのノードを選択し、グローバルモードに切り替えて実際にウェブページを開いてみて、正常に読み込めるか確認しましょう。遅延の数値だけで判断しないことが重要です。
3. 遅延の数値が異常でもウェブページが正常に開ける場合、測定リンク自体に問題があり、ノード自体は正常に動作していることを意味します。この場合ノードの設定を追って調査する必要はありません。

トラブル対処の流れまとめ

上記5つのステップを固定した順番にまとめておくと、「ノードが全滞留する」問題に遭遇したときにこの順で確認するだけで、数分以内にどの段階に問題があるかを特定できます。

1. サブスクが期限切れ、または通信量を使い切っていないか——サービス提供元のパネルで確認し、リンクが開けるかどうかだけで判断しないこと。
2. ローカルのシステム時刻にズレがないか——自動同期が有効か、タイムゾーンが正しいかを確認する。
3. ポートが占有・競合していないか——netstat/lsof で確認し、残留プロセスを終了する。
4. プロトコルとコアバージョンが合っているか——クライアントのコアをアップデートし、対応プロトコルの範囲を確認する。
5. 測定用アドレス自体が利用可能か——別のアドレスに変更し、実際にウェブページが開けるかどうかで判断する。