Clashノードの選び方：遅延・倍率・地域・プロトコルの判断ガイド

SELECTION BASELINE

まずノード選定の目的を決める

Clashノードを選ぶとき、遅延が最小なら実際の快適さも最高とは限りません。現在の用途に合うかどうかは、接続の安定性、利用可能な帯域、ネットワーク経路、接続先の地域、通信量倍率、クライアントの対応状況などで決まります。Web閲覧、動画視聴、大容量ファイルのダウンロード、リアルタイム通話、リモート開発では求められる回線品質が異なるため、1回の遅延値だけで判断すると誤りやすくなります。

通常のWebアクセスでは、接続確立の速さと安定性が重要です。動画視聴では継続的な帯域が必要で、バッファリング後なら一時的な高遅延は再生に大きく影響しませんが、短時間のパケットロスや大きな揺らぎは画質低下を招きます。音声通話、会議、ゲームでは、低ジッター、低パケットロス、安定した往復時間がより重要です。大容量ファイルのダウンロードでは、連続スループットを確認しつつ、ノード倍率による通信量の増加も考慮します。

選定を始める前に、用途を「日常の標準ノード」「特定地域向けノード」「高帯域の一時利用ノード」の3種類に分けます。日常用は安定性を優先し、ルールモードで大半のプロキシ通信を任せられるものを選びます。特定地域用は地域によって提供内容が変わるサービスへのアクセスに使い、高帯域用は更新、同期、ダウンロード向けとします。ただし、長時間の接続維持に向くとは限りません。すべての用途をカバーする「最速ノード」を探すより、この分類のほうが信頼性の高い選び方です。

LATENCY TEST

Clashの遅延テストを正しく理解する

Clashクライアントの遅延テストは、通常、システムコマンドのICMP Pingとは異なります。一般的には、対象ノード経由でテスト用URLへアクセスし、接続確立から応答を受け取るまでの時間を測定します。プロキシ経路上のHTTPまたはHTTPS接続性に近い結果ですが、あくまで少量通信によるテストであり、継続的なダウンロード速度を直接示すものではありません。

同じノードを連続してテストしても、結果が変わることがあります。原因として、ローカルWi-Fiの揺らぎ、通信事業者の混雑、プロキシサーバーの負荷、国際経路の変化、DNS名前解決の時間、テスト先の応答速度などが挙げられます。初回は名前解決、TCP接続、TLSハンドシェイクのコストが含まれ、2回目以降はキャッシュが再利用されるため、数値が低くなる場合もあります。判断するときは最小値だけでなく、複数回の結果の範囲を確認しましょう。

遅延値の読み取り方

• 値が安定している：複数回の結果が近ければ、一覧で最小値でなくても、日常用のノードとして適しています。
• 値の変動が大きい：隣り合うテストで数百ミリ秒も差が出る場合は、経路または負荷が不安定な可能性があるため、引き続き確認が必要です。
• タイムアウトになる：ノードが利用できない可能性もあれば、テスト先にそのノード経由でアクセスできない可能性もあります。1回のタイムアウトだけで設定から削除しないでください。
• 遅延は低いのにダウンロードが遅い：小さなリクエストへの応答が速くても、サーバーの出口帯域が十分とは限らず、混雑時にスループットを維持できるとも限りません。
• 遅延は高いのに再生が安定している：継続的な帯域が十分でパケットロスが少なければ、バッファリング済みの動画は安定して再生できます。

より実用的なのは、3～5回連続でテストして中央値と変動幅を記録する方法です。たとえば2つのノードの中央値がそれぞれ80ミリ秒と110ミリ秒でも、前者が頻繁に600ミリ秒まで跳ね上がり、後者が常に100～130ミリ秒で安定しているなら、後者のほうが会議、リモート端末、継続的なブラウジングに適しています。

すべてのノードが同時にタイムアウトする場合は、まずサブスクリプションが更新済みか、設定が正常に読み込まれているか、端末のネットワークが正常か、Clashコアが動作中かを確認します。特定のプロキシグループだけがタイムアウトする場合は、グループ内のノードが有効かも確認してください。TUNモードを有効にしても、ノードの遅延が自動的に下がるわけではありません。TUNは通信をプロキシコアへ渡す方法を変えるだけで、実際の経路品質はローカルネットワーク、ノードサーバー、接続先ネットワークによって決まります。

