目次
グループ全体の速度テストによる誤検知であることを確認する
この記事で扱うのは、Windows 版 FlClash におけるグループ全体の遅延テスト異常だけです。一度更新すると多数のノードが Timeout と表示されますが、そのうち一つを開いて個別にテストすると遅延が返り、選択すれば実際のアクセスも完了できます。
公式 issue #2314 には v0.8.95 での比較結果が記録されており、同じ設定とネットワークを v0.8.94 へ戻すと一括テストが正常になりました。その後、v0.8.96 のリリースノートには Windows 版のグループ全体の遅延テストに関する修正が明記されています。
単一ノードのテスト、実際のリクエスト、同じグループ内のほかのノードがすべて失敗する場合、画面上の誤検知として扱うことはできません。この場合は、ノード、テスト先、DNS、現在のネットワークのいずれかが実際に利用できない可能性が高くなります。
まず Timeout を二種類に分ける
| 観察結果 | 可能性が高い結論 | 次の手順 |
|---|---|---|
| 一括テストでは Timeout と表示されるが、個別テストと実際のアクセスは正常 | Windows 版のグループ全体の速度テストによる誤検知 | バージョンを記録し、更新を準備する |
| 一括テストと個別テストがともに失敗し、実際のアクセスにも失敗する | ノードまたはネットワークの障害 | ノード、DNS、テスト先の確認へ進む |
| 一つのプロキシグループだけに異常がある | グループの規模または設定の違い | 同じグループに固定してバージョンを比較する |
| TUN を有効にすると端末全体で通信できなくなる | 速度テストの表示に関する問題ではない | まずシステムプロキシを復元し、TUN を確認する |
設定を保存し、テスト条件を固定する
更新前に Profile、オーバーライド、アプリ設定をエクスポートし、FlClash のバージョン、Windows のバージョン、テストするプロキシグループ、テスト時刻を記録します。サブスクリプションリンクには token が含まれる場合があるため、スクリーンショットとログでは必ず伏せてください。
今回変更するのはクライアントのバージョンだけです。サブスクリプションの更新、ネットワークの切り替え、厳格な DNS オーバーライドの有効化、TUN の調整を同時に行わないでください。テスト条件を変えないことで、Timeout がグループ全体の速度テスト経路に起因するかを判断できます。
繰り返しテストできるサンプルを一組用意する
現在の Profile をバックアップする
サブスクリプションの入手元、オーバーライド、現在のポリシー選択を残し、バックアップを手元の端末で確認できることを確かめます。
アプリのバージョンを記録する
「About」画面または設定画面で Windows v0.8.95 かを確認し、バージョンのスクリーンショットを保存します。
一つのプロキシグループに固定する
多数のノードを含み、多くの Timeout を安定して再現できる同じプロキシグループを選びます。
赤色のノードを三つ選ぶ
ノード名を記録し、後で個別テスト、実際のアクセス、更新後の再テストをそれぞれ行います。
個別テストと実際のアクセスを比較する
一括テストで Timeout と表示されたノードを一つ選び、まず個別の遅延テストを一度実行します。次に現在のポリシーをそのノードへ切り替え、安定して開ける Web ページへアクセスします。最後に接続記録で、接続の成功と実際の送信先が表示されているかを確認してください。
ほかの赤色ノード二つでも繰り返します。複数のノードで個別テストまたは実際のリクエストを完了できる場合、一括テストのバッジはノードの稼働状態を表していません。すぐにサブスクリプションを削除したり、ルールをリセットしたり、すべてのノードを変更したりしないでください。
三つの層で比較を完了する
ノードを個別にテストする
今回の結果が完了するまで待ち、グループ全体の更新を続けてクリックしないでください。具体的な遅延が返るかを記録します。
現在のノードに固定する
手動選択グループで対象のノードを選び、リクエスト中に自動ポリシーが出口を切り替えないようにします。
実際のリクエストを送る
普段安定してアクセスできるページを開き、読み込みが完了するかを確認します。
接続記録を照合する
リクエストが FlClash へ入り、先ほど選択したノードと接続の成功が表示されることを確認します。
個別テストで遅延が返り、実際のリクエストも成功する
ノードは利用可能で、一括テストの Timeout はこの記事の手順で対処できます。
個別テストは失敗するが、実際のリクエストは成功する
ノードの障害として削除せず、遅延テスト先とテスト経路を確認してください。
個別テストは成功するが、実際のリクエストは失敗する
ルール、DNS、プロトコル、接続先 Web サイトを確認します。単純な一括速度テストの問題ではありません。
両方とも失敗する
まずネットワークを変えるか別のノードへ固定し、一般的なノードのタイムアウト手順に沿って確認します。
Windows 版の一括テストで起きた回帰を理解する
issue #2314 では、問題を v0.8.95 の Windows デスクトップ経路に限定しています。デスクトップ IPC を通して一括リクエストを送る際に輻輳が起き、送信失敗が画面上ですべて Timeout と表示されるため、単一ノードのテストでは再現しない場合があります。
公式の修正コミットでは、一つのバッチで同時に処理するノード数を減らし、デスクトップ RPC の待機処理と応答処理を調整しました。この変更は FlClash の一括テスト経路にあり、ノードのプロトコルやサブスクリプションの内容を変更するものではありません。
これは v0.8.95 固有の回帰を説明できますが、FlClash のすべての Timeout が IPC に起因することを証明するものではありません。個別テストと実際のリクエストを比較した後に限り、更新による検証へ進むのが適切です。
三つの層を混同しない
| 層 | 失敗時に表示される内容 | ノードの故障を示すか |
|---|---|---|
| グループ全体の速度テスト画面 | 多数のノードが同時に Timeout へ変わる | 単独では証明できない |
| 単一ノードの遅延テスト | 一つのノードから遅延が返らない | 実際のリクエストも必要 |
| 実際の接続記録 | リクエストを確立できない、またはノードでエラーが出る | 実際の利用可否により近い |
FlClash v0.8.96 へ更新する
FlClash v0.8.96 は 2026年8月17日に公開され、公式説明には Windows 版のグループ全体の遅延テスト失敗に対する修正が明記されています。前述の特徴に一致する場合は、v0.8.96 またはそれ以降の安定版への更新を優先してください。
プロジェクトの公式 Release から、Windows のアーキテクチャに合うインストーラーを入手します。強引にインストールするためにセキュリティソフトウェアを無効にしたり、配布元の警告を無視したりしないでください。ファイルの入手元を確認できない場合は、現在利用可能なバージョンを維持します。
ロールバック可能な順序で更新する
バックアップを利用できることを確認する
Profile、オーバーライド、現在の選択をエクスポート済みか確認し、旧バージョンのインストーラーの保存場所を記録します。
FlClash を完全に終了する
トレイからアプリを終了し、古いプロセスがカーネル、設定、デスクトップサービスを保持し続けないようにします。
公式の安定版をインストールする
公式 Release から正しいアーキテクチャを選び、インストール完了後にアプリを起動します。
バージョンと設定を照合する
v0.8.96 またはそれ以降の安定版と表示され、元の Profile とポリシー選択が残っていることを確認します。
同じプロキシグループで修正を検証する
元のネットワーク、サブスクリプション、テスト先、プロキシグループを変えず、グループ全体の遅延テストをもう一度実行します。更新前に記録した三つの赤色ノードを重点的に確認し、全体の赤色表示が減ったことだけで判断しないでください。
続いて対象ノードを一つずつ選び、実際のリクエストを送って接続記録を確認します。グループ全体の結果が復旧し、サンプルノードから遅延が返り、リクエストも成功して初めて、手元の環境で一括テストの誤検知が解決したと確認できます。
修正の完了基準
- アプリのバージョンが v0.8.96 またはそれ以降の安定版である
- 同じプロキシグループで、多数のノードが同時に Timeout と表示されなくなる
- 更新前に記録したサンプルノードから遅延が返る
- 少なくとも一つのサンプルノードで実際の Web リクエストが完了する
- 接続記録に、現在選択しているノードをリクエストが使用したと表示される
- サブスクリプション、オーバーライド、DNS、TUN の設定が意図せずリセットされていない
更新後も Timeout が残る場合の切り分け方法
少数のノードが利用できなくても、修正失敗とは限りません。安定版が対処するのは、確認済みの Windows 版のグループ全体のテスト問題だけです。実際のノード停止、テスト先への到達不能、DNS の異常、現在のネットワーク制限によって、通常の Timeout は引き続き発生します。
公式 issue #2253 には、厳格な DNS オーバーライドを有効にした後、一括速度テストに異常が起きる別の場面も記録されています。これは v0.8.95 の IPC 回帰と完全に同じとは確認されていません。すべてを緑色にするために、必要な DNS 設定を長期間無効にしないでください。
特定の少数ノードだけが失敗する
個別テストと実際のリクエストをそれぞれ行い、ノードまたはテスト先へ到達できないかを確認します。
一括テストと個別テストが引き続きすべて失敗する
テスト URL、DNS、システム時刻、現在のネットワークを確認し、モバイルホットスポットへ切り替えて比較します。
厳格な DNS オーバーライドが有効な場合だけ異常になる
設定を保存してからスイッチの有効・無効を比較し、別の issue として追跡します。修正済みの回帰へ分類しないでください。
TUN を有効にするとすべてのリクエストが中断する
まず TUN を無効にしてシステムプロキシを復元し、ルーティング、仮想ネットワークアダプター、DNS ハイジャックを確認します。
画面は正常だが、自動グループが引き続き誤ったノードを選ぶ
カーネルのヘルスチェック先、間隔、ポリシーグループの種類を確認します。
異常がある場合は、利用可能と分かっているバージョンへ戻す
v0.8.96 が手元の環境で起動しない、Profile が失われる、または実際の接続に新しい障害が起きる場合は、まずアプリを完全に終了し、更新前のバックアップを復元します。実行中に設定ディレクトリを何度も上書きしないでください。
issue #2314 の比較環境では、v0.8.94 でグループ全体のテストが正常だったため、この特定の回帰に対する一時的なロールバック先として使用できます。ロールバックすると v0.8.96 の修正は失われるため、更新を長期間止める理由にはなりません。
利用可能な状態を復元する
すべてのプロセスを終了する
トレイ、画面、カーネルがすべて終了したことを確認してから、バージョンを変更します。
検証済みの旧版をインストールする
更新前に保存した公式インストーラーを使用し、必要に応じて手元の端末で動作確認済みの v0.8.94 へ戻します。
設定のバックアップを復元する
自分の Profile とオーバーライドだけを復元し、配布元が不明なディレクトリ全体をインポートしないでください。
実際の接続を検証する
まずシステムプロキシでリクエストを一度完了し、その後グループ全体の速度テストと接続記録を確認します。