Clashの全ノードがタイムアウトで接続不可?ローカル回線とサブスクポート障害の切り分け方

まず現象を見極める:全部赤くなる3つの可能性

クライアントで遅延テストを行うと、全ノードがタイムアウトまたは赤表示になる——このとき「ノードが全部落ちた」と思いがちですが、複数のプロバイダー・複数地域のノードを含むサブスクで、サーバーが同時に全滅する確率は実際には非常に低いです。もっとよくある原因は3種類に分けられます。1つ目はローカル機器側の回線自体に問題があり、そもそも外に出られないケース(ノードとは無関係)。2つ目はローカルやルーター層での何らかの遮断が、Clashが使うプロトコルポートを狙い撃ちで切っているケース。3つ目はサブスク自体、あるいはその中継サービスに問題が生じ、ノード情報が正しく反映されなかったりサーバーが一時的に使えなくなっているケースです。「まず自分側を確認→回線を確認→最後にサブスクを確認」という順序でこの3つを潰していけば、無闇にノードを切り替えたりクライアントを再起動したりせずに、10分程度で断絶点を特定できます。

手を動かす前に、判断基準をひとつはっきりさせておきましょう。プロキシを使わずブラウザで直接アクセスしても一般的なサイトが開けない場合、問題はほぼローカル回線側にあり、Clashとは無関係です。直接接続では正常だがプロキシを有効にした時だけ失敗する場合に限り、以下の順序でコアやサブスクの方向へ切り分けを進めてください。

ステップ1:ローカル回線自体の到達性を確認する

Clashのシステムプロキシと TUN モードをオフにして直接接続の状態に戻し、プロキシを経由しない中国本土(または現地)の一般的なサイトへアクセスしてみます。直接接続でも開けない場合、問題はローカル回線(ルーター、光回線、DNSプロバイダー)にあります。この場合はまずネット回線事業者に問い合わせるかルーターを再起動するべきで、クライアント設定をいじり続けるのは後回しにしましょう。

直接接続が正常な場合は、端末が多重的なネットワーク環境になっていないか確認します。例えば別のVPNクライアント、社内ネットワークの認証ソフト、OS標準のプロキシ設定の残留などが同時に動いていないかです。これらのソフトはClashの仮想ネットワークアダプタやシステムプロキシ設定と競合しやすく、通信がノードに届く前に遮断されたり誤った出口に転送されたりします。これらのソフトを1つずつ一時停止して速度測定をやり直すことで、競合が原因かどうか確認できます。

1. システムプロキシとTUNモードをオフにし、直接接続で回線自体が使えるか確認する。
2. 他のVPN、社内ネットワーク認証ソフト、OSレベルのプロキシツールが同時に動いていないか確認する。
3. ローカルルーターと端末のネットワークアダプタを一度再起動し、一時的な回線障害を排除する。

ステップ2:システム時刻と証明書ハンドシェイクを確認する

このステップは見落とされがちですが、全ノードが同時にタイムアウトする頻出原因の一つです。Clash系クライアントがリモートノードとTLS接続を確立する際(特にTrojan、VMessのTLS伝送、一部のHysteria2の場面)、クライアントとサーバーの両方が証明書の有効期限を検証します。端末のシステム時刻が大きくズレている場合——仮想マシン、デュアルOS切り替え後の未同期、システム時計の手動変更などでよく起こります——証明書検証がそのまま失敗し、TLSを使う全ノードがタイムアウトまたは接続拒否になる一方、他のプロトコルを使うノードは正常に繋がることがあります。

確認方法は簡単です。システムの時刻設定を開き、「ネット時刻と自動同期」がオンになっているか、タイムゾーンが正しいかを確認してください。時刻のズレが数分を超えている場合は手動で同期し直します。この修正後にクライアントへ戻って速度測定をやり直すと、多くの場合すぐに一部または全部のノードが正常に戻ります。

ステップ3:プロトコル/ポートが遮断されていないか確認する

ローカルの直接接続が正常で、システム時刻も問題ない場合、次に疑うべきはネット回線の出口側による特定ポートやプロトコル特徴の遮断です。一部の家庭用光回線、公共Wi-Fi、社内ネットワーク、学校のネットワークでは、非標準ポートやプロキシ特有の通信特徴に対して速度制限や遮断を行うことがあります。この場合、そのネットワーク下ではClashが使うプロトコルポートで常に接続が確立できないのに、スマホのテザリングなど別のネットワークに切り替えると正常に繋がる——これが「ポート遮断かどうか」を判断する最も直接的な方法です。

