Clashの全ノードがタイムアウトする原因と対処法｜サブスクリプション・時刻・プロトコルを確認

1. 遅延テストの失敗と実際の接続障害を切り分ける

Clashクライアントの遅延テストでは通常、コアが指定したノード経由でテストURLにアクセスし、応答時間を測定します。単純なICMP pingでも、ダウンロード速度の測定でもありません。すべてのノードがtimeoutと表示されても、制限時間内にテストが完了しなかったことを示すだけで、すべてのサーバーが同時に停止したとは限りません。

テスト先に到達できない、ノードのドメイン名を解決できない、TLSハンドシェイクに失敗する、認証情報が誤っているといった場合も、同様の結果が表示されることがあります。まず現在の設定を保存し、ノードを1つ選んで該当時間帯のコアログを確認したうえで、同じノードから実際にWebページへアクセスしてみましょう。

1. 現在のサブスクリプション名、選択中のノード、テスト時刻、クライアントに表示されるコア名とバージョンを記録します。
2. 自動切り替えを一時停止し、手動選択できるプロキシグループでノードを1つ固定します。ブラウザーのリクエストが実際にそのノードを通っていることも確認してください。
3. 遅延テストとWebページへのアクセスをそれぞれ1回だけ実行し、接続ログでルール、プロキシグループ、出力経路を確認します。
4. Webページには正常にアクセスできるのに遅延テストだけ失敗する場合は、テストURL、テストのタイムアウト時間、サーバー側によるテストリクエストの制限を優先して確認します。クライアントの再インストールは後回しにしましょう。

2. サブスクリプションの有効期限・通信量・現在の設定を確認する

サブスクリプションを更新できても、アカウントの通信量が残っているとは限りません。逆に、更新に失敗しても、ローカルにキャッシュされたすべてのノードが無効になったとは限りません。サブスクリプションの取得経路とノードへの接続経路は別々に確認しましょう。

サーバー側とローカルの状態を順に確認する

• アカウントの状態：サービス提供元のアカウントページで、プランの有効期限、残り通信量、端末数や同時接続数の制限、メンテナンスのお知らせを確認します。クライアントに表示される通信量は、前回更新時のキャッシュである可能性があります。
• 更新結果：サブスクリプションの更新ログと最終成功時刻を確認します。HTTP 401または403は、認証またはアクセスが制限されていることを示します。具体的な原因はサービス提供元の案内も確認し、ステータスコードだけでプランの期限切れと断定しないでください。
• レスポンス内容：HTTP 200でも、ログインページやエラーテキストが返されることがあります。設定の解析に成功し、ノード数が正常で、その設定が実際に有効化されて初めて、内容が少なくともコアの読み込み処理に入ったと判断できます。
• 設定の取得元：現在、古いローカルコピーを使っていないか確認します。proxy-providersを使用している場合は、対応するプロバイダーの更新も確認してください。メイン設定ファイルの更新日時だけでは判断できません。

サービス提供元がサーバーアドレス、ポート、認証情報を変更しても、クライアントに古いキャッシュが残っていれば、旧ノードがすべて失敗することがあります。まず更新を成功させ、現在有効な設定のノード情報を確認しましょう。サブスクリプション一覧に「更新完了」と表示されただけで確認を終えないでください。

3. システム時刻を合わせてからTLSと認証のエラーを判断する

システムの日付が誤っていると、証明書の有効期間の判定に影響します。ログのcertificate has expired or is not yet validは、サーバー証明書が原因の場合もあれば、端末の時刻ずれが原因の場合もあります。時刻検証を伴う認証処理にも正確な時計が必要です。まず時刻を合わせ、端末側の問題をノードのプロトコル障害と誤認しないようにしましょう。

Windowsでは、次の読み取り専用コマンドを実行して、時刻サービスの状態と同期元を確認できます。サービスが動作していないとコマンドがエラーになることがあります。その場合はシステム設定から対処し、エラーをノード障害と見なさないでください。

w32tm /query /status

タイムゾーンは現地時刻の表示に影響しますが、TLSの判定には実際の時刻が使われます。タイムゾーンを別の地域に変更しただけでは、システム時刻のずれは直りません。時刻を修正したら再接続してください。それでも証明書エラーが出る場合は、サーバー証明書、ノードのSNI、ネットワークによる証明書の傍受を確認します。

