3種類のプロキシグループの選び方
Clashの自動プロキシグループは「この接続をどのノード経由にするか」を決めるもので、すべてのアプリの通信速度を自動で上げる機能ではありません。url-testは応答遅延を比較し、fallbackはノードの優先順位を維持し、load-balanceは接続を利用可能なノードに振り分けます。低遅延、固定の主回線・予備回線、接続の分散のどれが必要かを決めてから、設定項目を調整しましょう。
プロキシ選択の処理はコアが実行します。クライアントはサブスクリプションの読み込み、速度測定結果の表示、選択内容の反映を担当します。ボタン名が似ていても、クライアントによって使用するコアや対応フィールドは異なる場合があります。以下のYAML例は、mihomo（Clash Metaの後継コア名）の設定仕様に基づいています。他のClashコアで同じフィールドが使えるかどうかは、各コアの設定ドキュメントと読み込みログで確認してください。
| グループの種類 | 選び方 | 主な用途 | 注意点 |
|---|---|---|---|
url-test |
ヘルスチェックの遅延と切り替え許容値 | Web閲覧や操作時のリクエストに適した低遅延の出口 | 遅延が低くても、ダウンロード速度が速いとは限らない |
fallback |
リストの上位にある利用可能なノード | 主回線と予備回線を固定 | 主ノードが利用可能なら、予備ノードのほうが速くても切り替わらない |
load-balance |
振り分け方式とノードの稼働状況 | 複数のタスクや接続先への通信を分散 | 単一の接続を複数回線に分けて帯域を合算する機能ではない |
url-test：遅延を基準に自動選択
url-testは、各候補ノードから指定したテストURLにアクセスして応答遅延を記録し、利用可能な候補から出口を選択します。ここでの「速度測定」はリクエスト1回分の遅延チェックであり、継続的なダウンロード速度の測定ではありません。結果は、利用環境のネットワーク、ノードから接続先までの経路、DNS、接続確立、サーバーの応答などに左右されます。
intervalとtoleranceの役割
interval: 300：ヘルスチェックの実行間隔は300秒（5分）です。接続のタイムアウト時間ではありません。tolerance: 50：遅延の切り替え許容値は50ミリ秒です。候補ノードがわずかに速いだけで頻繁に切り替わるのを抑えます。timeout: 5000：ヘルスチェック1回あたりのタイムアウト上限は5000ミリ秒です。上限を超えたチェックは失敗と判定される場合があります。lazy: false：プロキシグループが使われていない間も定期的なヘルスチェックを停止しません。継続的なチェック結果を確認できます。
たとえば、現在のノードの遅延が120ミリ秒、別のノードが95ミリ秒なら、差は25ミリ秒です。許容値を50ミリ秒に設定している場合、この程度の差だけで切り替わるとは限りません。別のノードが60ミリ秒まで下がれば、差は60ミリ秒となり、許容値を超える条件を満たします。数値は設定の説明用であり、実際の回線測定値ではありません。最終的な選択はノードの稼働状況やコアの実装にも左右されます。
proxy-groups:
- name: 自動遅延
type: url-test
proxies:
- 香港-A
- 香港-B
- 日本-A
url: https://www.gstatic.com/generate_204
interval: 300
timeout: 5000
tolerance: 50
lazy: falseテスト先には、すべての候補ノードからアクセスでき、応答サイズが小さく動作が安定したURLを指定してください。例のURLは疎通確認用であり、あらゆるWebサイトへの接続品質を示すものではありません。特定のサービスを主に利用する場合は、そのサービスへの実際のリクエストも確認しましょう。ログインページ、認証画面、大容量ファイルのURLを定期チェック先にするのは避けてください。
fallback：リスト順で主回線・予備回線を切り替え
fallbackは、遅延の最小化を主な目的とせず、候補リストの上位からヘルスチェックに合格したノードを選択します。普段は同じ出口を使い、主回線が使えなくなったときだけ予備回線に切り替えたい場合に適しています。
proxy-groups:
- name: 主回線・予備回線
type: fallback
proxies:
- 香港-A
- 日本-A
- 香港-B
url: https://www.gstatic.com/generate_204
interval: 300
timeout: 5000
lazy: false障害時の切り替えと復旧後の優先順位
- 「香港-A」がチェックに合格していれば、「日本-A」の遅延がより低くても、優先して使用されます。
- 「香港-A」が利用不可と判定されると、次に利用可能な「日本-A」が選ばれます。こちらも利用できない場合は、「香港-B」が確認されます。
- 後続のヘルスチェックで「香港-A」の復旧が確認されると、再び優先して選択される場合があります。その後に確立する接続は主回線に戻る可能性があります。
そのため、fallbackは優先順位に従って選択する方式であり、「予備回線に切り替わったら、そのまま予備回線を使い続ける」という意味ではありません。手動で確認してから主回線に戻したい場合は、手動のselectグループで出口を管理してください。自動の主回線・予備回線グループだけでは、その手順を実現できません。
障害が発生した瞬間に必ず検知されるわけではありません。定期チェックだけを考えた場合、チェックに成功した直後に回線が切れると、次のチェックとタイムアウト判定まで待つ可能性があります。その他の失敗検知の仕組みはコアの設定によって異なります。interval: 300を即時切り替えの保証と解釈しないでください。
予備回線は、できるだけ主回線と異なる障害要因を持つものを選びましょう。名前が異なるノードでも、実際には同じ上流回線を共有していて、同時に使えなくなることがあります。重要なタスクでは、利用環境のネットワーク、ノードの稼働状況、接続先サービスの状態を個別に確認し、接続先自体の障害を主ノードの障害と誤認しないようにしてください。
load-balance：帯域の合算ではなく接続を分散
load-balanceは、利用可能なノード間で接続を振り分けます。複数のWebページやダウンロードタスク、異なる接続先へのリクエストを別々の出口に割り当てられますが、既存のTCP接続は選択済みのノードを使い続けます。ブラウザーに表示されるダウンロード速度の合計が向上するかどうかは、タスクの並列数、サーバー側の制限、各ノードが帯域を共有しているかなどに左右されます。
proxy-groups:
- name: 接続分散
type: load-balance
proxies:
- 香港-A
- 香港-B
- 日本-A
url: https://www.gstatic.com/generate_204
interval: 300
timeout: 5000
lazy: false
strategy: consistent-hashingconsistent-hashingとround-robin
| strategy | 振り分け方式 | 利用に適したケース |
|---|---|---|
consistent-hashing |
接続先に関連する情報を使った一貫性ハッシュにより、同じ接続先が同じ出口に割り当てられやすくなります | 同じサイトへの接続でノードが変わるのを抑えたい場合に適しています |
round-robin |
新しい接続を利用可能な候補間で順番に割り当てます | 出口が変わっても問題のない、独立した並列タスクに適しています |
一貫性ハッシュでも、出口が永久に固定されるわけではありません。候補ノードの数や稼働状況が変わると、割り当て先が変わることがあります。ドメインが利用可能かどうか、接続先がどのように識別されるかも振り分けに影響します。また、1つのページが複数のドメインにリクエストすることもあるため、「同じページ」でもすべてのリクエストが同じ出口を使うとは限りません。
mihomoには、接続元と接続先に関連する情報に基づき、一定期間割り当てを維持するsticky-sessions方式もあります。使用する場合は、利用中のコアが対応していることと、その動作を確認してください。互換性を確認せずに拡張フィールドを古いコアの設定へコピーしないでください。
ログインや長時間セッションの出口を選ぶ
銀行、決済、企業認証など、送信元IPアドレスに敏感なサービスには、固定ノードまたは手動グループが適しています。負荷分散を使うと、同じアカウントの接続ごとに異なるグローバルIPアドレスが使われ、再認証が必要になることがあります。一貫性ハッシュを使う場合でも、トップページだけでなく関連するドメインをまとめて確認してください。
ルールからのプロキシグループ利用とサブスクリプションの上書き設定
グループを定義しただけでは、通信がそのグループに流れるわけではありません。ルールモードでは、接続はrulesを上から順に照合し、該当したルールでノードまたはプロキシグループが指定されます。クライアントのシステムプロキシ、TUN、ルール照合はそれぞれ異なる段階の処理です。前の2つは通信をコアに取り込む方法を決め、プロキシグループは取り込まれた後の出口を選択します。
3種類の自動グループを1つの手動選択用グループにまとめ、クライアントから使いたい方式を選ぶこともできます。以下の例は、3つの自動グループがすでに定義されている前提です。グループ名は任意ですが、参照名は一致させ、グループ同士が循環参照にならないようにしてください。
proxy-groups:
- name: 出口選択
type: select
proxies:
- 自動遅延
- 主回線・予備回線
- 接続分散
rules:
- DOMAIN-SUFFIX,example.com,主回線・予備回線
- MATCH,出口選択example.comは、ルールの構造を示すための予約済みのサンプルドメインです。このルールでは、特定のドメインを主回線・予備回線グループに固定し、それ以外の接続は「出口選択」で処理します。既存のサブスクリプションルールすべてを置き換えるための設定ではありません。MATCHは最終ルールなので、優先的に適用するルールより後に配置してください。
サブスクリプション更新後も設定を維持する
- サブスクリプションからダウンロードしたYAMLを直接編集すると、次回の更新で変更が上書きされることがあります。まず、クライアントが永続的な上書き設定や設定のマージに対応しているか確認してください。
- クライアントの上書き機能を使う場合は、配列が全置換、追加、名前によるマージのどれで処理されるか確認してください。クライアントごとの実装は異なるため、別のクライアントの設定方法をそのまま適用できるとは限りません。
proxy-providersを使用する場合、プロキシグループからuseでプロバイダーを参照するのが一般的です。プロバイダー側のヘルスチェックと、グループ側の候補管理の両方を確認してください。- サブスクリプションの提供元がノード名を変更すると、静的な
proxiesの参照が無効になることがあります。更新後は読み込みログとグループ内の候補一覧を確認してください。
共通フィールドやルールの優先順位については、YAMLガイドのプロキシグループ解説を参照してください。通信をコアに取り込む方法を確認する場合は、TUN設定ガイドもご覧ください。プロキシグループを変更するために、すべてのネットワーク設定まで同時に変更する必要はありません。
自動切り替えがうまくいかないときの確認手順
遅延チェックは正常なのにダウンロードが遅い
まず遅延とスループットを分けて考えましょう。ヘルスチェックは小さなデータを1回リクエストするだけなので、夜間の混雑、連続転送時の速度制限、単一接続の帯域は測定できません。同じダウンロード先と時間帯にそろえ、候補ノードを手動で選んで継続的な速度を比較してください。80ミリ秒と100ミリ秒の差だけで、どちらの回線が速くダウンロードできるか判断しないでください。
ノードが切断されても切り替わらない
- 現在のモードがルールモードか確認し、接続ログで実際に適用されたルールと最終的な出口を確認してください。
- アプリの通信が実際にClashへ送られているか確認してください。ターミナルのツールではプロキシ環境変数を別途設定する必要があり、macOSのシステムプロキシに従うとは限りません。
urlに指定したURLへノード経由でアクセスできるか、intervalが長すぎないか、また遅延チェックが遅延実行の設定によって想定どおり継続しているかを確認してください。- テスト用の新しい接続を作成し、「新しい接続も切り替わっていない」のか「既存の接続が維持されている」のかを切り分けてください。
url-testの選択が頻繁に変わる
まず複数回のチェックで遅延の推移を記録してから、許容値を調整してください。たとえば、interval: 300とtolerance: 50を起点に様子を見ればよく、間隔を数秒まで短縮する必要はありません。候補ノードの遅延がわずかに変動する場合は、許容値を少し上げると切り替えを抑えられます。テスト先自体が不安定なら、まず適切なチェック先に変更してください。
すべてのノードが同時に利用不可と表示される
クライアントをすぐに再インストールするのではなく、まずテストURLへのアクセス、DNSの名前解決、利用環境のネットワーク、サブスクリプションの認証情報を確認してください。同じノードから、アクセスできることが分かっている別の小さなページに接続し、タイムアウト、名前解決失敗、接続拒否などのログと比較します。すべての候補で同時に失敗する場合は、各リモート回線が一斉に切断したのではなく、共通の依存先に障害が起きている可能性があります。
設定の検証と使い分け
Web閲覧や操作時のリクエストには、まずurl-testを試してください。主回線を決め、障害時に予備回線へ切り替えたい場合はfallback、複数の独立したタスクで出口を分散したい場合はload-balanceが候補です。単一のアカウントで安定したグローバルIPアドレスが必要なら、固定ノードまたは手動選択のほうが管理しやすいでしょう。
- 元の設定を保存する。元に戻せるよう設定のコピーを残し、まずはプロキシグループだけを変更してください。DNS、TUNスタック、すべてのルールを同時に変更するのは避けましょう。
- 設定が読み込まれたことを確認する。クライアントのログを確認し、未対応フィールド、存在しないノード名、グループの循環参照などのエラーがないか確認してください。
- 実際の出口を確認する。新しいリクエストを発生させ、接続ログで適用ルール、プロキシグループの経路、最終ノードを確認してください。グループ名だけで判断しないでください。
- 最低2回のチェック周期を観察する。間隔を300秒に設定した場合は、ヘルスチェックに必要な時間を確保してください。手動の速度測定で分かるのは、その時点の結果だけです。
- 予備回線を安全な環境でテストする。元に戻せる環境で主ノードを利用不可の状態にしてから復旧させ、新しい接続が切り替わるタイミングと主回線に戻る動作をそれぞれ確認してください。
プロキシグループ設定では、選択ルールを実際の用途に合わせることが重要です。遅延、稼働状況、出口の安定性、接続の振り分けはそれぞれ別の指標です。個別に検証すれば、速度測定を何度も繰り返したり、チェック間隔をむやみに短くしたりするより、問題の原因を特定しやすくなります。