Windows 11 の Clash Verge Rev で fallback ポリシーグループを構成する実務ガイド（ヘルスチェック付きフェイルオーバー）

読者と本稿で扱う範囲

すでに Windows 11 に Clash Verge Rev を入れ、ダッシュボード側で Mihomo と呼ばれる Clash Meta 互換 のコアが動いている前提で、この記事だけを読んでもほぼ最後まで到達できるよう書きました。テーマは proxy-groups のうち type: fallback である fallback グループ（ポリシーグループ） の設計と、そのブロック直下に書く共通ヘルスチェックのurl・interval の意味と調整軸です。画面上の名前と YAML の対応だけ押さえたい方はプロキシグループ総覧のガイドへ、自動レイテンシ選抜側の細部はurl-test 専用の記事へと役割分担しています。

fallback が目的とするゴールは、常にギリギリまで速さを競うよりも、最初に持っておきたい出口へ張りつき、その一行が不健全と判定された瞬間だけ下位のメンバーへ滑らせるフェイルオーバーです。並び順は結果を左右するので、リストの頭に置くべき名前は「今すぐすべてのコンテンツに最適とは限らなくても、信頼と地域ポリシーが合っている主力 hop」になりがちです。逆にリスト末は意図的に穏やかなバックホールや最終迂回を置く構成もよく見られます。

ふるまいの心象図（遅延トップとは違う）

Mihomo 系スタックでの ヘルスチェックは、共通のHTTPSエンドポイントに対して候補出口を総当りし、そのハンドシェイク結果で「現在選べそうか」「危険域か」を評価する仕組みが中心です。このチェック結果はグループタイプにより解釈が変わり、fallback グループでは「並び順の次候補に進んでよい許可」を出す材料として使われます。ゆえに 遅いが安定 な一行を頭に、その手前にある爆速だけど不安定そうな pop を二番手に並べたいときは、この型の方が挙動を読みやすいことがあります。

一方で、同一テスト URL が全員に対してタイムアウトする状態だとヘルスチェックは機能せず、fallback と url-test はどちらも「すべて赤い」ような表示に収束します。まず問題を切り分けるコツはブラウザもしくは別端末から同じ環境へ直叩きできるかであり、単に一覧の並びを入れ替えても効かないレイヤだった、ということが珍しくありません。

1. メンバー列Proxies:の順がそのまま設計書になる

YAML で 名前を並べたままが優先度です。画面上でドラッグできない構成でも YAML の配列順を変えれば挙動は追随しますので、運用ログを読むとき「先頭とは何を意味したのか」をコメントまたは README に残してください。名前は購読更新で増減するため、自動マージ済み構成を直接編集していると週末の更新で並びが戻ってしまう典型パターンがあります。恒久対策としては別ファイルで追記できるマージ方法や、自分専用のローカル補強ブロックへ切り離すしかありません。

並べ替える際に忘れがちなのが DIRECT と REJECT に相当する名前がテンプレ内で別名に換骨奪胎されているときです。DIRECT をリスト末に書く意図は「外部出口がすべて死んだときは素直に直結で凌ぐ」ような防御ですが、その出口が運用規約や企業環境では禁止されていることがあります。現場規律にそぐわない最終退路を自動で叩かせないために、リストに含める前に自分の許容範囲をチェックしましょう。

1. 運用開始直後に並びをスクリーンショットまたは Git diff で残し、変更理由を短文でログに載せます。
2. リストの頭は「復旧したら戻れる主力 hop」であり、レイテンシ一位とは限らないと割り切ります。
3. 二番手以降は地理的にも技術スタックともにバラけさせ、同じ上流 ASN のみを縦に積み上げないことを意識します。

2. グループ共通のヘルスチェック url と interval を現実値にする

url に指定するHTTPSターゲットは、自分の環境でもTLSが途切れず返る軽いエンドポイントを選んでください。遅延テストだけでサイト全体の速度勝負をしているわけではない一方、フェイルオーバーが頻発するようならテスト側が過敏すぎる可能性があります。interval を短くしすぎるとログが騒がしくなったり電力を削りましたりするので、まず現在値を読み取り、そのうえで片方向のみ動かしましょう。間隔調整だけで頭打ちになるなら、その時点でもう一度fake-ipまわりを疑ってください。

Windows で特有に出やすいのは電源管理中のWLANドライバが一時的なレイテンシスパイクを作り、アクティブ hop が短時間しか持たないように見えるシーンです。この場合フェイルオーバー自体が悪ではなく物理層のざわつきです。Ethernetで再現しないならWLAN設定もテーブルに乗せます。初回セットアップの復習だけで済ましていた読者にも、WLANと有線でのAB比較を一度は勧めます。

YAML 記述ブロックの例（名称は自分のリストへ置換）

proxy-groups:
  - name: FAILSAFE-GLOBAL
    type: fallback
    url: https://cp.cloudflare.com/generate204
    interval: 300
    lazy: false
    proxies:
      - PREMIUM-TOKYO
      - STANDARD-SG
      - BACKUP-US
      - DIRECT

rules:
  - GEOIP,cn,DIRECT  # excerpt
  - MATCH,FAILSAFE-GLOBAL

上記は構成の一例に過ぎません。lazy: true にすると当該グループがほぼ使わない間はヘルスチェックを間引けるため省電には有利ですが、初回だけ古い並び結果が見えるような体感になることもあります。GUIから閲覧できる場合でも最終ソースはYAMLなので、アプリ側のプレビューと実際のマージ済み構成が食い違っていないかを必ず確認します。

