Clashクライアントのノード一覧には、地域、回線、倍率、プロトコル、専用回線などの表示が同時に並ぶことがあります。遅延の数値だけを小さい順に選んでも、1回のテストで最速だった応答が分かるだけで、Webページの読み込み、動画のバッファリング、ファイル転送、長時間接続の安定性まで判断できるわけではありません。ノード選びでは複数の指標に分けて考えます。まず接続できることを確認し、次に目的のサービスまでの経路が適切かを判断し、最後に通信量の課金と継続的な安定性を合わせて選択します。

ここでいう「ノード」とは、設定ファイルからプロキシグループに渡されるプロキシサーバーのエントリを指します。Clash、Clash Meta、mihomoはルールに従って接続を適切なノードへ渡しますが、クライアントがノード上流の混雑状況を変えたり、1つの遅延値からネットワーク品質全体を推測したりすることはできません。正しい方法は、何度でも再現できる選別手順を作ることであり、数十個のノードを無作為に頻繁に切り替えることではありません。

LATENCY TEST

遅延の数値が示すもの

クライアントに表示される遅延は、通常1回のHTTPプローブに基づく値です。Clashがテスト先へ接続し、リクエストが成功すると所要時間を記録します。一般的なテスト先は非常に小さな空のレスポンスを返すため、この結果が主に示すのは、DNS名前解決、ノードとの接続確立、プロキシのハンドシェイク、テスト先へのアクセスにかかる時間です。クライアントによってテストURL、タイムアウト値、測定方法が異なるため、2つのクライアントに表示される数値が完全に一致するとは限りません。

遅延が80ミリ秒でも、ノードが一定速度でデータをダウンロードできるとは限りません。スループットは、ノードの出口帯域幅、国際回線の混雑、サーバー負荷、通信事業者の経路、TCP輻輳制御、接続先サイトの速度制限などにも左右されます。遅延が120ミリ秒でも経路が安定したノードのほうが、50〜300ミリ秒の間で頻繁に変動するノードより実際の使用感に優れる場合があります。

一度の最小値ではなく、中央値を見る

1回だけ測定するより、3〜5回連続でテストしたほうが参考になります。結果が72、75、78、74ミリ秒なら経路は比較的安定しています。一方、65、230、タイムアウト、91、410ミリ秒のような結果なら、最低値が小さくても、そのノードはまず不安定と判断すべきです。実際の使用中に発生する引っかかりは、最低遅延の大きさよりも遅延の揺れやパケットロスに関係することが多いからです。

  • 低遅延で変動が小さい：操作の多いWebページ、リモートターミナル、インスタントメッセージ、リアルタイムアプリに適しています。
  • 遅延は中程度でもスループットが安定：動画、システム更新、大きめのファイル転送に適しています。
  • 遅延が大きく変動する：混雑、パケットロス、ノードの過負荷、または無線LANの干渉が考えられます。
  • テストがタイムアウト：ノードがオフラインの場合もあれば、テスト先に到達できない、プロトコルに互換性がない、接続タイムアウトが短すぎる場合もあります。

まずローカルネットワークの揺らぎを除外する

すべてのノードで同時に遅延が高くなった場合は、まずプロキシを無効にしてローカルネットワークをテストします。ルーターの負荷、Wi-Fiの電波状況、モバイルネットワークへの切り替え、DNSの応答を確認してください。複数のノードが同時に悪化しているなら、最初から特定の遠隔ノードだけを原因と考えるべきではありません。有線接続、または安定した5GHz・6GHz帯の無線接続で再テストすると、ローカル回線が判断に与える影響を抑えられます。

REGION ROUTING

ノードの地域を接続先サービスに合わせる

ノード名に含まれる香港、日本、シンガポール、米国などの地域名は、通常サーバーの出口所在地を示しますが、名前だけで経路全体が分かるわけではありません。クライアントからノードまでが1つの経路で、ノードから接続先サービスまでは別の経路です。地域を選ぶ際はこの2つの接続を同時に考え、単純に地理的に最も近い国や地域を選ばないようにします。

