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

Timeout は、構成で指定したテスト先が制限時間内に応答しなかったことを示します。ノードに到達できない、テスト URL が遮断される、DNS が失敗する、ローカルネットワークが通信を止める可能性があります。それだけでパソコン全体の切断や、動画、ダウンロード、UDP の性能は判断できません。

同じノードで失敗したサイトを開くか、アプリで同じ操作を行い、実際の結果と遅延テストの結果を記録します。遅延が小さくても、ダウンロードが継続するか、長い回答が最後まで届くかはそれぞれ確認してください。

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

宛先ドメイン、一致したルール、ノード名、プロトコル、ログのエラーを記録します。接続画面に要求がなければ、アプリが Clash を経由しているか確認します。DIRECT ならルールを調べ、ノードに渡った後もタイムアウトするならノードへの接続を確認します。

単独のノード障害で DNS と TUN を同時に変える必要はありません。同じネットワークで複数のサブスクリプションが失敗する場合は、接続ネットワークの比較が役立ちます。

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

スマートフォンのテザリングで成功し、元の Wi-Fi で失敗するなら、ノードは動作しているため、ルーターの DNS、ファイアウォール、IPv6、通信事業者のネットワークを確認します。夜の混雑時だけ遅くなり昼に戻る場合は、テスト時刻と継続速度を記録します。回線の混雑が疑われます。

同じプロトコルのグループ全体が失敗し、ほかのプロトコルが正常なら、種類とコアのバージョンを記録して提供元に構成を確認します。Reality、XTLS Vision などの転送方式や flow の名前だけでは回線品質を判断できません。

url-test は測定結果から遅延の小さいノードを選び、fallback は現在のノードが使えなくなると順に切り替えます。測定間隔が短すぎる、tolerance が小さすぎる、テスト URL が不安定といった条件で、新しいリクエストの出口が頻繁に変わることがあります。既存の接続が切れるかどうかは、ノードの障害やクライアントが古い接続を閉じるかにもよります。

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

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

テスト URL に応答があっても元の操作がタイムアウトする場合は、ノード、ネットワーク、時刻、エラーを記録し、提供元に回線やサーバーの問題を調べてもらいます。