3種類のプロキシグループの選び方
低遅延の出口を自動で選ぶならurl-test、優先順位を決めた主回線・予備回線ならfallback、複数の出口に接続を振り分けるならload-balanceを使います。いずれもプロキシグループであり、プロキシプロトコルではありません。また、新しいノードを作成する機能でもありません。グループには、すでに存在するプロキシノードまたは互換性のあるプロキシグループを指定します。
Clashは、ルールベースのプロキシコアやそのクライアント群を指す一般的な呼び名です。Clash Metaは後にmihomoとして開発が続けられています。クライアントの見た目が似ていても、同じコアを使っているとは限りません。この記事のYAML例はmihomo向けです。旧バージョンのClashコアでは、利用できる項目や負荷分散アルゴリズムが異なる場合があるため、使用中のコアのドキュメントと設定検証の結果を確認してください。
| 種類 | 選択基準 | 用途 | 主な制約 |
|---|---|---|---|
url-test |
チェック結果と切り替え許容値 | 普段のブラウジングで、低遅延のノードを自動選択 | チェック時の遅延はダウンロード帯域を示すものではない |
fallback |
リスト内で最も優先度が高く、利用可能なメンバー | 主回線を優先し、障害時に予備回線へ切り替え | 主回線が遅くても利用可能な場合、通常は切り替わらない |
load-balance |
利用可能なメンバーと指定した振り分けアルゴリズム | 複数の宛先や接続を別々の出口に振り分ける | 単一接続の帯域を合算する機能ではない |
url-test：チェック時の遅延で経路を選択
url-testは各メンバーから指定したURLにアクセスして結果を記録し、それをもとに出口を選びます。ノードの品質が時間とともに変わり、手動で頻繁に切り替えたくない場合に適しています。測定するのはチェック先へのリクエストにかかった時間であり、ローカル環境からノードサーバーまでの単純なICMP遅延ではありません。
intervalとtoleranceは単位が異なる
interval: 300：自動ヘルスチェックの間隔は300秒、つまり5分です。300ミリ秒ではありません。tolerance: 50：切り替えの許容値は50ミリ秒です。小さな遅延変動による頻繁な切り替えを抑えるための値で、チェックのタイムアウト時間ではありません。url：ヘルスチェックに使用するHTTPまたはHTTPSのURLです。安定していて応答が軽く、すべてのメンバーからアクセスできるものを指定します。lazy: false：遅延チェックを無効にし、検証中にチェック結果を継続して確認できるようにします。ノードが多い場合は、バックグラウンドのチェックリクエストが増えます。
たとえば、現在の出口のチェック結果が120ミリ秒、別のメンバーが95ミリ秒なら、改善幅は25ミリ秒です。許容値が50ミリ秒の場合、すぐに切り替わるとは限りません。別のメンバーが60ミリ秒なら改善幅は60ミリ秒となり、許容値を超えます。この例はパラメーターの関係を説明するもので、実測値ではありません。実際の選択結果は、メンバーの利用可否やチェックの完了時間、カーネルの実装にも左右されます。
「安定させる」ために許容値を大きくしすぎないでください。たとえば500ミリ秒に設定すると、遅延に大きな差があっても切り替わりにくくなります。まずはinterval: 300、tolerance: 50で様子を見て、ネットワークの変動幅に合わせて調整してください。動画のバッファリングやダウンロード速度に問題がある場合は、パケットロスや帯域、接続先サイトへの経路も確認しましょう。管理画面の最低遅延だけを見ても原因は特定できません。
fallback：リスト順に主回線・予備回線を切り替え
fallbackは、リストの先頭に近い利用可能なメンバーを選びます。リストの順序がそのまま優先順位になります。先頭のメンバーが利用可能なら優先して使い、利用できない場合に次のメンバーを検討します。最低遅延を目指す方式ではなく、toleranceの設定も必要ありません。
- 普段使う優先ノードを
proxiesの先頭に置きます。 - 予備ノードは優先順位順に並べ、できるだけすべてのメンバーが同じ障害経路に依存しないようにします。
- 共通のチェックURLを使い、まずは間隔を300秒にして利用状況を確認します。
- 主ノードが復旧し、チェックで正常と判定されると、その後の接続では再び主ノードが優先されます。
先頭のメンバーのチェック結果が180ミリ秒、2番目が80ミリ秒だとします。先頭のメンバーが利用可能と判定されている限り、fallbackは2番目のほうが速いという理由だけで積極的に切り替えることはありません。主回線で「チェック先には接続できるが、実際に使うWebサイトは遅い」という場合でも、グループが主回線を選び続けることがあります。
load-balance：アルゴリズムに応じて接続を振り分け
load-balanceは、複数の接続をグループ内の利用可能なメンバーに振り分けます。並行するリクエストが複数あり、リクエストごとに異なる出口を使っても問題ない用途に適しています。3つの回線にそれぞれ帯域があっても、1つのダウンロード接続で3回線分の帯域を合算できるわけではありません。
mihomoでよく使われる振り分けアルゴリズム
| strategyの値 | 主な動作 | 使用上の注意 |
|---|---|---|
consistent-hashing |
宛先に関連する情報をもとに、一貫性ハッシュで振り分け | 同じ宛先に対して出口を比較的固定しやすい一方、メンバーが変わると割り当てが変わる場合がある |
round-robin |
新しい接続ごとに利用可能なメンバーを順番に選択 | 同じWebサイトへの接続でも、異なるグローバルIPアドレスが使われる場合がある |
sticky-sessions |
送信元と宛先の情報をもとに、一定期間同じメンバーへ割り当て | カーネルの対応状況を確認してください。アカウント単位で出口が固定される保証ではありません。 |
この例ではconsistent-hashingを使用します。宛先のグループ分けは、ドメイン情報を参照できるかどうかなどの条件に左右されます。「1つのアカウントが常に同じノードを使う」という意味ではありません。出口IPが重要な決済、管理画面へのログイン、企業認証などでは、固定ノードを使うか、手動選択用のグループを別に作成してください。
round-robinのローテーションは接続の振り分け時に行われます。1つのTCP接続のパケットを複数のノードへ順番に送る方式ではありません。ブラウザーがHTTP/2接続を再利用する場合、ページを何度か再読み込みしても、グローバルIPが厳密に交互に切り替わるとは限りません。負荷分散の動作を確認するには、クライアントの接続ログを確認し、複数の独立した新規接続を発生させてください。
proxy-groupsの設定例
以下はmihomoの設定に追加できるプロキシグループの一部です。設定内のproxiesに「香港01」「日本01」「シンガポール01」という3つのノードがすでに存在することを前提としています。これらの名前を実際のノード名に置き換え、元のサーバー、プロトコル、認証情報はそのまま残してください。
proxy-groups:
- name: 出口選択
type: select
proxies:
- 自動速度測定
- 障害時切り替え
- 負荷分散
- DIRECT
- name: 自動速度測定
type: url-test
proxies:
- 香港01
- 日本01
- シンガポール01
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: false
- name: 障害時切り替え
type: fallback
proxies:
- 香港01
- 日本01
- シンガポール01
url: https://www.gstatic.com/generate_204
interval: 300
lazy: false
- name: 負荷分散
type: load-balance
proxies:
- 香港01
- 日本01
- シンガポール01
url: https://www.gstatic.com/generate_204
interval: 300
lazy: false
strategy: consistent-hashingここで使うgenerate_204のURLはヘルスチェック専用で、サブスクリプションURLやノードサーバーではありません。通常はHTTP 204を返します。利用中のネットワークや出口から安定してアクセスできない場合は、軽量であることを確認した別のチェック先に変更してください。ログインが必要なページ、複雑なリダイレクトがあるページ、応答サイズの大きいページは避けてください。
ルールからプロキシグループを指定する
グループを定義したら、ルールからそのグループを参照する必要があります。以下はルール構文の例で、既存のルール一式を置き換えるためのものではありません。LAN向け、DIRECT向け、用途別のルールは残し、最後にデフォルトのルールを配置してください。
rules:
- DOMAIN-SUFFIX,example.com,出口選択
- MATCH,出口選択example.comはルール構文の例として使うドメインです。実際に使うときは、振り分け対象のドメインに変更してください。MATCHは、前のルールに一致しなかった接続をすべて対象にするため、詳細なルールより前に置いてはいけません。クライアントをルールモードにし、「出口選択」から「自動速度測定」「障害時切り替え」「負荷分散」のいずれかを選ぶと、選択したポリシーが該当する通信に適用されます。
サブスクリプションとproviderを統合する際のポイント
proxy-providersでノードを読み込む場合、プロキシグループでは通常、provider名をproxiesに書くのではなく、useで参照します。両者は別の名前空間です。以下は、既存の設定に「サブスクリプションノード」という名前のproviderが定義されている想定です。
proxy-groups:
- name: サブスクリプション自動速度測定
type: url-test
use:
- サブスクリプションノード
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: falseこの断片にはproviderのダウンロードURL、キャッシュパス、更新設定が含まれていないため、単独では完全な設定として使えません。サブスクリプションに利用可能なプロキシグループがすでに含まれている場合は、まず既存グループの動作を確認し、同じグループを重ねて作成しないようにしてください。数十個のノードを複数の自動グループに同時に登録すると、チェックリクエストが増え、問題の切り分けも難しくなる場合があります。
providerのhealth-check.intervalとプロキシグループのintervalは、設定する場所が異なります。一方だけ変更して、すべてのチェック間隔が変わったと考えないでください。チェックの実行や再利用の具体的な動作は、カーネルの実装によって異なります。原因を調べる際はproviderとプロキシグループの両方を確認し、実際のログを参照してください。
サブスクリプションを更新すると、設定ファイルに直接加えた変更が上書きされる場合があります。カスタムグループを継続して使うには、クライアントが対応する上書き、マージ、拡張設定の仕組みを利用してください。クライアントによってメニュー名は異なります。「サブスクリプション」または「設定」画面から現在の設定の操作メニューを開き、編集対象が永続化される上書きファイルか、ダウンロード後の一時設定かを確認してください。
設定の検証とトラブル対処
速度測定の数値だけでなく、手順に沿って検証する
- 現在の設定をバックアップします。正常に動作する設定のコピーを保存し、使用中のカーネル名を記録してください。コマンドラインで動作させている場合は、
mihomo -vでバージョン情報を確認できます。 - 構文と参照先を確認します。コマンドライン環境では
mihomo -t -f ./config.yamlを実行できます。相対パスのリソースを参照する設定の場合は、実際の実行ディレクトリと環境で確認してください。 - 設定を再読み込みします。クライアントの設定再読み込み機能を使うか、環境に応じてカーネルを再起動してください。ファイルを保存しただけでは、実行中の設定が切り替わらない場合があります。
- ヘルスチェックを実行します。プロキシグループの画面で速度測定を実行し、少なくとも1つのメンバーが利用可能であることを確認してください。初回のチェックが完了する前に、古い遅延値だけを見て選択結果を判断しないでください。
- ルールの一致状況を確認します。接続ログで宛先ドメイン、一致したルール、プロキシグループの経路、最終的なノードを確認し、通信が新しく作成したグループを通っていることを確かめてください。
- 新しい接続で再テストします。テストするアプリの既存接続を閉じてから再試行してください。同じ長時間接続のページを再読み込みするだけでなく、チェック状態、ポリシーの選択、実際のアクセス結果を比較しましょう。
よくある症状と原因
- プロキシが見つからないと表示される：ノード名が完全に一致しているか確認してください。空白、大文字・小文字、サブスクリプション更新後の名前変更に注意が必要です。providerを使用している場合は
useの参照も確認してください。 - 自動速度測定グループが切り替わらない：現在のモードと、ルールがそのグループに一致しているかを確認し、遅延差が
toleranceを超えているかも調べてください。使われていない、よく似た名前の別グループを現在の出口と取り違えないようにしてください。 - すべてのメンバーがタイムアウトになる：まず1つのノードを個別に検証し、その後チェックURL、DNS、ネットワークへの到達性を確認してください。共通のチェック先に障害があると、正常な回線が複数同時に異常と判定されることがあります。
- fallbackが常に先頭のメンバーを使う：先頭のメンバーが正常なら、優先順位に沿った動作です。低遅延の出口を選びたい場合は
url-testを使ってください。 - load-balanceでログイン状態に問題が起きる：ラウンドロビンを使っているか、サービスが出口IPに依存しているかを確認してください。アルゴリズムを頻繁に変えるより、対象の通信だけを固定ノードに振り分けるほうが簡単です。
- サブスクリプションの更新後にカスタムグループが消える：更新で上書きされるファイルに変更を加えていないか確認し、継続して使う変更はクライアント対応の上書き機能に移してください。
用途に合わせて設定を絞り込みます。普段のブラウジングではurl-testを検証し、主回線と予備回線の順序を固定するならfallbackを選びます。複数の接続を振り分ける必要がある場合に限り、load-balanceを使ってください。ルールやDNSをさらに調整する前に、設定ファイルのリファレンスを確認できます。インストールと設定の読み込み方法はクライアント設定ガイドをご覧ください。