Clashのノードがタイムアウト・速度測定に失敗する場合の対処法｜サブスクリプション更新からDNSまで

まず切り分ける：速度測定の失敗、ノードへの接続不可、ルールの不一致

timeoutが出ても、すぐにクライアントを再インストールしないでください。速度測定の結果が示すのは、選択したノード経由でテスト先へのリクエストが指定時間内に完了しなかったことです。テスト先に接続できない、ノードへの接続に失敗する、DNSの名前解決に問題があるなど、原因が異なっても同じタイムアウトになることがあります。まず失敗する範囲を確認してから、設定を変更しましょう。

比較できる状態を記録しておく

1. クライアントのバージョン、コアの名称とバージョン、現在の設定名、障害が発生した時刻を記録します。
2. 設定のコピーを保存します。現在のプロキシモード、プロキシグループの選択、システムプロキシ、TUNのオン・オフをスクリーンショットに残します。
3. ノード、テスト先、実際に確認するWebページをそれぞれ1つ選び、以降は一度に1つの設定だけ変更します。
4. クライアントの「ログ」と「接続」画面を開きます。画面や項目の名称はクライアントによって異なるため、実際の表示を確認してください。

速度測定の単位は通常ミリ秒で、テストリクエストにかかった時間を示します。ダウンロード速度ではありません。タイムアウトのしきい値を一時的に3000ミリ秒から10000ミリ秒に変更すると、単に接続確立に時間がかかっているのかを確認できます。この値は診断用の例であり、実測性能を示すものではなく、無効なノードを復旧させるものでもありません。

手順1：サブスクリプションが有効で、最新の設定が適用されているか確認する

まずクライアントの「サブスクリプション」または「設定」画面を開き、手動で更新します。更新完了時刻が変わったことを確認し、現在有効な設定が更新したものか確認してください。設定一覧に新しい項目があっても、コアに読み込まれているとは限りません。

更新結果に応じて対処する

• 401または403が返る：サブスクリプションURLが完全か、アクセストークンが変更されていないか、アカウントの状態を確認します。詳しい意味はサーバー側の案内を確認してください。
• 404が返る：URLのパスが期限切れでないか確認し、元のサブスクリプション管理画面からURLをコピーし直します。古いブックマークは使わないでください。
• 200が返るがインポートに失敗する：レスポンスの内容がログイン画面やエラーページではないか確認します。HTTPリクエストが成功しても、利用可能な設定が返されたとは限りません。
• YAMLの解析エラーが表示される：インデント、フィールド形式、クライアントが対応するサブスクリプション形式を確認します。単一ノードのリンクを設定ファイル全体として読み込まないでください。
• サブスクリプションのダウンロードがタイムアウトする：更新リクエストが、現在使えないプロキシに依存していないか確認します。クライアントに更新用プロキシの設定がある場合は、リクエスト方法を一時的に切り替えて再試行してください。

更新後は、ノード名と数、プロキシグループのメンバーが想定どおりかも確認します。サーバー側でノードのアドレスが変更されたり、ローカルの上書きルールで新しいノードが除外されたりすることがあります。設定の読み込みに失敗している場合は、まずそのエラーを解決してください。速度測定を繰り返すのはその後です。

手順2：システム時刻を合わせ、基本的なネットワーク障害を切り分ける

端末がインターネットに正常に接続できることを確認し、システムの日付と時刻、自動同期の状態を確認します。証明書の検証には正確な時刻が必要で、一部の認証方式も時刻のずれに影響されます。表示されるタイムゾーンが異なるだけで、必ずしも障害とは限りません。重要なのは、システムの実時刻が正確かどうかです。

• Windows：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を確認してから「今すぐ同期」を実行します。
• macOS：「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻を自動設定する項目を確認します。
• Android：システム設定の「日付と時刻」を開き、自動設定を有効にします。メニューの場所はOSのバージョンや端末によって異なります。

ログに certificate has expired または certificate is not yet valid と表示されたら、まず端末の時刻を確認し、その後サーバー証明書の有効期限を確認します。エラーを回避するために証明書検証を無効にしないでください。根本原因が隠れ、接続の安全性も低下します。

ネットワークを切り替えて障害の範囲を確認する

