Clash のノードがタイムアウトする場合は？遅延テスト、ノードの切り替え、頻繁な切断を確認する

Clash の遅延ボタンは、設定されたテストアドレスへアクセスし、指定時間内に結果を待ちます。Timeout の原因には、ノードへ到達できない、テスト URL が遮断されている、DNS の失敗、現在のネットワークによる遮断などがあります。この結果だけでコンピュータ全体がオフラインだとは判断できず、動画、ダウンロード、UDP の実際の性能を直接表すものでもありません。

逆に、遅延が数十ミリ秒でも持続接続の安定性は保証されません。ノードを調べるときは「ヘルスチェックの結果」と「実際の用途のリクエスト」を分けて記録してください。そうしないと、見栄えのよい数値に惑わされます。

メインのポリシーグループで特定のノードを選び、url-test、fallback、load-balance は使用しません。Rule モードを維持し、Connections を開いて、同じWebページまたはアプリの操作を繰り返してください。送信経路を固定することで、成功と失敗を同じ経路で比較できます。

対象ドメイン、該当ルール、ノード名、ログエラーを記録します。接続画面にリクエストがなければ、アプリは Clash を経由していません。DIRECT と表示される場合、そのルールは対象ノードを使っていません。リクエストがノードへ渡ったことを確認してもタイムアウトする場合に、ノード接続を調べます。

範囲を絞ってから設定を変更してください。たとえば一つのノードだけが故障しているときに DNS や TUN を変更すると、かえって新しい問題が発生します。同じネットワークですべてのサブスクリプションが失敗する場合も、新しいノードを購入し続けるだけでは原因を説明できません。

ログの時刻は、直前に行ったテスト操作と対応させる必要があります。バックグラウンドのサブスクリプション更新、ヘルスチェック、ブラウザリクエストが同時にログへ書き込まれることがあるため、最終行だけを切り取ると別の処理を選んでしまいがちです。

同じ固定ノードから同じ対象へ、自宅 Wi-Fi とモバイルホットスポットで一度ずつリクエストします。ホットスポットでは成功し、Wi-Fi では失敗する場合、ノード自体は動作しています。ルーターの DNS、ファイアウォール、IPv6、または通信事業者の経路を確認してください。両方で失敗する場合は、同じサブスクリプションの別ノードを試します。混雑時間帯だけ明らかに遅く、日中に戻る場合は、テスト時刻と持続速度を記録してください。設定が突然誤ったというより、回線混雑の可能性が高いと考えられます。

同じプロトコルのグループ全体が失敗し、ほかのプロトコルは正常な場合は、プロトコルの種類とコアのバージョンを記録し、サブスクリプション提供元に設定を確認してもらってください。Reality や XTLS Vision などの転送方式や flow 名を、単独のノード品質指標として扱わないでください。役立つのは、同じ環境での比較結果です。

url-test は確認結果に基づいて遅延の低いノードを選び、fallback は現在のノードが利用できなくなると順番に切り替えます。確認間隔が短すぎる、tolerance が小さすぎる、またはテスト URL が不安定だと、送信経路が頻繁に変わり、サインインセッション、ダウンロード、ストリーミング接続が中断することがあります。

ポリシーグループを一時的に select へ変更し、ノードを一つ固定します。通信断が消えた場合、原因はノード自体ではなく、ヘルスチェックのパラメータや自動切り替え方法かもしれません。自動グループを戻す際は、安定したテスト URL を使い、interval を適切に長くし、url-test に十分な tolerance を設定してください。

Webの問題ではサインインとページ読み込みまで完了させ、ダウンロードの問題では一定時間の連続転送を確認します。音声通信やゲームでは UDP とセッションの安定性を見てください。Connections には想定したルールと固定送信経路が継続して表示され、ログには同じエラーが出なくなる必要があります。

テスト URL が正常表示になったことしか確認できず、元の利用場面ではタイムアウトが続くなら、調査はまだ完了していません。ノード、ネットワーク、時刻、エラーの四つの情報をサブスクリプション提供元へ渡してください。それがあれば、経路またはサーバー側を調査できます。