サブスクが複数のプロトコルや複数ポートのノードを提供している場合は、クライアント上で別のポート・別のプロトコル(例:固定ポートのVMessから443ポートを使うTrojan/TLSノードへ)に切り替えて比較テストしてみましょう。プロトコルやポートを切り替えて接続が復旧すれば、現在のネットワークが元のポートを遮断していると概ね確認でき、ノードやクライアント自体の問題ではないと言えます。長期的に同じ制限のあるネットワークを使うユーザーは、一般的なHTTPSポート(443)を使うノードを選ぶ方が安定しやすいです。このポートは通常のWebブラウジングと通信特徴が似ているため、狙い撃ちで遮断される可能性が低くなります。

ステップ4:サブスクサーバーとノード自体の状態を判断する

ローカル回線、システム時刻、ポート遮断を除外したうえで、ようやくサブスクやノード自体を疑う段階に入ります。ここで2つの概念を区別する必要があります。1つは「サブスクリンク」自体で、サービス提供者のサイトにホストされている設定ファイルにすぎず、どんなノードがあるか、接続パラメータが何かをクライアントに伝える役割です。もう1つは「ノードサーバー」で、実際に通信を中継する機器です。サブスクリンクは正常に更新でき、返ってくるノードリストも完全であっても、リスト内のノードサーバーがメンテナンスや増強、一時的な障害で使えなくなっている場合があります。この場合、クライアントは設定を正常にインポートできるのに、実際の接続では全ノードがタイムアウトします。

確認方法:まずサブスクを一度更新し直し、取得したノード数と最終更新時刻が正常かどうかを確認します。サブスク自体が長期間更新されていない、またはノード数が明らかに減っている場合は、サブスク提供元に問い合わせてサーバー側の障害がないか確認してください。サブスクが正常に更新でき、ノードリストも完全なのに接続が依然として全てタイムアウトする場合は、地域やプロトコルの異なる1〜2個のノードだけを残して個別にテストしてみましょう。数十個のノードを同時に速度測定すると、それ自体が端末の帯域や同時接続数を消費し、性能が控えめな端末ではむしろ測定結果が一括でタイムアウト表示になりやすく、「全ノードが壊れている」という誤解を生みます。

ステップ5:クライアントのコアバージョンの違いを確認する

Clash系クライアントには単一の実装しかないわけではなく、代表的なものとしてオリジナルのClashコア(更新終了)、Clash Premium、そして現在主流のClash Meta(mihomoコア)があります。コアによってプロトコルの対応度、接続タイムアウトの判定ロジック、TUNモードの処理方式にも差異があります。クライアントが長期間更新されておらず古いバージョンのコアを使っている場合、サブスクのノードが新しいプロトコル特徴(例:新版Hysteria2のパラメータ、新しいShadow-TLSの組み合わせ)を使っていると、明確なエラーではなく全部または一部のノードが認識できずそのままタイムアウト判定になることがあります。

確認方法は、クライアントの「バージョン情報」ページに表示されているコアバージョンを確認し、そのクライアントプロジェクトの最新リリース履歴と照らし合わせて、最新の安定版かどうかを判断することです。バージョンが明らかに古い場合は、クライアントを更新してサブスクを再インポートし、速度測定をやり直すのが、切り分けの中で最もコストが低く効果も直接的なステップです。前の4ステップを終えても解決しない場合は、まずこれを試すことをお勧めします。

• クライアントが使用しているコアの種類(Clash / Clash Premium / Clash Meta-mihomo)を確認する。
• クライアントの「バージョン情報」または「設定」ページで現在のコアバージョン番号を確認する。
• 最新の安定版に更新後、サブスクを再インポートして速度測定をやり直す。

5ステップをひとつの切り分けルートにまとめる

上記5つのステップをつなげると、近い原因から遠い原因へ、コストの低い順に並んだ切り分けルートになります。まず端末の直接接続が正常かを確認し、次にシステム時刻が正確かを確認し、続いて現在のネットワークが特定のポートやプロトコルを遮断していないかを判断し、その後サブスクとノードサーバー自体の状態を確認し、最後にクライアントのコアバージョン更新を検討します。この順序の設計はシンプルです——端末に近い原因ほど切り分けや修正のコストが低いので先に排除し、サーバーに近い(遠い)原因ほど関わる変数が多くコストも高くなるため、後回しにします。

実際の運用では、「全ノードがタイムアウト」というケースの大半はステップ2(システム時刻)またはステップ3(ポート遮断)で解決し、本当にサブスク提供元への連絡やクライアント更新が必要になる割合はそれほど高くありません。順番通りに全プロセスを進めることで、最終的にサブスクやノード側に問題があった場合でも、それまでの切り分け過程が状況説明を明確にする助けになります。「直接接続は正常、時刻は同期済み、プロトコルを変えたら使えた」といった具体的な説明は、その後の対応をより速く的確にします。