REGION AND ROUTE

地域と実際のネットワーク経路で選ぶ

地域ラベルはノードサーバーまたは入口の所在エリアを示しますが、地理的な距離は遅延を左右する要因の一つにすぎません。どの通信事業者を経由するか、迂回経路になっているか、入口と出口が分離されているかによって、実際の結果は変わります。近い場所のノードでも相互接続品質が低ければ遅延が大きくなることがあり、遠いノードでも安定した経路によってジッターが小さい場合があります。

日常用ノードを選ぶときは、まず地理的に近い地域からテストし、異なる地域の候補を1～2個予備として残します。候補をすべて同じ地域に集中させると、地域的な障害、サーバーメンテナンス、夜間の混雑が複数ノードに同時に影響する可能性があります。予備ノードは使わずに放置するものではなく、メインノードが連続してタイムアウトしたり速度低下したりしたとき、すぐ切り替えるためのものです。

地域選びでよく使う判断基準

ノード名に含まれる地域情報だけでは、ネットワーク経路を正確に把握できない場合があります。中継入口を使うサービスでは、ノード名が出口地域を示していても、端末が最初に接続する入口は別の場所にあることがあります。また、名前に回線コードや通信事業者の略称が含まれる場合もあります。確認できないときは、実際のテスト結果とサービス提供元のノード説明を基準にしてください。

「対象サービスの地域」と「プロキシノードの地域」も区別する必要があります。グローバルCDN上のWebサイトへアクセスする場合、ノードによっては出口に近いエッジサーバーへ割り当てられるため、出口地域が配信経路に影響します。地域指定のない日常利用では、安定していて経路が短いノードを優先し、対象サービスが地域に依存するときだけ出口位置を最優先条件にします。

TRAFFIC RATE

倍率と実際の通信量コストを確認する

ノード倍率は通常、サブスクリプションサービスが採用する通信量の課金係数であり、Clashプロトコル自体の属性ではありません。1倍のノードで1GB通信すると、一般的にはプランの1GBとして計上されます。2倍なら同じ通信量でも2GBとして計算される場合があります。集計範囲や計算方法はサービスの説明に従ってください。Clashクライアントは設定されたノードを利用するだけで、倍率のルールを一律に定義するものではありません。

倍率が高いからといって、必ずしも速度が速いとは限りません。高倍率は、コストの高い回線、混雑の少ない入口、特定地域のリソースに対応している場合がありますが、ノードの現在負荷は変動します。一方、低倍率のノードでも、混雑していない時間帯なら十分な速度が出ることがあります。倍率はコスト指標として扱い、遅延、安定性、スループットとは分けて評価しましょう。

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

1. 日常のブラウジングやメッセージ通信では、安定した標準倍率のノードを優先し、頻繁な手動切り替えを避けます。
2. OSイメージ、ゲームの更新、クラウド同期は通信量が多くなるため、まず残りの通信枠を確認し、低倍率ノードの継続速度を比較します。
3. 地域や回線に明確な要件がある一時的な作業では、高倍率ノードを使い、完了後に標準のポリシーへ戻します。
4. 速度テスト自体も通信量を消費します。大容量ファイルによるテストを連続して行うと使用量が急増するため、すべてのノードで繰り返すのは避けてください。

PROTOCOL REVIEW

代表的なプロキシプロトコルとクライアント対応を比較する

サブスクリプションには、Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUICなどのノードが同時に含まれることがあります。プロトコルは接続・転送方式を決めますが、プロトコル名だけでノードの速さを証明することはできません。サーバーの場所、回線帯域、混雑状況、トランスポート層の設定、クライアントコアのバージョンのほうが大きく影響することもあります。

Shadowsocks

Shadowsocksの設定は比較的シンプルで、一般的なClashコアは複数の暗号化方式に対応しています。実際に使えるかどうかは、クライアントコアが指定された暗号方式や拡張形式をサポートしているかに左右されます。インポート後にcipher、plugin、unsupportedなどのエラーが出る場合は、遅延テストを繰り返す前にコアの対応状況を確認してください。

VMessとVLESS