アジア向けに展開されたサービスへアクセスする場合、香港、日本、シンガポールなどのノードは経路が短くなることがあります。北米に主に配置されたサービスへアクセスする場合は、米国西部のノードのほうが接続先側で直接的な経路になる可能性があります。ただし実際の結果は、サービスが利用するCDN、ノード事業者間の接続、本地ネットワークの出口にも左右されます。同じ地域のノードでもまったく異なるバックボーンを通ることがあるため、最終的にはテスト結果を基準にしてください。

地域選びの実用的な順序

  1. まず、接続先サービスに地域制限、アカウント地域の要件、コンテンツの地域差があるか確認します。
  2. 要件を満たす地域のノードから、安定して接続できるエントリを絞り込みます。
  3. 連続した遅延、ページのファーストビュー表示時間、動画の再生開始時間、ダウンロード速度を比較します。
  4. 単一地域の回線障害に備え、異なる地域の予備ノードを1つ残します。

ログイン状態を維持する必要があるサービスでは、地域を頻繁にまたいで切り替えるのは避けてください。出口アドレスが短時間にアジアから欧州や北米へ変わると、サービス側のセキュリティ確認が発生する可能性があります。この場合は同一地域内でメインノードと予備ノードを選び、障害時の切り替え能力を保ちながら、出口地域の大きな変化を抑えます。

ノード名にある「ホーム回線」「データセンター」「専用回線」「中継」などのラベルは、設定の提供元が定義したものです。Clashが回線種別を検証した結果ではありません。ラベルは初期分類の手がかりにはなりますが、最終的には出口属性、接続先サイトへの到達性、一定時間内の安定した挙動を確認してください。

TRAFFIC RATE

倍率は通信量の消費に影響するが、速度ランクではない

倍率は通常、サブスクリプションサービスの課金ルールで定義されます。たとえば実際に1 GBの通信を行った場合、倍率1のノードでは1 GB、倍率2のノードでは2 GB、倍率0.5のノードでは0.5 GBが利用枠から差し引かれることがあります。具体的な集計方法はサブスクリプション提供元の説明に従ってください。倍率フィールドはClash共通の性能指標ではなく、クライアントが倍率の高いノードに自動で広い帯域を与えることもありません。

高倍率ノードがコストの高い回線に対応している場合はありますが、「倍率が高いほど速い」と直接判断することはできません。ピーク時間帯の負荷、ノード全体の帯域幅、ローカル通信事業者の経路によっても結果は変わります。倍率はコストの条件、遅延・ジッター・スループット・到達性は品質の条件として、それぞれ分けて判断してください。

用途に応じて倍率を使い分ける

  • Web閲覧とテキスト通信：通信量が少ないため、低遅延と安定した接続を優先します。
  • 高画質動画と大容量ファイル：通信量を大きく消費するため、低倍率ノードの継続速度を比較します。
  • リモート操作とターミナル接続：ジッターとパケットロスの影響を受けやすく、高帯域幅が最優先とは限りません。
  • 一時的な緊急接続：品質の高い予備回線を確保し、メインノードの障害時に手動で切り替えます。

プランの通信量に上限がある場合は、2層の戦略を作るとよいでしょう。日常のルールグループには低倍率で安定したノードを使い、重要なサービスには検証済みのノードを個別に割り当てます。すべての接続を高倍率回線に置き続けるより、消費量を管理しやすくなります。プロキシグループはプロキシエントリを選ぶだけで、通信量の差し引きは遠隔サービス側で集計されます。

PROTOCOL COMPATIBILITY

プロトコルはカーネルの互換性とネットワーク環境を優先する

サブスクリプションには、Shadowsocks、Trojan、VMess、VLESS、Hysteria2、TUICなどのプロトコルが含まれることがあります。プロトコル名は接続方式や伝送方式を示しますが、サーバー設定、カーネル実装、現在のネットワーク環境から切り離して比較することはできません。従来のClashとClash Meta、mihomoでは、対応するプロトコルやフィールドの範囲が完全には同じではありません。インポート前に、クライアントが実際に使用するカーネルのバージョンを確認してください。

現在のカーネルが認識できないプロトコル種別やパラメータを設定に含めると、設定の解析に失敗する、ノードが表示されない、接続時に直接エラーが出るといった結果になります。この種の問題はプロキシグループを切り替えても解決しません。まず互換性のあるカーネルへ更新するか、サブスクリプション提供元が用意した互換設定を使用してください。同じプロトコルでも、トランスポート層、TLS、SNI、フィンガープリント、UDPパラメータが異なる場合があります。ノード名だけで設定が同等だと判断しないでください。

