目次
ノードを手動で選ぶとウェブサイトを開けるのに、遅延テストは失敗し、自動選択でもそのノードが選ばれない。そんなときは、サブスクリプションを読み込み直す前に確認したいことがあります。Mihomo には、テスト先が 1 ミリ秒未満で応答すると、成功した処理時間が 0 に切り捨てられるという、条件の限られた計測の問題がありました。
ノードは使えるのに、なぜ遅延テストは失敗する？
公式リポジトリの #3316 では、同じノードのテスト履歴に alive: true と delay: 0 が現れる一方、個別ノードの遅延 API は 503 を返し、自動グループもこの 0 を有効な遅延がない状態として扱う場合が報告されています。対象となるテスト先は、同じホスト、LAN、非常に近いエッジなどです。遅延テストの失敗すべてに当てはまるわけではありません。
GUI クライアントでは、コアのエラーをまとめて失敗やタイムアウトとして表示し、0ms 自体は画面に出ないこともあります。Timeout または alive: true のどちらかが見えただけでは、この不具合と確定できません。同じノード、同じテスト URL、近い時刻の結果を照合する必要があります。
似ている三つの現象を見分ける
| 現象 | 確認と対処 |
|---|---|
| テストはすぐに完了するのに、古いコアでは 0 と記録され、失敗も表示される | #3316 の計測条件に当てはまるか確認し、対応する更新手段で修正を取り込みます。 |
| DNS・TLS・接続のエラー、または実際のリクエストが timeout を超える | 該当するログから原因を調べます。サブミリ秒の計測修正で、すべてのタイムアウトを説明することはできません。 |
| Provider の更新後に自動グループが切り替わらず、上記の計測を示す記録もない | その時点の記録を残し、グループの状態を別に調べます。同じ修正済みの問題とは判断できません。 |
v1.19.33 で変わる計測値とネットワーク速度の関係
v1.19.33 の正式リリース情報には #3316 が含まれています。固定されたソースでは、URLTest が正常に戻る経路で処理時間を整数のミリ秒へ変換した後、結果が 0 なら 1 と記録します。有効な遅延がないことを示す 0 との混同を防ぐためです。unified-delay が有効な場合の、二度目に成功したリクエストの計測も、この共通処理を通ります。
この 1ms は計測値の下限です。通信にちょうど 1 ミリ秒かかったことを意味せず、高速化を保証するものでもありません。テストでは引き続き、接続、HTTP リクエスト、設定されたステータスコードの判定が行われます。テスト先、ノード、クライアントの実際の状態は、それぞれ確認する必要があります。
timeout を大きくして変わるのは待ち時間で、tolerance が変えるのは自動グループの切り替え許容差です。どちらも、0 に切り捨てられて失われた有効な計測値を補うことはできません。この修正を確かめるために、両方の値を何度も変える必要はありません。
失敗しているノードと URL を先に記録する
メニュー名はクライアントごとに異なります。アプリにあるコア情報、起動ログ、ノードの遅延テスト、接続記録を使って確認してください。調査のために external-controller を有効化したり、ポートを公開したり、secret を共有したりする必要はありません。クライアントのバージョンだけでは、実行中の Mihomo のバージョンは分かりません。
テスト結果と実際の接続を照合する
実行中のコアと使用中の設定を確認する
コア情報または今回の起動ログで完全なバージョンを記録し、有効な設定、ノード名、テスト URL を控えます。別のフォルダーにあるコアファイルのバージョンで代用しないでください。
個別ノード・自動グループ・Provider のチェックを区別する
実際に適用されている設定で、テストの実行元、url、timeout、interval、expected-status、unified-delay を確認します。グループの url はその proxies に使われます。use で取り込んだ Provider には別のヘルスチェックがあるため、同じ接続先を使っているとは限りません。
同じ条件で少数回だけ再確認する
同じノードを選び、クライアントにある個別ノードのテストを実行します。接続記録では、実際のリクエストがそのノードを通ったことも確認してください。時刻とエラーを記録します。ウェブサイトを開けることと遅延テストの結果は、別々の観測です。
取得できる記録に基づいて判断する
既存のローカル診断で delay/history を確認できる場合は、同じノードと URL の 0 と失敗結果を照合します。確認できない場合は画面とログを保存し、未確認として扱ってください。UI の Timeout から、サブミリ秒の処理時間だったと推測しないでください。
テスト URL の応答コードが expected-status を満たしていない場合や、ログに名前解決、証明書、接続のエラーがある場合は、その明確な原因から対処します。1ms 未満の結果を作るためにサーバーを立てたり、テストを連打したり、証明書の検証を無効にしたりしないでください。
修正を取り込み、適用されたことを確かめるには？
現在の設定、クライアントのデータ、復元可能な元のバージョンを、先に独立してバックアップします。アプリがコアの個別更新に対応している場合は、アプリが認める正式な経路から #3316 を含むバージョンを選びます。対応していない場合は、修正の取り込みをメンテナーが確認している正式なクライアントパッケージを使い、アプリ内部のファイルは上書きしないでください。
更新後も同じ対象をテストする
新しいコアが実際に起動したことを確認する
v1.19.33 への修正の取り込みは確認されています。更新してクライアントの指示どおりに再起動したら、コア情報または新しいログを読み直します。アプリの更新完了表示だけで判断しないでください。
同じノードと同じ接続先を再テストする
同じ設定とテスト URL に戻し、まず個別ノードをテストしてから、元の自動グループや Provider のチェックを観察します。実行元ごとに結果を比較してください。異なる接続先の結果では、更新前後の比較になりません。
普段のリクエストも確認する
クライアントの接続記録が引き続き想定したノードを示していることを確かめ、以前使えていたウェブサイトやアプリのリクエストを試します。既存の診断で確認できる場合は、有効な処理時間が 0 と記録されたために、そのテストが誤って失敗していないか調べます。すべてのノードに 1ms と表示される必要はありません。
対応する修正パッケージがまだない場合は、実際に使えることを確認したノードを手動で選び、暫定的に使えます。ただし、計測の不具合は直らず、自動フェイルオーバーが復旧した証拠にもなりません。確認できない場合は元の設定を保ち、正式な更新を待ってください。サブスクリプションの削除や、設定全体の書き換えは不要です。
今回の対処が完了したと判断するための確認事項
緑色の数字一つで判断せず、順番に確認する
- 実行中のコアの完全なバージョンを記録し、更新経路と実際に読み込まれた設定を確認した。
- 更新前後で同じノードとテスト URL を使い、各チェックのステータスコードの条件と時間の単位を区別した。
- DNS、TLS の検証、timeout、tolerance、サブスクリプションを同時に変えていない。別の変更による効果を、今回の修正と取り違えない。
- 元の個別ノードのテストと実際のリクエストを確認し直した。自動グループや Provider のヘルスチェックは別に観察し、一度の手動テストだけですべて復旧したとは判断していない。
- まだ失敗する場合は、具体的なエラー、時刻、機密情報を隠した結果を保存し、実際のタイムアウト、ステータスコードの不一致、Provider 更新の問題を分けて記録した。
この記事は、公式の修正と固定されたソースを基に計測条件を説明しています。コアをダウンロードしたり、あなたの環境で実機再現を代行したりはしていません。更新後も失敗が表示される場合は、新たに得られた具体的なエラーから調査を続けてください。v1.19.33 ですべての遅延テストの問題が解決するわけではありません。
更新後に別の問題が起きたら、どう元に戻す？
影響を受ける操作を止め、元々対応していた更新手段で保管済みの旧バージョンへ戻してから、そのバージョンに対応する独立したバックアップを復元します。二つのバージョンが同じデータフォルダーへ同時に書き込まないようにし、唯一のバックアップを上書きしないでください。復元後は、実行中のコア、設定、手動選択、実際のリクエストを確認します。
旧バージョンへ戻すと計測の不具合が再び現れる可能性があるため、利用できる環境を取り戻すための措置として扱います。メンテナーへは、OS、コアの完全なバージョン、テストの実行元、機密情報を隠した URL、時刻、具体的なエラーを伝えます。サブスクリプションのトークン、制御用のキー、個人情報は取り除いてください。issue が閉じられているだけで、手元のパッケージに修正が含まれるとは判断できません。