VMessとVLESSは、TCP、WebSocket、gRPC、TLSなどのトランスポート設定と組み合わせて使われることがあります。VLESSだからといって回線品質が決まるわけではなく、Reality、TLSなどの安全な通信パラメータもコアが正しく対応している必要があります。旧版のClashコアと、Clash Metaを基盤とし現在はmihomoと呼ばれるコアでは、プロトコルや拡張機能の対応範囲が異なる場合があります。サブスクリプションに新しいフィールドが含まれている場合は、その設定形式を引き続きサポートするクライアントとコアを使用してください。

Trojan

Trojanは通常TLS接続上で動作し、設定にはサーバー名、証明書検証、トランスポート層のパラメータが含まれます。端末の時刻ずれ、ドメイン名解決の異常、サーバー証明書の問題などでハンドシェイクに失敗することがあります。この種の障害はノード接続を確立できない状態として現れるため、単なる高遅延と誤認しないでください。

Hysteria2とTUIC

Hysteria2とTUICはUDPベースの転送設計を採用しており、高遅延またはある程度のパケットロスがあるネットワークで高いスループットを得られる場合があります。ただし、ローカルネットワーク、ルーター、通信事業者の経路がUDPを正常に通せることが前提です。企業ネットワーク、公衆Wi-Fi、ファイアウォールによってUDPが制限されると、ノードがタイムアウトすることがあります。その場合はTCPベースの候補へ切り替えると、問題の原因を切り分けやすくなります。

プロトコル選びでは互換性を優先します。まずクライアントコアが設定を解析して接続を確立できることを確認し、その後で使用感を比較してください。複数のプロトコルノードが同じ入口と近い経路を使う場合、実際の差は小さいことがあります。プロトコル名が新しいというだけで標準に設定する必要はなく、エラーログがない状態でサブスクリプションが生成したプロトコルパラメータをむやみに変更するのも避けてください。

PROXY GROUPS

Clashのプロキシグループで自動選定する

ノード数が多い場合は、プロキシグループを使うと手動切り替えを減らせます。Clashやmihomoの設定でよく使われるグループには、select、url-test、fallback、load-balanceがあります。それぞれ解決する問題が異なるため、グループ名だけで動作を判断することはできません。

• select：ユーザーがノードまたは下位のプロキシグループを手動で選択します。標準の出口や特定地域の選択に適しています。
• url-test：候補ノードを定期的にテストし、結果に基づいて条件を満たす低遅延ノードを選択します。
• fallback：候補を順番に確認し、先頭のノードが利用できない場合に後続のノードへ切り替えます。
• load-balance：設定した方式に従って複数のノードへ異なる接続を割り当てます。1つのダウンロード接続の帯域を単純に合算する機能ではありません。

簡単な自動テストグループは、次のような構成にできます。実際に利用できるフィールドは使用するコアのバージョンによって異なり、ノード名は設定内のプロキシ項目と一致している必要があります。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - HK-01
      - SG-01
      - JP-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval はテスト間隔を制御します。短すぎるとリクエスト回数とリソース消費が増えます。tolerance は遅延差が小さい場合の頻繁な切り替えを抑えるために使います。切り替え条件やヘルスチェック用フィールドの実装はコアのバージョンによって異なる場合があるため、変更前に現在使用しているコアの設定仕様を確認してください。

自動選択には、候補ノードの品質と地域・用途が近いグループを使います。異なる地域、倍率、用途のノードをすべて1つのurl-testグループに入れると、遅延が最小のノードが地域要件に合わなかったり、通信量コストが高くなったりする可能性があります。地域または用途ごとに分けてからグループ内で自動テストし、最上位でselectを使って「自動ノード」「特定地域」「手動選択」を選ぶ構成が合理的です。

ルールモードでは、ドメイン、IP、プロセスなどのルールに基づき、接続を指定したプロキシグループへ送ります。ノード選択が決めるのは、最終的にグループが使う出口だけであり、ルールが上から順に評価され、マッチ後に停止する基本動作は変わりません。特定のWebサイトが想定したノードを経由しない場合は、ノードを交換するだけでなく、ルールのマッチ結果とプロキシグループの現在の選択も確認してください。

TEST PROCESS

再現性のあるノード選定手順を作る

信頼できる比較を行うには、ローカルネットワークの条件と時間帯をなるべく揃えます。Wi-Fiでテストする場合は、まず端末の電波が安定していることを確認し、バックグラウンドの大容量ダウンロード、クラウド同期、システム更新を停止します。モバイル回線と固定回線では経路が異なるため、あるネットワークで最速のノードが、別のネットワークでも優位とは限りません。