TCP、UDPとネットワーク制限

一部のプロトコルは主にTCPを使用し、別のプロトコルはUDPやQUICを使用します。UDP型の伝送は、適切な回線ではパケットロスへの耐性に優れることがありますが、企業ネットワーク、学校ネットワーク、公衆Wi-Fi、一部の通信事業者回線ではUDPが制限される場合があります。家庭のネットワークでは正常なのに、オフィスネットワークで特定のノードがタイムアウトし続けるなら、サーバーがオフラインだと決めつける前に、現在のネットワークが該当する伝送方式を許可しているか確認してください。

リアルタイム音声、オンラインゲーム、一部のDNS処理にはUDP転送が必要です。ノードエントリ、プロトコル実装、プロキシグループ、動作モードのすべてが該当する通信に対応している必要があります。TUNモードを有効にすると、より多くのシステム通信をカーネルで処理できますが、TUN自体がノードにないUDP機能を補ったり、遠隔回線の帯域幅を増やしたりすることはありません。

プロトコルは速度ランキングではない

「特定のプロトコルが必ず最速」という固定の順位は作れません。プロトコルのオーバーヘッド、ハンドシェイク方式、輻輳制御は確かに性能へ影響しますが、サーバー負荷や回線品質も同じように重要です。より確実な判断方法は、まず現在のクライアントが正しく解析・接続できることを確認し、同じネットワーク、近い地域、近い時間帯で実際の作業を比較することです。

STABILITY CHECK

継続テストで実際の可用性を確認する

遅延、地域、倍率、プロトコルで初期選別を終えたら、候補ノードを実際の利用環境で検証します。各候補ノードを少なくとも10〜30分観察し、Web閲覧、マルチメディア、仕事用接続など主要な作業を含めることをおすすめします。速度テストを1回行うだけでは、短時間の空き状態を長期的な安定性と誤認しやすくなります。

4つの安定性チェック

  1. 接続確立：複数の新しいページを続けて開き、接続段階で頻繁に止まらないか確認します。
  2. 継続転送：高ビットレートの動画を再生するか、適度なサイズのファイルをダウンロードし、速度が周期的にゼロにならないか確認します。
  3. 長時間接続：インスタントメッセージ、リモートターミナル、Webアプリをオンラインのままにし、接続が繰り返し切れないか確認します。
  4. ピーク時の再テスト：普段もっとも利用する夜間や勤務時間帯に再テストし、負荷の低い時間帯の結果だけを記録しないようにします。

安定したノードは、すべての指標で絶対的に1位になるとは限らず、時間帯が変わっても近い性能を保つノードです。候補ノード3つについて、テスト日時、遅延範囲、接続先サービス、倍率、異常内容を記録するとよいでしょう。数日続けて確認すれば、こうした記録はノード名に含まれる回線ラベルよりも役立ちます。

ノードの問題とルールの問題を切り分ける

ノードを切り替えても対象サイトへの接続がDIRECTのままなら、問題はノード品質ではなくルールマッチングにある可能性があります。クライアントの接続履歴を確認し、どのルールに一致したか、どのプロキシグループへ渡されたか、そしてグループが実際にどのノードを選択しているかを確認してください。ルールは設定に記述された順序で評価されるため、前のルールが後ろの地域ルールやドメインルールより先に適用されることがあります。

ブラウザーではアクセスできるのに他のアプリが接続できない場合は、システムプロキシの適用範囲を確認します。システムプロキシが処理できるのは、主にプロキシ設定に従うアプリです。TUNモードならより多くの通信を引き受けられますが、対応するシステム権限が必要です。この場合、ノードを変更すると一時的に現象が変わることはあっても、通信がClashに入っていないという根本原因は解決できません。

DNSの異常がノード障害のように見えることもあります。ドメインは開けないのに既知のアドレスへ直接アクセスできる場合は、DNSモード、nameserver設定、ログを確認してください。Fake-IPモードでは、カーネルがドメインと予約アドレスの対応関係を管理します。返されたアドレスを特殊に検査するアプリでは、互換ルールの追加が必要になることがあります。ノードの遅延が正常でも、DNS名前解決の経路が正常だとは限りません。