複数グループへ同じ名前の出口をぶら下げているときは、fallback と url-test の両方へ同じ子をぶらさない設計検討が必要です。二重自動化はログ追跡を難しくし、復旧順序よりも画面上の自動ボタンの方がユーザー心理を騒がせます。tolerance のような細かな抑制ノブはまずは url-test で使い倒し、fallback側はフェイル判定の粒度をintervalとtimeout（サポートされていれば設定）で調整すると理解しやすいです。

3. Clash Verge Rev 上での段階的ワークフロー

1. バックアップを取ってからYAMLを開く。Ctrl+Zで復元できる前提は崩れやすく、インデント一つでもパース不能になります。
2. プロファイル一覧でアクティブな構成を明示的に確認し、編集していたファイルが現在のカーネルに適用済みであることを頭に置きます。複数プロファイル運用ではここでの取り違えが頻発します。
3. 保存後に自動リロードか手動リロードへ切り替わる運用規約を自分で決め、どちらにも対応できるようダッシュボードの該当トグルへ慣れる。
4. ログパネルを開いたまま DELAY テストまたはGUI付属のグループチェック機能を一度走らせ、リストの色変化だけでなく文字列イベントを確認します。
5. 実サイトを二つほど読み込み、アクティブ行が並び順どおり復帰するか体感で確かめる。ここまで来て初めて設定は完了です。

TUNレイヤとの組み合わせはフェイルオーバー以前の問題として表面化することがあります。仮想アダプタの権限問題や競合サービスへの理解は別稿が整理しやすいので、その場合TUN に焦点を絞った解説記事へ進んでください。Windowsサービス順序も絡むと「プロキシは生きているのに特定アプリだけ直結している」状態が続きます。

フェイルオーバーが効いているかの簡易セルフテスト

まず頭のメンバーを明示的に落とせる状態を作れるならログを見つつ復旧順を確かめるのが最速です（購読者ポリシーで禁止されていない場合に限ります）。すべてのユーザーが自分の上流を止められるわけではないため、より安全にはダッシュボードの手動Bypassやルール順の一時変更で上流だけを迂回させる検証になります。その際は本番とは別プロファイル複製を起動し、復旧ログを読み込むワークスペースを汚さないよう区切ってください。

セルフテストで見るべきサインとしてはログに並んだ「health」やタイムスタンプイベント、並び順とGUIのチェック状態の一致性、復旧ごとのアクティブ行の名前が並び順の期待と一致しているかがあります。体感がすべて良好でもログイベントが異常に多いときはヘルスチェックが過敏です。

• 先頭のみを障害状態にすると二番へ移る／移らないログの差異を読む。
• 障害から復旧させたときに頭の名前へ自動で戻るか、恒久に二番へ留まるかをサービス SLA に照らして判断する。
• DNSレイヤを含め複数ウィンドウを開いた状態で順序だけをいじっても問題が続くときは上流ブロック検査へ。

url-test と併べ持つときの判断マトリクスざっくり表イメージ

自動レイテンシ選抜だけでサイトのリージョン制約まで追い込みたいなら url-test と tolerance の記事にあるノブを読み返しましょう。一方で複数CDNを順番に試して最初に通ったものだけ使いたいときはfallbackの方へ寄せられます。この二つを名前レベルでネストさせるときは名前衝突に注意してください。親子名前が循環すると起動ログにしか出ないようなエラーに悩む羽目になります。

細かい機能差異は上流コアのアップストリームのリリースノートで増減するため、自分の環境にあるバージョンのドキュメントを常にセットで読むことを忘れずに。機能表に載っていないキーだけをYAMLに増やしたところで無視されますし、ログに警告が増えるだけになることもあります。

FAQ（本文）

Q：並び順は購読の更新ですぐ消えるのか

リモート合成が勝手に同名ブロックを差し替える設計になっているときはYAML直書きだけでは翌朝には元へ戻ります。その場合にもレジストリにあるマージ用の自分専用断片ファイルやルールセットを使うしかありません。購読制作者へ「fallbackブロックだけは触らせてほしい」とメールすると返ってくる回答が一番早いときもあります。

Q：不健全ノードだけを自動スキップするイメージの踏み込み

コア側はプローブ結果を評価し、選べなくなった出口を自動的に飛ばすロジックを持ちます。つまり手で逐一クリックしなくとも「今はリストの三番目が張っている」状態を作れるのがメリットです。ただし並び順で表現されていない複雑な優先順位ロジックまでこの型に載せ込もうとするとYAMLが読みづらくなり運用終了まで苦しむことになりやすいです。

ひとつのまとめ

fallback グループとは、並び順に忠実でありながら不健全と判定された出口だけを自動で順送りすることで可用性だけを確保したいときの道具です。グループに共通で掛けるヘルスチェックのurlとintervalという二つの基準が崩れると一覧は誰でも赤く見えるため、並び順以前のレイヤだけを張り替え続けないよう注意しましょう。Windows ユーザーは電源状態と無線環境だけは常に共通のチェックリストにしておいて損がありません。

一方で、この世界にはGUIの絵だけを増やしたクライアントも多く、fallback と url-test の違いを説明しないまま自動ボタンだけを増やしていると復旧順序まで追いたいユーザーがどこにも行けなくなります。構成をテキストで共有でき、上流コアのアップストリームの意味を短文で読み返せるほうが事故後の復旧が速く、自分の頭のモデルとも一致します。それを支える素材としてこのサイトにもドキュメント集と安定版クライアントへの導線があります。

もし自分のワークフローに合うクライアントを探しているなら、自動レイテンシ選抜とは別次元の復旧モデル説明まで含められる無料ダウンロードのクライアント最新版を一度ここから試す価値は十分にあります。Windows 側のセットアップ手順を最初から復習したい場合でもすぐ読み進められる構成にしているので、この記事だけで一区切りでも、総合ページからでも自由にブラウザのタブへ足すことができます。