ノードと設定はそのままにして、PCの接続先を現在のネットワークからスマートフォンのテザリングに切り替え、再テストします。テザリングでは使えて元のネットワークでは使えない場合、元のネットワークのアクセス制限、認証ページ、ルーター設定を優先して確認します。どちらでも失敗する場合は、端末側とノード側を引き続き調べてください。ネットワークの切り替えで原因の範囲は絞れますが、1回の結果だけでサーバー障害とは断定できません。

手順3：コアの起動、ポートの競合、システムプロキシを確認する

クライアント画面でコアが正常に動作していることを確認します。GUIが開いていても、mihomoが正常に起動しているとは限りません。ログに address already in use と表示される場合、通常は待ち受けアドレスまたはポートが使用中です。まず起動エラーを解消してから、ノードをテストしてください。

実際の待ち受けポートを確認する

mixed-port はHTTPとSOCKS5の両方のプロキシ接続口を提供します。以下ではローカルの混合ポートとして 7890 を例にしています。実際のポートはクライアントの設定または現在有効な設定から確認してください。すべてのクライアントでこの値が初期設定とは限りません。

# 設定例の抜粋。完全な設定ではありません
mixed-port: 7890
allow-lan: false

Windowsのコマンドプロンプトで待ち受け状態を確認します：

netstat -ano | findstr LISTENING | findstr :7890

macOSまたは必要なツールが利用できるLinuxで確認します：

lsof -nP -iTCP:7890 -sTCP:LISTEN

ポートが別のプロセスに使われている場合は、プロセスIDからプログラムを特定してから、不要なプログラムを通常の方法で終了するか、Clashのポートを変更します。正体のわからないシステムプロセスを強制終了しないでください。変更後は、アプリに手動入力したプロキシアドレスも更新します。

ローカルのプロキシ接続口とリモートノードを区別する

Windowsでは、次のコマンドでローカルHTTPプロキシ経由のリクエストを明示的に実行できます。テスト用URLはコマンドの書式を示す例です。実際にアクセスできると確認済みのHTTPSアドレスに置き換えて比較してください。

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

macOSまたはLinuxでは、コマンド冒頭の curl.exe を curl に変更します。すぐに 127.0.0.1:7890 に接続できないと表示された場合は、まずローカルの待ち受け状態とポートを確認してください。リクエストがコアに届いている場合は、接続パネルで実際に選ばれたプロキシグループとノードを確認します。プロキシを明示しても、リクエストがプロキシの入口に届いたことが分かるだけで、ルールによってリモートプロキシが選ばれるとは限りません。

明示的なプロキシ経由のテストは成功するのにブラウザーでは使えない場合は、クライアントの「システムプロキシ」設定、ブラウザー独自のプロキシ設定、ほかのネットワークツールがシステムプロキシを上書きしていないかを確認します。TUNモードにはサービス権限やルーティングも関係するため、この段階ではシステムプロキシと何度も切り替えないでください。

手順4：サーバー名と接続先ドメインのDNSをそれぞれ確認する

DNSの問題は少なくとも2か所に分けて確認します。1つはノードのサーバー名をIPアドレスに名前解決する処理、もう1つはアクセス先サイトのドメインを名前解決する処理です。前者に失敗すると、プロキシ接続が確立しないことがあります。後者に失敗すると、ノードの速度測定は成功するのに特定のWebページだけ開けないことがあります。

まずノードのサーバー名を確認する

現在の設定からノードの server フィールドを確認します。値がドメイン名なら、nslookup または Resolve-DnsName でシステムの名前解決結果を調べます。コマンドには実際のサーバー名を指定し、サブスクリプションURLやパスを含むURL全体を入力しないでください。

• システムの名前解決に失敗し、クライアントにも名前解決エラーが出る場合：端末のDNSとネットワーク接続を先に確認します。
• システムでは名前解決できるのに、クライアントでは失敗する場合：コアが使うDNSの上流サーバーと接続方法を確認します。両者が同じ経路で名前解決するとは限りません。
• 暗号化DNSを設定している場合：接続先自体にアクセスできるか確認します。接続先のドメイン名も、初期の名前解決が必要になる場合があります。
• mihomoを使用している場合：対応するバージョンで proxy-server-nameserver の設定を確認します。この設定はプロキシサーバー名の名前解決に使う上流サーバーを指定します。対応状況の詳細は、使用中のコアの設定ドキュメントを確認してください。

次にFake-IPとアプリのキャッシュを確認する