問題を隠すためにskip-cert-verifyをtrueに設定するのは避けてください。証明書検証を無効にするとサーバーの身元を確認できなくなり、期限切れのアカウント、誤ったパスワード、トランスポートプロトコルの非互換も解決できません。

4. クライアント名ではなく、実際に動作しているコアを確認する

クライアントは画面表示、設定管理、システムプロキシを担当し、実際に接続を確立するのはコアです。オリジナルのClashとClash Meta（現在の名称はmihomo）では、対応プロトコルが異なります。同じクライアントでも、コアを切り替えたり更新したりできる場合があります。そのため、設定をインポートできても、現在動作中のコアがすべてのプロトコルを処理できるとは限りません。

読み込みログで3つの情報を確認する

1. コアの種類：クライアントのコア情報画面または起動ログで名称とバージョンを確認し、実際に動作しているコアを記録します。インストーラーのバージョンだけを記録しないでください。
2. ノードの種類：設定のtypeを確認します。たとえばHysteria2、TUIC、VLESS、REALITY関連の設定には、それぞれの機能に対応したコアとバージョンが必要です。旧版のオリジナルClashと同じ互換性を前提にしないでください。
3. すべてのパラメーター：サーバーアドレス、ポート、パスワードまたはUUID、トランスポート方式、TLS、SNI、プロトコル固有の項目を確認します。プロトコル名が同じでも、すべての拡張オプションを相互に置き換えられるわけではありません。

unsupported proxy type、不明な暗号化方式、設定の解析エラーが発生した場合は、まず互換性と設定の問題を解決してください。こうしたエラーは、ノードが実際にネットワーク接続を始める前に発生することが多く、遅延テストのタイムアウトを延ばしても解決しません。ログの文言はコアのバージョンによって異なるため、決まったエラーメッセージだけでなく、項目と前後の文脈を確認しましょう。

Shadowsocksのcipherはサーバー側と一致させる必要があります。VMessとVLESSのユーザー識別子は相互に代用できません。WebSocketを使うノードでは、パスとHostも確認します。REALITYを使うノードは、サービス提供元から指定された公開鍵、Short ID、サーバー名などのパラメーターを確認してください。サブスクリプションの変換時にこれらの項目が失われていた場合、ノード名の変更や再テストでは元に戻りません。

5. ログからDNS・ポート・ハンドシェイクの障害を切り分ける

サブスクリプション、時刻、互換性を確認したら、リクエストがどの段階で止まっているかを調べます。DNS、TUN、ポート、ルールを同時に変更すると、復旧しても原因を特定しにくくなります。ログレベルを一時的に上げて問題を1回再現し、その後は元の設定に戻してください。クライアントによっては設定の上書きでこの項目を制御するため、最終的に適用される設定を確認しましょう。

log-level: debug

ノードサーバーのドメイン名解決と、Webサイトのドメイン名解決は別の処理です。mihomoでproxy-server-nameserverを設定している場合は、プロキシノードのドメイン名を解決できるか確認してください。ブラウザーのDNS設定を変えても、コアがノードへ接続するときの名前解決経路には影響しないことがあります。

TCPポートの確認は、原因の切り分けに役立ちます。たとえばWindows PowerShellで次のコマンドを実行すると、example.comのTCP 443番ポートを確認できます。このドメイン名は構文の説明用です。実際の調査ではサブスクリプションに記載されたサーバーとポートに置き換えてください。例の実行結果はノードの状態を示すものではありません。

Test-NetConnection -ComputerName example.com -Port 443

TCPの確認に成功しても、TCP接続が確立したことしか分からず、プロキシ認証やTLSハンドシェイクの成功は確認できません。Hysteria2やTUICなどQUICベースの接続はUDPを使用するため、TCPテストではサービスの利用可否を判断できません。TCP 443に到達できたからといって、現在のネットワークでUDPが制限されている可能性を除外しないでください。

6. システムプロキシ・TUN・ネットワーク環境の影響を切り分ける

コア内蔵のノードテストとブラウザーからのアクセスでは、通信経路が異なることがあります。ブラウザーの通信はシステムプロキシ、拡張機能、アプリ独自の設定に左右されます。TUNでは仮想ネットワークアダプター、ルーティング、DNSの引き継ぎも関係します。コア自体がノードに接続できずタイムアウトするなら、ブラウザーのプロキシを切り替えても通常は解決しません。ノードテストは成功するのにWebページを開けない場合は、アプリの通信がコアに渡っているかを確認しましょう。

