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

まず通信経路を確認：ノードの選択が反映されているか

ノードを選ぶ前に、対象の通信が設定変更中のプロキシグループを実際に通っているか確認しましょう。Clashのルールモードでは、rulesが上から順に評価されます。ブラウザーの通信がDIRECTに一致している場合、プロキシノードを変更しても通信経路は変わりません。動画配信サービス向けのルールが独立したプロキシグループを参照していて、ホーム画面の既定グループとは無関係な場合もあります。

1. クライアントの「設定」または「Profiles」を開き、別の設定を更新しただけではなく、現在有効なサブスクリプション設定を確認します。
2. 「プロキシ」または「Proxies」で、ルールが実際に参照しているプロキシグループを見つけ、まずノードを1つ手動で選択します。
3. 対象サイトにアクセスした後、「接続」または「Connections」を開き、対象ドメイン、適用されたルール、送信経路を確認します。メニュー名はクライアントによって異なりますが、この3項目の確認がポイントです。
4. ノードを切り替えたら、新しい接続を確立してからテストします。既存のTCP長時間接続は通常、自動では切り替わりません。必要に応じて元の処理を停止し、再接続してください。

遅延は安定性で選ぶ：最低値だけで判断しない

クライアントに表示される遅延は、通常、ノード経由でテストURLにアクセスして測定した値です。端末からノードサーバーまでの単純なICMP遅延でも、ダウンロード速度でもありません。テスト先、DNS、接続確立、プロトコルのハンドシェイク、接続の再利用、コアの実装などによって結果は変わります。数値を比較するなら、同じネットワーク、同じテスト先で測定したノード同士を比べましょう。

5回測定して候補ノードを絞り込む

候補を3つ選び、約30秒おきに計5回測定します。大容量ダウンロードを同時に実行するのは避け、タイムアウトも記録してください。成功した測定の最低値だけを残してはいけません。以下は判断方法の例であり、本サイトが各サービスを実測したデータではありません。

上の例では、普段使いならBで25 msが出たことだけを理由に選ぶのではなく、まずAを試します。接続先サービスの地域要件を満たすなら、不安定なBよりCのほうが適している場合もあります。測定のタイムアウトだけでパケット損失率を断定することはできません。損失の判断には、ネットワーク診断と実際の接続状況も確認してください。

夜の混雑時間帯にも実際の通信をテストする

• Web閲覧：よく使うページを5つ続けて開き、初回表示や画像、スクリプトの読み込みで何度も待たされないか確認します。
• 動画：同じ動画を同じ画質で再生し、再生開始の速さだけでなく、3分間のバッファリング状況を確認します。
• ダウンロード：同じ合法的なテストファイルを使い、開始直後の速度と60秒間の速度をそれぞれ記録します。帯域を奪い合う複数タスクの同時実行は避けましょう。

日中は問題ないのに夜間に大きく遅くなる場合、回線やサーバーの負荷変動が原因として考えられます。プロトコルを変更しても解決するとは限りません。まず別の回線を比較し、普段使う時間帯に再測定してください。

通信量倍率：使用量を見積もってから速度を比べる

ノード名にある「0.5倍」「1倍」「2倍」は、一般にサブスクリプションサービスの課金倍率を示すもので、Clashコア共通の速度制限設定ではありません。ノード名に「2倍」と書かれていても、ダウンロード速度が2倍になるわけではありません。最終的な通信量の計算方法はサービス提供元の案内とアカウントの使用量記録で確認してください。アップロードとダウンロード、または特定の時間帯を別々に集計するサービスもあります。

単位をそろえて通信量を見積もる

「課金対象の通信量 × 倍率」で計算され、1回の作業で2 GiB使うと仮定すると、0.5倍なら約1 GiB、1倍なら約2 GiB、2倍なら約4 GiBが消費されます。あくまで計算例です。プロトコルのオーバーヘッド、双方向の課金、GBとGiBの単位差などにより、アカウントの記録とローカルファイルのサイズは異なる場合があります。

• Web閲覧・メッセージ：通常は通信量倍率より安定性を優先します。
• 動画・大容量ファイル：まず月間使用量を見積もり、必要な通信量を安定して使える低倍率のノードを選びます。
• 一時的な重要作業：倍率が高くても安定した候補を使い、作業後に普段使いのノードへ戻す方法があります。

地域の選び方：地理的な近さだけでなく、出口と接続先を見る

ノード名に記載された地域は、通信の出口の場所を示す場合もあれば、サービス提供元が付けた回線ラベルにすぎない場合もあります。入口サーバー、中継回線、最終的な出口がそれぞれ異なる地域にあることもあります。端末から近い地域のノードが最速とは限りません。通信事業者間の接続、迂回経路、ピーク時の混雑によって結果は変わります。

普段使いのWebサイトと動画配信では判断基準が異なる

