目次
通信できるのに遅延を測れない場合は、テスト結果と実際の接続を別々に記録します。サブスクリプション更新後の保存済み選択が、名前の変わったノードを指している可能性があります。元の設定を残して画面で現在のノードを選び直し、保存を待って再起動後も確認すれば、新しい選択が残っているか確認できます。
サブスクリプション更新後、通信できるのに Timeout が出るのはなぜ？
サブスクリプションでノード名が変わる前後にFlClashでページを開けるか、同じ手動選択グループとそれを参照する上位グループにTimeoutが出続けるかを記録してください。ここでのテストはテスト先への遅延を測るもので、帯域幅の測定ではありません。
プロジェクトの issue #2635 は Windows の FlClash 0.8.99+2026100301 でこの現象を報告しています。今回の確認時点では利用者報告のままで、管理者が確認した汎用修正版はありません。v0.8.99 のソースに基づく調査と復旧案であり、すべての Timeout が同じ原因とは限りません。
v0.8.99 で select グループをテストする際は、まず Profile の selectedMap、つまり以前保存したノード名を読み、実際にテストするノードを探します。古い名前が現在の設定に存在しない場合、テスト対象が見つからなくても value: -1 が返ります。この値だけで、実際の通信がタイムアウトしたとは判断できません。
同じ Profile の更新後にノード名が変わり、実際の通信は予定のプロキシで成功するのに、元の選択グループや参照先のグループだけで異常が出ることが手掛かりです。確認されている報告は Windows です。他のプラットフォームは自身の名前と通信の比較が一致する場合だけ参考にし、すべてに影響があるとは推測できません。
ノード単体、グループ、実通信の結果を比較する
まずローカルバックアップを作成し、現在の Profile、オーバーライド、設定を残します。クライアントの正確なバージョン、グループ名、変更前後のノード名、テスト URL を記録してください。サブスクリプション URL に認証情報が含まれる場合があるため、バックアップと元の設定は手元だけに保管します。
同じネットワーク、Profile、テスト URL を維持し、ノード画面で問題の手動選択グループを展開します。新しい名前が現在のメンバー一覧にあることを確認してください。新しいノードとそのグループをそれぞれ一度ずつ遅延テストし、今回のテストが終わってから結果を比較します。違いが分からなくなるような連続の一括テストは避けてください。
そのグループで現在選択しているノードを使い、普段開ける HTTPS ページへアクセスして FlClash の接続履歴を確認します。リクエストが FlClash に入り、想定したプロキシを使って最後までアクセスできた場合に限り、正常な通信の比較対象になります。ブラウザーがプロキシを経由せずに成功した結果は含めません。
表示されるログに、古いノード名が applied config に存在しないと出ていれば、現在のメンバー一覧と照合します。このログがなくても古い選択が残っていないとは言えず、一つの失敗値だけで原因を特定することもできません。証拠を集めるためにデータベースを直接操作したり、制御インターフェースを LAN に公開したりしないでください。
結果に応じた調査の進め方
| 比較結果 | 次の手順 |
|---|---|
| 新しいノードの個別テストは成功し、元のグループは失敗するが、実際のプロキシ通信は成功する | まずグループに保存された選択を確認し、次の節の手順で画面から現在のメンバーを選び直します。 |
| 新しいノードとグループのテストがどちらも失敗し、実際のプロキシ通信も失敗する | ノード、テスト URL、DNS、現在のネットワークを調べます。古い名前が原因とは判断しないでください。 |
| 実際の通信は正常だが、複数の独立したノードで同じテスト URL にアクセスできない | 現在のネットワークやルールがテスト URL を遮断していないか確認します。信頼でき、到達できることを確認済みの別の URL で比較してください。 |
| Windows の旧版 FlClash で一括テストだけが失敗し、個別テストは正常で、ノード名の変更もない | 当サイトの一括遅延テストの記事を参照し、v0.8.95 の既知の問題と区別します。 |
画面から現在のメンバーを選び直し、保存を確認する
ノード画面で、現在の一覧にある有効なノードを選び直し、保存と切り替えが終わるまで待ちます。データベースへの書き込みや切り替えに失敗したという通知が出たら、繰り返しクリックせず、エラーを保存してください。
v0.8.99 は選択を selectedMap に保存し、保存やコアの切り替えに失敗した場合は変更を戻します。再起動だけでは古い記録が消えない場合があります。下の手順で選び直して確認してください。ただし、v0.8.99 をこの報告への確認済みの修正とは扱いません。
元の設定を残した復旧の手順
有効な新しい名前を選ぶ
問題の select グループで、現在の一覧にある有効な新しいノードを自分で選び直します。上位グループがこの手動グループを参照する場合は、下位の選択を直してから、上位が必要なグループを選んでいるか確認してください。回避のために自動グループを手動へ変えないでください。新しい名前を記録し、サブスクリプションから消えた旧項目は選びません。
保存時にエラーが出ていないか確認する
選択操作が終わるまで待ち、現在のグループとアプリの通知を確認します。書き込みや切り替えの失敗が出た場合はクリックを繰り返さず、元のエラーを保存してください。
ノードとグループを再テストする
元のテスト URL を使い、新しいノード、手動グループ、影響を受けた上位グループを個別にテストします。実際の HTTPS リクエストがどのプロキシを経由したかも改めて確認してください。
完全終了してから再確認する
アプリまたはトレイの通常の終了操作で完全に終了し、再び起動します。有効な新しい名前が選ばれたままか確認し、同じグループのテストと実際の通信を繰り返してください。完全終了後も正しく保存されている場合に限り、その端末で復旧したと記録します。
選び直しても保存されない場合は、元の Profile を残して別のコピーと比較する
再起動後に古い選択へ戻った場合は、まずバックアップと元の Profile を残します。通常のファイル追加または URL インポート機能から、同じ信頼できるサブスクリプションを別の Profile として追加し、区別できる異なる名前を付けてください。元の項目を削除したり、比較用の設定を作るためにアプリ全体のバックアップを復元したりしないでください。
v0.8.99 の新規インポートでは独立した Profile を作成し、保存される選択の初期値は空になるため、元の Profile に残っている選択と比較できます。サブスクリプション自体に含まれるルールは内容とともにインポートされますが、旧 Profile に紐付いた追加ルール、スクリプト、独自設定まで移行済みとは限りません。アプリ全体のオーバーライドが新しい設定にも影響する場合があるため、まず実行時設定を確認してください。
まず新しい設定のノード一覧と必要なルールを確認し、有効なメンバーを選びます。準備が整ってから短時間だけ切り替えて検証してください。新しい設定では正常で元の設定では再現する場合、新しい設定を一時的な復旧用に残し、必要なカスタマイズを一つずつ確認できます。ただし、それでもメンテナーによる原因の確認を代わりに済ませたことにはなりません。
新しい設定でも失敗する場合は、以前使えていた Profile と今回変更した設定に戻します。FlClash を介した通信を停止して、通常のネットワークが使えることを確認してください。必ずプロキシを経由すべき作業は中断し、直接接続を同等の復旧方法として扱わないでください。すべてのデータの消去、データベースの直接編集、セキュリティソフトの停止は行わず、旧版への再インストールで直るとも断言しないでください。
復旧を確認し、失敗時の証拠をプロジェクトへ報告するには？
復旧したと判断するには、名前が正しく、遅延テストと実際の通信結果を合理的に説明でき、完全終了後も選択が残っている必要があります。緑色の遅延値は一度のテストが成功したことを示すだけで、すべてのサイトやプロトコルが使える証拠にはなりません。テスト URL に到達できなくても実際の通信が正常なら、その結果も別に記録してください。
異常が続く場合は FlClash プロジェクトへ、クライアントの正確なバージョン、OS のバージョン、変更前後のノード名の対応、現在のグループメンバー、同じ URL でのノード個別テストとグループテスト、実際のリクエストが経由したプロキシ、画面で選び直した結果、完全終了と再起動後の結果を報告します。公開資料のグループ名とノード名は一貫した仮名に置き換え、サブスクリプションの認証情報、パスワード、個人用アドレス、制御インターフェースの secret を伏せてください。
issue #2635 と特徴が一致するなら、匿名化した比較結果を追加できます。YAML 無効、ノード自体の切断、一括測定だけの失敗であれば、違いを分けて説明してください。