Clashのノード選び方：遅延・倍率・地域・プロトコルの比較

Clashサブスクリプションをクライアントに読み込むと、名称、地域、プロトコル、倍率が異なるノードが一覧表示されます。ノード数が多いからといって、選びやすいとは限りません。速度テストの結果は、特定の時点で特定のテスト先に対して測った値にすぎず、実際のアクセスでは出口の場所、回線混雑、DNS解決、ルールの適用先、接続先サイトの応答速度などにも左右されます。「Clashのノードはどう選ぶべきか」を判断するには、まず要件を観測可能な指標に分解し、同じ条件で比較することが大切です。

この記事では、日常的な利用場面に沿ってノードの選び方を説明します。目的は、常に最速のノードを探すことではありません。クライアントとサブスクリプションが対応するプロトコルを確認し、安定性に欠けるノードを除外したうえで、アクセス地域、通信量コスト、アプリの種類に応じて、プロキシグループ内の優先順位を決める再現可能な手順を作ることです。

まずノード・プロキシグループ・サブスクリプションを区別する

Clashの設定では、ノードは通常、具体的なプロキシサーバーへの接続先を指します。サーバーアドレス、ポート、認証情報、通信プロトコル、関連パラメータなどが含まれます。プロキシグループは、複数のノードや他のポリシーグループをまとめたものです。手動選択グループ、自動速度テストグループ、フェイルオーバーグループ、負荷分散グループなどが該当します。サブスクリプションは設定内容を取得するためのアドレスで、クライアントは更新によってノードやルールを取得します。サブスクリプションのURL自体はノードではありません。

この区別は重要です。画面に表示される「自動選択」は、1台のサーバーではなく、プロキシグループである場合がほとんどです。その中で現在選択されている項目が、実際に使われるノードです。プロキシグループの切り替え、サブスクリプションの更新、具体的なノードの変更は、それぞれ異なる操作です。更新によってノードが追加・削除・改名されることはありますが、プロトコルの非互換、システムプロキシの未設定、ルールの誤適用などが自動的に解決されるわけではありません。

遅延は最低値ではなく安定性を見る

クライアントの遅延テストでは通常、テスト先へリクエストを送り、接続確立またはリクエスト完了までの時間を記録します。結果はミリ秒で表示され、数値が小さいほど、そのテスト先に対する応答が速いと考えられます。ただし、「遅延が低い」ことは「すべてのサイトが速い」ことを意味しません。テスト先が近くても、目的のサイトは別のネットワーク経路上にある可能性があります。また、接続確立の速さだけで継続的なダウンロード速度を判断することもできません。

最低遅延・平均遅延・ジッター

1回のテストで得られた最低値は、その瞬間のネットワーク状態に大きく左右されます。より参考になるのは、同じ時間帯に繰り返しテストし、平均遅延、最大遅延、失敗回数を確認することです。たとえばノードAが5回連続で82、84、81、83、85ミリ秒、ノードBが48、51、190、Timeout、55ミリ秒だったとします。最低値はBのほうが優秀ですが、変動が小さいAのほうが、継続的なアクセスやリモートワーク、接続維持が必要なアプリに向いています。

ジッターとは、簡単にいえば遅延の変動幅です。ビデオ会議、リモートデスクトップ、リアルタイム通信、オンラインゲームはジッターの影響を受けやすい一方、ウェブページの表示、短いリクエスト、一般的なAPIアクセスでは初回応答を重視する場合があります。パケットロスやタイムアウトも判断材料に含めましょう。平均遅延が低くても再試行が頻発するノードでは、1回のリクエストが完了するまでの時間がかえって長くなることがあります。

テスト方法ごとに分かることは異なる

• TCPまたは接続テスト：テストサービスへ到達して接続を確立するまでの速さを主に確認します。基本的な到達性の絞り込みに適しています。
• HTTPまたはURL Test：指定したURLへリクエストを送り、ノード、テストサイト、DNS、接続先サイトの応答が結果に影響します。ウェブリクエストに近い測定ですが、ダウンロード速度を直接示すものではありません。
• 実際のアクセスによるテスト：目的のアプリや普段使うサイトを短時間利用して確認します。自分の用途に最も近い結果を得られますが、表示中のページ、キャッシュ、サーバー負荷の影響を受けます。