Fake-IPモードでは、DNSが合成アドレスを返すのは正常な場合があります。一般的な設定では 198.18.0.0/16 の範囲が使われます。この範囲のアドレスが表示されても、すぐに名前解決エラーと判断しないでください。コアの接続ログも確認し、アプリのリクエストが正しく処理されているか、ドメインとの対応付けが有効かを確かめます。

ブラウザーのセキュアDNS、アプリ内蔵の名前解決、システムDNSは、それぞれ異なる経路を使うことがあります。特定のアプリだけで問題が起きる場合は、設定全体を書き換える前に、そのアプリのDNS設定を確認します。比較のためにアプリ独自の名前解決を一時的に無効にした場合は、結果を記録してから恒久的な設定を決めてください。

DNSの設定は一度に1項目だけ変更し、設定を再読み込みしてからテストアプリを終了し、再起動します。Windowsでは ipconfig /flushdns でシステムのDNSキャッシュを消去できます。ただし、ブラウザー独自のキャッシュは自動的に消去されず、コアのキャッシュ管理の代わりにもなりません。Fake-IPと別のモードを切り替える場合は、既存の接続や古いマッピングにも注意してください。

手順5：プロトコル設定と通信条件を1つずつ確認する

一部のノードだけ失敗する場合は、そのノード固有の設定を重点的に確認します。手動でパラメーターを組み合わせる前に、サブスクリプション元から再更新してください。ClashのGUIクライアントとコアは別の層です。画面に特定のノードタイプが表示されても、実行中のコアのバージョンがそのタイプやすべてのフィールドに対応しているとは限りません。

QUICベースのノード通信では、通常UDPが使われます。現在のネットワークでUDPが制限されている場合、ローカルHTTPプロキシのポートを変更しても、リモート側の通信問題は解決しません。別のネットワークで比較するか、サーバーが提供する別のトランスポート方式を試してください。一般的なTCPポートの接続テストでは、UDPを使うノードが利用可能かどうかは判断できません。

TCP接続に成功しても、特定の待ち受けポートに接続できたことが分かるだけです。認証エラー、TLSハンドシェイクの失敗、トランスポート経路の不一致があれば、プロキシは使えません。「ポートに接続できた」だけで、プロトコル全体が正常だと判断しないでください。

最後に検証：ルール、ログ、実際のリクエストから原因を絞り込む

修正後は速度測定の色だけで判断しないでください。実際のWebページを開き、接続パネルで接続先ドメイン、適用されたルール、プロキシグループ、最終的に使われたノードを確認します。ルールモードではテスト用ページが DIRECT に振り分けられることがあります。その場合、ページが開いても選択したプロキシノードが使える証拠にはなりません。

ログから失敗した段階を特定する

• connection refused：接続先から明示的に拒否されています。アドレス、ポート、サービスが待ち受けているかを確認します。
• i/o timeout：いずれかの段階でリクエストが制限時間内に完了していません。前後のログを見て、名前解決、接続、ハンドシェイクのどこでタイムアウトしたかを判断します。
• no such host：まずドメイン名の入力と名前解決経路を確認します。
• authentication failed：認証情報とアカウントの状態を確認します。DNSだけを変更し続けないでください。
• unsupported proxy type：設定のプロキシタイプとコアの互換性を確認し、まず読み込みエラーを解消します。

ログレベルを一時的に上げる必要がある場合は、再現できる操作を1回だけ記録し、その後、通常のレベルに戻します。確認が終わったら、テスト先、プロキシモード、アプリのDNS設定など一時変更した項目を元に戻し、有効だった変更だけを残します。診断時の設定をそのまま使い続けないでください。

問い合わせ時に添える情報

クライアントとコアのバージョン、OS、失敗する範囲、ネットワークを切り替えた結果、エラー発生時刻、機密情報を隠した関連ログを共有してください。サブスクリプションの更新可否、ローカルポートの待ち受け状態、リクエストがコアに届いているかも記載します。この順に情報を記録すると、「ノードが全部赤い」という説明よりも、端末設定、名前解決経路、ノードサービスのどこに問題があるかを判断しやすくなります。

確認の流れは次のとおりです：サブスクリプションを更新して適用 → 時刻とネットワークを確認 → コアが起動しポートが利用可能 → DNS経路を確認 → プロトコル設定を照合 → 実際のリクエストが想定したノードに接続。再現性のある失敗が見つかった段階で止め、その問題を先に解決してください。