1. サブスクリプションを更新：クライアントに最新の設定が読み込まれていることを確認し、停止済みまたはパラメータが変更されたノードをテストし続けないようにします。
2. グループ全体の接続テストを1回実行：継続的にタイムアウトするノード、ハンドシェイクできないノード、未対応の設定を持つノードを除外します。
3. 候補を絞る：対象地域から、遅延が比較的低く変動の小さいノードを3～5個残します。
4. 繰り返しテスト：数十秒間隔で複数回テストし、遅延の中央値、最大値、タイムアウト回数を確認します。
5. 実際の用途で検証：普段使うWebサイトを開く、動画を再生する、短時間ダウンロードするなどして、読み込み、スループット、再接続の状況を確認します。
6. 倍率と通信枠を確認：使用感が近い場合は、通信量コストが適切なノードを優先します。
7. 予備ノードを残す：異なるサーバーまたは地域の候補を確保し、メインノードの障害時に全リストから選び直す手間を省きます。

テスト結果は時間帯ごとに記録するのがおすすめです。午前中は安定しているのに夜間に明らかに速度が落ちるノードは、ピーク時の負荷やネットワーク相互接続の変化が原因と考えられます。深夜に1度だけ速度を測っても、日常の利用時間帯を代表する結果にはなりません。仕事で使う場合は、午前、午後、夜間に短時間のテストを行い、1～2日観察してから標準ノードを決めましょう。

ノードを切り替えても、既存の接続がすぐ新しいノードへ移行するとは限りません。ブラウザーの接続プール、ダウンロード、動画セッション、端末の長時間接続は、接続が閉じるかタイムアウトするまで以前の出口を使い続ける場合があります。新しいノードを検証するときは、テストページを開き直すか、関連する接続を再起動してください。システムプロキシやTUNを有効にしている場合は、対象アプリの通信が本当にClashへ入っているかも確認します。クライアント画面でノードを選択しただけでは、すべてのアプリがそのノードを使うとは限りません。

ERROR CHECK

よくある誤判断と対処法

一覧で遅延が最小のノードだけを選ぶ

最小値は偶然のテスト結果か、テスト先の応答だけを反映している可能性があります。テスト回数を増やし、普段使うサービスでも確認してください。最小遅延のノードが頻繁に切断されるなら、少し遅くても安定したノードのほうが標準の出口に適しています。

速度テストに失敗したらサブスクリプションが無効だと判断する

1つのノードの失敗と、サブスクリプション全体の無効化は別の問題です。まず他のノードに接続できるかを確認し、クライアントログでDNS、ハンドシェイク、タイムアウト、未対応プロトコル、ネットワーク到達不可などの情報を確認します。すべてのノードが同時に失敗した場合に、サブスクリプションの更新、設定の読み込み、ローカルプロキシの状態を詳しく調べてください。

ノードを切り替えてもアクセスできない

原因はノードではなくルールにある可能性があります。現在のモードがルール、グローバル、ダイレクトのどれかを確認し、対象接続がどのプロキシグループにマッチしたかを確認してください。DNSキャッシュ、ブラウザーの既存接続、対象サービス側の障害によっても、切り替え後すぐに復旧しないことがあります。まず既存の接続を閉じ、別の正常確認済みWebサイトで比較テストを行うと切り分けやすくなります。

TUNモードを高速化機能と考える

TUNモードは、システムプロキシ設定に従わない通信をより広く取り込むための機能です。ゲーム、コマンドラインプログラム、特定アプリの通信をより完全にカバーできる場合がありますが、プロキシサーバーの帯域を増やすものではありません。有効化後に使用感が変わるのは、通信経路やDNS処理方式が変わったためであることが多いです。異常が起きた場合は、TUNの権限、ルーティング、DNS、アプリの互換性を確認し、速度テストの頻度を上げ続けないでください。

1回の大容量ファイルテストで通信量を使いすぎる

大容量ファイルは継続スループットを測定できますが、すべてのノードで実行する必要はありません。まず小さなリクエストで候補を絞り、その後2～3個のノードで短時間の実ダウンロードを行います。テスト後は速やかに停止し、クライアントの通信量統計とサブスクリプションの管理画面で使用量を確認してください。