速度テストのURLは統一し、テスト時間帯もできるだけ揃えましょう。異なるクライアントやURLで測ったミリ秒の値を、そのまま横並びで比較してはいけません。自動速度テストグループでは、テスト間隔と切り替え条件にも注意が必要です。テスト頻度が高いとリクエスト数が増え、許容範囲が狭すぎると一時的な揺らぎでノードが頻繁に切り替わります。

通信量倍率が実際のコストを左右する

サブスクリプションサービスでは、ノードごとに通信量倍率が設定されていることがあります。倍率が1xなら、1GBの通信は通常1GBとして計上されます。2xなら、同じ通信量で約2GB分の容量を消費します。具体的な計算方法はサービスの説明に従ってください。アップロードとダウンロードを合算するか、プロトコルごとに倍率が異なるかなど、細かな条件はサービスによって異なります。

倍率は速度の評価ではありません。高倍率のノードでも、出口の場所が適切だったり、経路が安定していたりする場合があります。反対に、低倍率のノードでもピーク時には混雑することがあります。選ぶ際は「使い心地」と「容量」を分けて記録しましょう。ウェブ閲覧やテキスト同期など通信量の少ない作業では、安定していてコストが適度なノードを優先できます。システム更新、クラウドストレージの同期、動画再生では通信量が増えるため、まず容量の消費を確認してから高倍率の回線を使うか決めます。

通信量あたりの使い心地で判断する

よく使うノードについて簡単な表を作り、テスト日、遅延範囲、タイムアウト回数、倍率、用途を記録しておくと便利です。たとえばノードAは平均90ミリ秒で1x、ノードBは平均55ミリ秒で2xだとします。BがAより少し速いだけで、普段の閲覧で容量を2倍消費するなら、Aをデフォルトにしたほうが適している可能性があります。一方、Bによって動画のバッファリングが明らかに減り、短時間の会議だけに使うなら、追加消費を許容する判断も合理的です。

ノードの倍率は、サブスクリプションプラン、通信量プール、回線の種類によって変わることがあります。ある時点で表示された倍率を、永続的な属性だと考えないでください。サブスクリプションを更新するたびにノード名とサービスの説明を確認し、現在のクライアント設定とサービス提供者の計量ルールを基準に判断しましょう。

出口地域はアクセスできるコンテンツとサービスの挙動に影響する

ノード名に含まれる地域名は、通常、出口IPの所在国または地域を示します。ただし、名前だけで判断せず、実際に確認する必要があります。出口地域は、コンテンツ配信、サービス提供地域、リスク判定、時刻表示、ウェブサイトの言語や通貨などに影響します。特定地域が必要なサービスでは、まず対象サービスが対応する地域を確認してから、該当する出口を選びましょう。地理的な近さだけを優先すると、IPの種類、AS、データセンターのアドレスに対するサービス側の判定を見落とすことがあります。

同じ地域にある複数のノードでも、通信事業者、データセンター、上位回線が異なる場合があります。同じ都市名が付いた2つのノードでも、同じサイトへアクセスした際の遅延や安定性が大きく異なることは珍しくありません。地域は最初の絞り込みに使い、その後は実際の接続先に対するテストも組み合わせて判断しましょう。

アクセス先に合わせて地域を選ぶ

• 近隣地域向けの一般的なウェブ閲覧：距離が近く遅延の安定した出口を優先し、ピーク時に明らかなパケットロスがないか確認します。
• 特定地域向けのサービス：地域要件を満たす出口を選び、同じ地域内で安定性とプロトコル互換性を比較します。
• 地域をまたぐAPIや開発サービス：接続確立、長時間接続の維持、リクエスト失敗率を確認し、1回のウェブ速度テストだけで結論を出さないようにします。
• 動画や大容量ファイル：遅延だけでなく、継続的な転送速度、夜間の混雑、通信量倍率も確認します。

