ルールは分かった。次は「出口」を自動で決めたい
購読を取り込み、DOMAIN や GEOIP でトラフィックを振り分けるところまで来ると、あとはルール行末に書かれたポリシーグループ名が、実際の通信経路を決めます。多くのテンプレではそのグループが PROXY のような包括名で、中身は手動の select になっていることがあります。動画や開発ツールのように常に同じ地域の出口が欲しい用途なら手動でも構いませんが、ノードの健全性が日々変わる環境では、遅延計測で最適化する url-test と、優先順で生きているノードへ逃がす fallback を組み合わせた方が、メンテナンスの手間がぐっと減ります。
本記事の焦点は、ドメイン単位の分流そのものではなく、proxy-groups の型と主備（プライマリ／バックアップ）の並べ方、そして設定後に GUI やログで「本当に切り替わったか」を見る手順です。ルール設計の全体像は ルール分流の解説記事 とあわせて読むと、設定ファイルの見通しがさらに良くなります。
select・url-test・fallback の違いを一行で
select はユーザーが選んだ子プロキシ（または別グループ）をそのまま使います。自動では切り替わりません。url-test は定期的に url へ到達できるかと遅延を計測し、条件を満たす中からいま遅延の小さい候補を選びます。fallback はリストの上から順に「生きている」最初の候補を使い、障害が続くと次へ進むイメージの故障転送です。主備構成にしたいときは、多くの場合プライマリを上に並べた fallback が素直です。一方、「常に速い方を自動で」が主目的なら url-test の比重が高くなります。
url-test：計測 URL・間隔・許容差をどう置くか
url-test グループには、計測先の url、再計測の interval（秒）、および遅延差の tolerance（ミリ秒、実装により解釈差あり）がよく使われます。計測 URL は、軽量でブロックされにくい HTTP エンドポイントを選ぶのが無難です。コミュニティでは http://www.gstatic.com/generate_204 などが例として挙がることがありますが、自環境で到達不能な URL を選ぶと、全候補が不健康扱いになるので、自宅回線・ノードの組合せで実際に叩けるかを確認してください。
interval を短くしすぎると計測トラフィックが増え、長すぎると障害や回線状況の変化に追従が遅れます。体感とログを見ながら、たとえば数分オーダーから始めて調整するのが現実的です。tolerance は「ほぼ同じ遅延なら今のノードを維持する」ためのバッファとして理解すると分かりやすく、頻繁なチラつき切替を減らす方向に効きます。細かい既定値や追加キーは、利用中のコアのリリースノートを一次情報として確認してください。
fallback：主備ノードを「順番」で表現する
fallback の proxies 配列は、上にあるほど優先です。したがって、いちばん信頼したい商用ノードや自前 VPS を先頭に、コスト優先の予備や、最終手段としての別リージョンを続けます。先頭が復旧したときに自動で戻るかどうか、戻り方の速さは実装と設定の組合せに依存するため、「プライマリ復旧後すぐ戻ってほしい」要件がある場合は、コアの挙動説明を読み、必要なら間隔パラメータを調整してください。
予備として DIRECT を列の末尾に置く構成も見かけますが、規制下の回線では DIRECT は意図せぬブロックに当たることがあるため、安易に最終フォールバックへ入れない方がよいケースもあります。自分のルール設計とセットで、「ここまで落ちたらむしろ切断で気づきたい」のか「とにかく繋がればよい」のかを決めておくと安全です。
入れ子のポリシーグループ：AUTO と手動 select を両立する
運用では、url-test や fallback で束ねた「自動グループ」を一つのプロキシとして扱い、外側に select を置いて「自動／手動 A／手動 B」を切り替える構成がよく使われます。ルールの MATCH や海外向け行は、最終的にその外側の select 名を指すようにしておくと、GUI からの操作も分かりやすくなります。名前の重複や参照ミスは典型的な設定事故なので、購読テンプレをマージしたあと存在しない名前をルールが指していないかを必ず確認してください。
設定例（説明用の断片）
以下は概念説明用の YAML 断片です。ノード名は購読の proxies に実在する名前に置き換えてください。環境によってはキー名や必須項目が異なる場合があります。
proxy-groups:
# Latency-based auto pick among nodes
- name: AUTO-URL-TEST
type: url-test
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
proxies:
- Tokyo-01
- Singapore-02
- LosAngeles-03
# Primary then backup; first healthy wins
- name: PROXY-FALLBACK
type: fallback
url: http://www.gstatic.com/generate_204
interval: 300
proxies:
- Primary-VPS
- Backup-Commercial
- Tokyo-01
# Manual override wraps automatic groups
- name: PROXY
type: select
proxies:
- AUTO-URL-TEST
- PROXY-FALLBACK
- DIRECT
ルール側では、例えば MATCH,PROXY のように、最終的に上記 PROXY グループへ流します。ストリーミングや金融系など出口の国を固定したいドメインだけ、別の select 名へ振り分ける、という二段構えにすると運用が楽です。
実測・検証：GUI・ログで切替を確認する
設定を反映したら、まずクライアントのポリシー画面で url-test グループに遅延表示が付くか、fallback が想定の子を選択しているかを見ます。次に、意図的にプライマリを落とす（クライアント上で無効化する、あるいはファイアウォールで遮断する等）と、数分以内に予備へ移るかを確認します。戻し試験としてプライマリを復旧させ、期待どおり先頭候補に戻るか、維持されるかを記録しておくと、後から同じ構成を再現しやすくなります。
ログでは、接続失敗や健康チェックの結果がメッセージに出ることがあります。症状が再現しないときは、DNS が別経路を返していないか、TUN モードとシステムプロキシの二重適用など、ルール以前の要因も疑ってください。TUN 周りの整理は TUN モードの記事 が参考になります。
よくある誤解と落とし穴
url-test と fallback を同じ目的で二重に積む
どちらも「自動で良い方へ」に見えますが、選び方の基準が異なります。遅延最優先なら url-test、契約やコストで優先順が決まっているなら fallback が主役です。迷う場合は、まず fallback で主備を固定し、各段の中だけ url-test で枝を広げる、と階層化すると思考が整理されます。
ルールは正しいのに挙動が変わらない
ルールが別のグループ名を指している、GUI の一時的な選択が残っている、プロファイルが複数あって編集したファイルを読み込んでいない、といったケースが多いです。反映ボタンやプロファイルの再読み込み、クライアント再起動まで含めて確認してください。
DNS だけ別ルートで名前解決が分裂
接続先 IP は期待どおりなのに応答が不安定、というときは、fake-ip とルール評価のタイミングや、クライアント外の DNS が混ざっていないかを疑います。分流記事の DNS 節と合わせて読むと原因が絞りやすくなります。
まとめ
url-test は遅延計測に基づく自動選択、fallback はリスト優先順の故障転送──この役割分担を押さえれば、ルールで「海外は PROXY」と決めたあとも、ノード選びをルーチンから外せます。主備を明確にしたいときは配列の上から順に信頼度を並べ、手動で上書きしたいときは外側に select を置く、という型が実務では扱いやすいです。計測 URL と間隔は環境依存が大きいので、導入後は必ず実測で微調整してください。
クライアントの導入や更新は、対応 OS が一覧になっている ダウンロードページ から行うと、後からポリシーグループを編集するときも同じ土台に立てます。GUI と YAML の両方に触れられることは、長期運用では大きな強みになります。