POLICY GROUPS

ノードの選別結果を適切なプロキシグループに割り当てる

手動選択は、出口を固定したい場合や明確に制御したい場合に適しています。自動遅延選択は、同じ用途のノード群からその時点で応答の速いエントリを選ぶ場合に適しています。フェイルオーバーはメインノードを優先して使い、プローブに失敗したら予備ノードへ切り替える場合に適しています。プロキシグループごとに解決する問題は異なります。すべてのノードを1つの自動グループに入れて、地域、倍率、サービス互換性まで同時に処理できると期待しないでください。

mihomoの設定でよく使われるurl-testは、指定したアドレスと間隔でノードをテストし、条件に合う低遅延の結果を選択します。fallbackは、リスト順に利用可能なノードを選ぶことを重視します。実際に利用できるフィールドはカーネルのバージョンによって異なるため、設定を変更する前に復元可能なバックアップを残してください。

proxy-groups:
  - name: 日常用
    type: select
    proxies:
      - アジア自動
      - メインノード
      - 予備ノード

  - name: アジア自動
    type: url-test
    proxies:
      - 香港-01
      - 日本-01
      - シンガポール-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

上記のテストアドレスは構造の説明用です。現在のネットワークとノードの出口から長時間アクセスでき、応答が安定した軽量なアドレスを選んでください。intervalは再テストの間隔を制御します。短すぎるとリクエストやログのノイズが増えます。toleranceは遅延が近い場合に頻繁な切り替えを抑えるために使います。自動グループはテストの仕組みに基づいて判断するだけで、倍率、アカウント地域、特定サービスのログイン状態を理解することはありません。

おすすめのノード階層化方法

  • 地域ごとに候補グループを作ります。たとえばアジア、北米、欧州に分け、用途が大きく異なるノードを混在させないようにします。
  • 通信コストに応じて、日常用グループと高品質な予備グループを分けます。
  • 特定地域の固定を求めるサービスには専用プロキシグループを作り、ルールからそのグループへ振り分けます。
  • 重要なグループごとに、少なくとも2台の異なるサーバー、または異なる回線のノードを確保します。
  • 継続的にタイムアウトするもの、プロトコルが無効になったもの、名前が変更された古いエントリを定期的に整理します。

サブスクリプションの更新後にノード名が変わると、プロキシグループに手書きした古い名前が使えなくなることがあります。長期的な管理には、クライアントが対応するプロキシセット、フィルター条件、設定オーバーライド機能を使うほうが適しています。ただし具体的な構文はクライアントとカーネルによって異なります。変更後は設定チェックを実行し、ログでプロキシグループが正常に読み込まれたことを確認してください。

SELECTION CHECKLIST

Clashノード選びチェックリスト

  1. サブスクリプションが正常に更新され、ノードのプロトコルが現在のClash Metaまたはmihomoカーネルと互換性があることを確認します。
  2. 安定したローカルネットワークで複数回連続テストを行い、1回だけ出た最低遅延による誤判定を避けます。
  3. 接続先サービスに合わせて地域を選び、ログイン状態を維持している間は地域を頻繁にまたいで切り替えないようにします。
  4. 倍率は通信コストとして扱い、速度や回線ランクと直接結び付けないようにします。
  5. 目的の作業がUDP、TUNモード、特定のDNS処理方式に依存していないか確認します。
  6. Web閲覧、動画、ダウンロード、長時間接続で実際の性能を確認し、普段利用するピーク時間帯も含めます。
  7. 接続ログを確認し、ルールの一致、プロキシグループの選択、実際のノードが一致していることを確認します。
  8. 同一地域の予備ノードを確保し、手動選択、自動テスト、フェイルオーバーグループで管理します。

最終的な選択は具体的な用途に合わせます。インタラクティブな操作では遅延とジッター、継続的な転送ではスループットと安定性、地域指定のサービスでは出口位置、通信量に制限がある場合は倍率を重視します。これらの条件を分けて判断し、プロキシグループで組み合わせれば、遅延が最小のノードを単純に選ぶより、安定性が高く理由も説明しやすい結果を得られます。