名称や速度ランキングよりプロトコル互換性を優先する

一般的なプロキシ設定には、Shadowsocks、VMess、VLESS、Trojan、Hysteria 2、TUICなどのプロトコルやトランスポートの組み合わせが含まれます。Clash Meta（mihomo）が対応する具体的なプロトコルやパラメータは、クライアントのバージョンと設定の記述方法によって異なります。Windows、Android、macOS、iOSのクライアントでは、コアの実装が異なる場合もあります。サブスクリプション一覧にノードが表示されても、現在のクライアントで正しく利用できるとは限りません。

プロトコルはまず互換性を確認し、その後にネットワーク環境を考慮します。ノードの速度テストに失敗する原因は、プロトコルパラメータの誤り、トランスポート層への制限、TLSやSNI設定の不一致、サーバーの一時的な停止などさまざまです。その場合はノード名だけで回線品質を判断せず、クライアントログの接続エラーを確認してください。クライアントのバージョンが古いと、サブスクリプションに含まれる新しいプロトコルフィールドを認識できないことがあります。更新前に、OSのバージョンとコアの対応範囲を確認しましょう。

一般的なウェブ閲覧やAPIリクエストでは、新しいプロトコルを追求するより、安定して接続を確立できることが重要です。モバイル回線、事業者をまたぐ経路、パケットロスの多い環境では、UDPベースのプロトコルが良好に動作する場合もありますが、ネットワーク機器の制限を受けることもあります。プロトコルに環境を無視した固定の優先順位はありません。同じ接続先、同じ時間帯で実際に比較してください。

再現可能なノード選定手順

ノード選びを、その日の速度ランキングだけに頼るべきではありません。次の手順は、新しいサブスクリプションを読み込んだとき、更新後、またはネットワーク環境が変わったときに繰り返し実行できます。

1. クライアントのコアとプラットフォームを確認する。使用中のClashクライアントがmihomoベースか、サブスクリプションに含まれるプロトコル、TLSパラメータ、ルールフィールドに対応しているかを確認します。モバイル端末では、システムのVPN権限が利用可能かも確認してください。
2. まず利用可能性で絞り込む。すべてのノードに同じ条件でテストを行い、連続したタイムアウト、ハンドシェイク失敗、証明書エラーが発生するノードを削除または一時的に優先度を下げます。1回失敗しただけで完全に除外する必要はなく、時間帯を変えて再確認してもよいでしょう。
3. 遅延の範囲を記録する。少なくとも複数回テストし、平均値、最大値、タイムアウト回数、テスト時刻を記録します。低遅延でも変動が大きいノードと、安定したノードを分けて管理しましょう。
4. 地域別に候補を作る。対象サービスの地域要件に応じて出口を絞り込みます。特定地域の指定がない場合は、経路の異なる候補を2～3個残し、すべての通信を同じ回線に集中させないようにします。
5. 倍率と通信量の用途を照合する。ノードの倍率を日常の作業と結び付けて考えます。通信量の多い作業では継続速度と容量消費を優先し、通信量の少ない作業では安定した接続と応答時間を重視します。
6. 実際の利用場面で検証する。普段使うウェブサイト、API、動画、オフィスアプリなどをそれぞれテストします。ルールモード、DNSモード、システムプロキシの設定を揃え、条件の違いによる誤判定を避けてください。
7. 予備の優先順位を設定する。手動選択グループには、メインノード、同じ地域の予備、異なる地域の予備を1つずつ用意します。自動選択グループでは、速度テストURL、切り替えしきい値、フェイルオーバーの動作を確認しましょう。

絞り込みが終わったら、クライアント内で用途別のプロキシグループにノードを分けられます。たとえば「日常用デフォルト」には安定していて倍率が適度なノード、「動画テスト」には継続速度の良いノード、「地域サービス」には地域要件を満たすノードだけを入れます。すべてのノードを1つの自動選択グループに詰め込むより、問題を特定しやすく、頻繁な切り替えも抑えられます。