普段のWeb閲覧では、まず近隣地域の安定した回線を試し、実際のページ表示を比較します。動画配信では、アカウントの地域、出口IPアドレス、コンテンツの配信権、サービス利用規約の要件を先に確認してください。出口が特定の国や地域と判定されても、その地域向けのすべてのコンテンツを再生できるとは限りません。

1. 候補ノードを1つ手動で固定し、対象ドメインが想定したプロキシグループに振り分けられているか確認します。
2. その出口経由でIPアドレスと地域を確認し、続けてサービスの再生ページで動作を確認します。
3. 画質を固定して3分以上再生し、バッファリングの繰り返し、画質の低下、地域に関するメッセージがないか確認します。
4. ページ表示と再生結果が異なる場合は、すぐにノードの障害と判断せず、メディアのドメインが別のルールで振り分けられていないか確認してください。

開発用途でも、接続先に合わせた検証が必要です。コードホスティング、パッケージリポジトリ、コンテナイメージでは異なるCDNが使われる場合があり、トップページの表示が速くても依存関係の取得が速いとは限りません。ログイン状態を安定して保ちたいサービスでは、出口地域をなるべく固定し、自動選択グループが異なる地域へ頻繁に切り替わるのを避けましょう。

プロトコルの選び方：まず互換性を確認し、UDPとネットワーク環境をチェック

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUICは、異なるプロキシプロトコルまたは方式の名称であり、速度のランクではありません。同じプロトコルでも、回線の違いによって使用感は大きく変わります。まずクライアントに搭載されているコアが、そのプロトコルと設定パラメーターに対応しているか確認してください。旧版ClashとClash Meta（mihomo）では、対応範囲が異なります。

Hysteria2とTUICはQUICをベースとしており、UDP通信が利用できるネットワーク経路が必要です。UDPが制限されるネットワークでは接続できなかったり、動作が不安定になったりする場合があります。一般的なTCPベースのプロキシ通信も、混雑や回線品質の影響を受けます。プロトコル名だけでは実際の性能を判断できず、「最速のプロトコル」の一律ランキングにも適しません。

Webサイトは開けるのに音声通話やゲームが失敗する場合は、UDP、TUNによる通信の取り込み、振り分けルールを確認してください。クライアントに未対応のプロキシ形式と表示された場合は、まずコアの互換性を解決しましょう。証明書検証の無効化を万能な対処法として使ってはいけません。サブスクリプションの認証情報、サーバーアドレス、通信パラメーターはサーバー側の設定と一致している必要があります。

プロキシグループの設定：普段使いは自動選択、重要な作業は手動で固定

url-testは、測定結果に基づいて候補から自動選択するのに適しています。ただし、通信量倍率や動画の配信権、開発作業の成否は確認しません。地域や倍率の異なるノードをすべて同じ自動選択グループに入れると、測定遅延は低くても実際の用途に合わないノードが選ばれる場合があります。

mihomoの設定例

以下はproxy-groupsの一部のみを示しています。現在の設定のproxiesに、名前が完全一致するJP-AとSG-Aの2つのノードが登録済みであることを前提としています。実際のノード名に置き換えて既存の設定に統合し、同じYAML内にトップレベルのproxy-groupsを重複して追加しないでください。

proxy-groups:
  - name: Daily
    type: select
    proxies:
      - Auto
      - JP-A
      - SG-A

  - name: Auto
    type: url-test
    proxies:
      - JP-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• type: select：手動選択です。普段使いにはAuto、長時間のダウンロードやログイン状態に影響する作業には単一ノードの固定が適しています。
• interval: 300：自動測定の間隔は300秒です。サブスクリプションの更新間隔ではありません。
• tolerance: 50：切り替え判定に使う許容差で、単位はミリ秒です。小さな遅延差による頻繁な切り替えを抑えるための値であり、速度制限やタイムアウトのしきい値ではありません。
• url：安定してアクセスできる軽量なHTTPSテスト先を指定します。テスト先を変更した場合、新旧の測定値をそのまま比較するのは適切ではありません。

上記の項目はmihomoで一般的な設定例です。他のコアを使う場合は、対応するドキュメントを確認してください。また、対象の通信に適用するにはルールからDailyを参照する必要があります。プロキシグループを作成しただけでは、通信の振り分けは変わりません。プロキシグループの設定項目で構造を確認し、ルールの設定項目で参照関係を確認してください。

用途に合わせて絞り込む：メインと予備のノードを残す

最終的には、普段使いのノードを1つ、別回線の予備を1つ残せば十分です。測定日、使用ネットワーク、対象の作業、倍率、結果を記録しておきましょう。問題が起きたら、同じ作業で予備回線をテストします。すべてのノードが同時に遅くなった場合は、候補を増やすのではなく、ローカルネットワーク、通信の取り込み方式、DNS、現在の設定を優先して確認してください。

選び方の手順は次のとおりです。まず通信が正しいプロキシグループを通っているか確認し、安定性で候補を絞ります。地域要件があればサービスで動作を確認し、なければ遅延を比較します。大容量の作業では通信量倍率を計算し、最後に対応しているプロトコルの中から選びます。