ローカルプロキシを明示してテストする

実際の混合ポートが7890の場合は、次のコマンドでシステムプロキシ設定を介さず、ローカルHTTPプロキシに明示的にリクエストを送れます。ポートが7890以外なら、現在の待ち受けポートに変更してください。Windowsではcurl.exeを使うと、PowerShell環境によって同名のエイリアスが干渉するのを避けられます。

curl --verbose --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

このコマンドもコアのルールに従うため、特定のノードを自動的に強制選択するわけではありません。接続ログを確認し、対象のリクエストがDIRECTではなく、意図したプロキシグループを通っていることを確かめてください。コマンドの10秒と20秒は、それぞれ接続段階とリクエスト全体の制限時間であり、ノード性能の評価値ではありません。失敗した場合は「開けない」とだけ記録せず、どの段階でエラーになったかを残しましょう。

同じ端末でネットワークを変えて比較する

• 端末、設定、ノードを同じにしたまま、自宅のネットワークとスマートフォンのテザリングを比較し、変数を増やさないようにします。
• 片方のネットワークだけで失敗する場合は、そのネットワークのログイン認証、UDP制限、ルーティング、ファイアウォールのポリシーを確認します。すぐにサブスクリプションを再インポートしないでください。
• 別のVPNやネットワークフィルタリングツールを有効にしている場合は、その状態を記録し、利用が許可された環境で1つずつ無効にしてテストします。セキュリティ対策をすべて一度に無効にしないでください。
• ログに記録された接続先がIPv4かIPv6かを確認します。該当するアドレスファミリーに到達できないと確認できた場合に限り、個別に設定をテストしてください。問題を隠すためにIPv6を全体で無効化しないようにしましょう。

ローカルプロキシを明示したテストは成功するのに、TUNを有効にすると失敗する場合は、TUNのルーティング、DNSリダイレクト設定、ほかの仮想ネットワークアダプターとの競合を確認します。変更前に設定を保存し、テスト後は元に戻してください。基本操作は使い方ガイドを参照できます。TUNをあらゆるタイムアウト問題に対する標準の修復手段と考えないでください。

7. 変更を最小限にして再テストし、再現できる記録をまとめる

修正を1つ行うごとに、最初に選んだノードと同じテストURLで再確認します。タイムアウト時間を延ばしたときだけ時々成功するなら、遅延やパケットロスの影響が考えられるため、実際のアクセスが安定しているかも確認してください。遅延の数値が1つ表示されただけで、調査を終えないようにしましょう。

1. サブスクリプション：アカウントが有効で通信量が残っており、現在のノードが直近で成功した更新から取得され、適用済みであることを確認します。
2. 端末：システム時刻が同期済みであることを確認し、コアの名称とバージョンを記録して、設定の読み込みエラーがないか確認します。
3. 接続：ノードのドメイン名解決、接続先アドレス、ポートを確認し、ログで最初に失敗した段階を特定します。
4. リクエスト：テストURLと実際のWebページへのアクセスを確認し、接続ログで想定したノードが選択されているか調べます。
5. ネットワーク環境：必要に応じて別のネットワークと比較し、システムプロキシとTUNの状態を個別に記録します。同時に設定を変更しないでください。

サービス提供元やクライアントの開発者に問い合わせる際は、OSのバージョン、クライアントとコアのバージョン、再現時刻とタイムゾーン、ノードのプロトコル、機密情報を伏せたエラーログ、別ネットワークでの比較結果を添えてください。アカウントの権限やサーバー側の待ち受け状態はサービス提供元に、設定の解析、コアの呼び出し、ルーティングの引き継ぎはクライアントの開発者に相談するのが適切です。「すべてtimeout」と表示された画面だけを送るより、担当箇所に合わせて情報を共有するほうが原因を特定しやすくなります。

調査が終わったら、一時的に変更したログレベルを元に戻し、機密情報を含むデバッグファイルを削除して、使える設定のバックアップを保管します。同じ問題が再発したときは、「サブスクリプションと認証情報 → システム時刻 → コアの互換性 → 名前解決と接続 → アプリの通信経路」の順に確認すると、ノードを手当たり次第に試すより共通の原因を見つけやすくなります。