ルール分岐とTUNモードでテスト結果は変わる

Clashのルールシステムは、ドメイン、ドメインサフィックス、IP、プロセスなどの条件に応じて、リクエストをDIRECT、プロキシグループ、REJECTなどのポリシーへ振り分けます。ノードをテストしても、テスト先がDIRECTにマッチしていれば、その結果はノード本来の性能を示しません。クライアントの接続履歴やルール適用画面で、リクエストがどのプロキシグループを使ったか確認してください。

TUNモードは、システムの仮想ネットワークインターフェースを通じて、より多くのアプリの通信を取り込みます。システムプロキシに従わないプログラムにも対応しやすい一方、ルーティング、DNS、システム権限などの変数が増えます。TUNを有効にすると、ブラウザのテスト結果がシステムプロキシだけを有効にした場合と異なることがあります。LAN機器、仮想マシン、ゲーム、企業VPNではルートが競合する可能性もあります。ノードの選定段階では、まず一方のモードで基準値を測り、その後にTUN環境を個別に検証するのが安全です。

DNSモードも結果に影響します。Fake-IPではドメインに仮想アドレスを割り当て、その後ルールとコアが接続を処理します。Redir-Hostなどのモードでは、解決結果を保持します。ドメインは解決できるのに接続できない、LAN内のドメインだけ動作しない、特定のアプリに接続できないといった場合は、すぐにノードを変更せず、DNS設定とルールの組み合わせが適切か確認しましょう。

よくある誤解と切り分けの順番

速度テストが最も低いノードだけを選ぶ

最低遅延は、1回のテストにおける短時間の結果しか示しません。連続テスト、タイムアウト率、対象サイトへのアクセス、高負荷時間帯の挙動を組み合わせて判断しましょう。長時間接続を使うアプリでは、数十ミリ秒の差より安定性のほうが価値を持つことが多いです。

ノード名の「専用線」を性能保証だと考える

名称はサブスクリプション提供者による識別方法にすぎず、検証可能なデータの代わりにはなりません。同じラベルでも、データセンター、上位回線、負荷が異なる場合があります。同じテスト先を使い、複数の時間帯で記録して初めて、自分のネットワークに適した回線か判断できます。

速度テストは成功するのにウェブページが開けない

「ルール適用→DNS解決→ノード接続→対象サイトの応答」の順に確認します。まずリクエストが想定したプロキシグループに入っていることを確認し、次にドメイン解決とクライアントログを確認してから、他のノードと比較します。1つのドメインだけ失敗するなら、対象サイトや地域ポリシーが原因かもしれません。複数のドメインが同時に失敗する場合は、設定、システムプロキシ、DNSを優先して確認してください。

サブスクリプション更新後にノードが急に減った

サブスクリプションの内容が変更された可能性のほか、更新リクエストが完了していない、クライアントの解析に失敗している可能性もあります。まず更新ログと設定の更新時刻を確認し、次にサブスクリプションURLへアクセスできるか確認します。設定の状態を確認しないままローカル設定を何度も上書きすると、整理済みのプロキシグループ設定を失うおそれがあります。

おすすめの記録方法

簡単なノード記録表があれば十分で、関係のない情報を大量に保存する必要はありません。ノード識別子、プロトコル、地域、倍率、テスト日、遅延範囲、タイムアウト回数、用途、メモを記録するのがおすすめです。メモには「夜間も安定」「API向け」「動画速度が良好」「特定地域のみ利用可」などを書けます。サブスクリプション更新後に名前が変わったら、サーバーアドレス、プロトコル、地域情報を手掛かりに再対応させましょう。

最終的には、ノード選びを次の一文にまとめられます。まず安定して接続できる候補を選び、地域要件を満たす範囲で遅延と実際の挙動を比較し、最後に倍率と通信量の用途で優先順位を調整します。多くのユーザーにとっては、安定したメインノードと経路の異なる予備ノードを1つずつ確保し、定期的に再測定するほうが、速度ランキングの首位を追い続けるより予測しやすい接続環境につながります。