Clashのノード選び方

用途で絞ってから遅延を比較

Clashのノード一覧にある名前、遅延、倍率は、それぞれ異なる情報を示します。地域は出口の場所やサービスの利用可否に関わり、倍率はサブスクリプションの通信量消費に影響します。プロトコルはコアとの互換性や通信条件に関係し、遅延は特定の測定時点における応答状況を表します。すべてのノードをミリ秒順に並べても、今の用途に最適なノードがわかるとは限りません。

まずクライアントで、現在のプロファイルが有効になっていることを確認し、「プロキシ」または「プロキシグループ」を開きます。画面上の名称はクライアントによって異なるため、グループ名、グループタイプ、接続ログをもとに判断してください。ノードを切り替える前に、操作中のグループが対象サイトのルールから参照されているか確認しましょう。現在の接続に使われていない予備グループを変更しても、通信経路は変わりません。

1. 用途を決める：Web閲覧、動画視聴、リモート操作、大容量ファイルの転送では、求められる接続条件が異なります。
2. 出口地域を絞る：まず対象サービスが利用可能な地域のノードを残します。地域制限がなければ、遅延と安定性を比較しましょう。
3. コストを確認する：サブスクリプション提供元の倍率と課金方法の説明を確認し、長時間の利用に向かないノードを除外します。
4. 通信方式を確認する：現在のコアがプロトコルに対応しているか確認します。UDPが必要なアプリでは、UDPの通信経路も検証してください。
5. 実際の接続を比較する：同じネットワーク、同じ接続先、近い時間帯で再測定し、最後にメイン用と予備用の出口を1つずつ残します。

遅延テストでわかること

HTTPテストは単純な往復時間ではない

Clashやmihomoの遅延テストでは、指定したプロキシ経由でテストURLにリクエストを送る方法が一般的です。ノードサーバーにICMP Pingを送る方法とは異なります。測定結果には、端末から入口までの経路、プロキシのハンドシェイク、出口からテストサイトまでの経路、テスト先の応答が影響します。DNSやTLS、接続の再利用が測定に含まれるかどうかは、コアの実装やそのときの接続状態によって異なります。

たとえば画面に80ミリ秒と160ミリ秒と表示されても、比較できるのはテストURL、ネットワーク環境、測定方法が同じ場合に限られます。この数値は比較方法を示す例であり、本サイトでの実測値ではありません。テストサイトに近い出口がその測定で優れていても、実際に利用するサービスのサーバーに近いとは限りません。

条件をそろえて再測定し、1回の結果だけで判断しない

一度に比較する候補は少数に絞り、同時測定でローカルの接続を使い切らないようにします。同じネットワークで3回測定し、各回の間隔を約30秒空けて記録する方法があります。これは推奨する操作例であり、性能を保証するものではありません。最小値だけでなく、中央値やタイムアウトの回数も見ましょう。夜間の利用状況を確認したい場合は、実際に使う時間帯に再測定してください。

測定中は大容量ファイルの同期を一時停止し、テストURLも変えないでください。すべてのノードが同時にタイムアウトする場合は、ローカルネットワーク、テストサイト、サブスクリプションの有効期限を先に確認します。特定のノードだけ失敗が続く場合は、そのノードのプロトコル設定やサービス状況を確認しましょう。1回のタイムアウトを理由にDNS、TUN、すべてのルールを同時に変更すると、原因を特定しにくくなります。

通信量倍率とサブスクリプション残量

倍率は通常、サブスクリプション提供元が定める課金ルールであり、Clashのプロトコル項目ではありません。ノード名に「0.5x」「1x」「2x」と書かれていても、提供元が名前に付けた表示である可能性があり、クライアントはその名前だけを見て課金方法を決めません。実際の倍率、上り・下りの両方が残量に加算されるか、集計方法や反映時期は、提供元の案内とアカウントの利用明細で確認してください。

倍率が高くても遅延が小さいとは限らず、帯域幅が広いとも限りません。高倍率は特定の回線コストや地域のリソースに関連する場合もあるため、実際に確認が必要です。OSイメージのダウンロード、写真の同期、長時間の動画視聴では、まず必要な性能を満たす低倍率のノードを探しましょう。リモート操作では応答性と安定性を重視し、予算に余裕があれば用途に合う経路を選びます。

• 倍率の異なるノードを初めて使うときは、アカウントの残量を記録してから、通信量を管理しやすい範囲で転送を行い、提供元の集計が更新された後に照合します。
• クライアントの接続画面に表示される1回分の通信量を、提供元の利用明細の代わりにしないでください。計測地点が異なる場合があります。
• 複数の端末でサブスクリプションを共有している場合は、ほかの端末の通信量も考慮しましょう。含めずに比較すると、誤った結論につながりやすくなります。

ノードの地域は名前だけでなく出口で確認

ノード名に含まれる地域名は、サブスクリプション提供元が設定したもので、入口、出口、または回線グループを指す場合があります。香港の入口を経由して日本の出口からサイトに接続した場合、通常、接続先サイトに見えるのは日本の出口IPアドレスです。物理的な距離が近くても経路が短いとは限らず、事業者間の接続や中継経路の設計も実際の通信品質に影響します。

地域を確認する3つの方法

1. 通信の出口を確認する：クライアントの「接続」画面で対象ドメインを探し、適用されたルール、プロキシグループ、最終的なノードを確認します。
2. 出口IPアドレスを調べる：同じブラウザーで信頼できるIPアドレス確認サービスにアクセスし、表示されたグローバルIPアドレスと地域を記録します。確認リクエストがDIRECTに振り分けられていないことを先に確認してください。
3. 対象サービスで確認する：実際に利用するサイトで使えるか確認します。IPアドレスのデータベースには反映の遅れがあり、サービスによって地域判定が異なる場合もあります。

確認サービスに正しい地域が表示されても、対象サービスで地域制限のメッセージが出る場合は、アカウントの登録地域、支払い情報、過去のセッション、サービス独自のポリシーも確認してください。ノード名に同じ地域名が付いた別のノードに変えても、制限が解消するとは限りません。ノード名だけでは、IPアドレスの種類、サービスの利用可否、アカウント利用規約への適合性は確認できません。

長期間ログインするサービスでは、出口地域をできるだけ固定してください。地域を頻繁に切り替えると追加認証が求められることがあります。また、ノードを切り替えても既存のTCP接続は通常、新しいノードへ自動的に移りません。新しい出口を確認するには、接続を張り直す必要があります。既存の接続を終了するかどうかは、ダウンロード、通話、リモートセッションを中断できるかを考慮して判断しましょう。

プロトコルは互換性とUDPを優先して確認

Shadowsocks、Trojan、VMess、VLESS、Hysteria2、TUICなどは、異なるプロキシプロトコルや伝送方式を示す名称であり、速度のランクではありません。対応状況はクライアントに搭載されたコアとそのバージョンによって異なります。Clash Meta（mihomo）コアを搭載したクライアントと、開発が終了した旧Clashクライアントでは、対応範囲を同じものとして扱えません。

設定をインポートしたときに未対応のプロキシタイプ、解析エラー、ハンドシェイクエラーが発生した場合は、まずクライアントの「バージョン情報」やコア情報で実際のコアを確認し、設定の要件と照らし合わせてください。アプリ名だけで判断したり、意味を理解しないままtype、network、SNI、TLSの設定を変更したりしないでください。

Hysteria2とTUICはQUICベースの通信を使うため、基盤となるUDP通信が利用できる必要があります。ネットワークによってはUDPが制限され、プロトコルに対応していても接続できないことがあります。逆に、ノード経由でWebのTCP通信ができても、ゲームや音声通話のUDP通信に使えるとは限りません。

システムプロキシは通常、すべてのアプリのUDP通信を自動的に取り込みません。システムプロキシに従わないアプリでは、TUNまたはアプリ独自のプロキシ設定がその通信をカバーしているか確認してください。ノード設定でudp: trueを有効にしていても、サーバー側の対応に加え、クライアントによる通信の取り込みとルールによる正しい振り分けが必要です。通常のネットワーク変動への対処として、証明書の検証を無効にしないでください。

手動選択と自動測定の使い分け

selectは出口を固定して手動で選ぶ場合に適しています。url-testは、条件の近い候補ノードから測定結果に基づいて自動選択する場合に使えます。ただし、後者がサブスクリプションの倍率、アカウントの地域要件、対象サービスの利用可否まで判断するわけではありません。倍率の異なるノードや地域要件が合わないノードを同じ自動選択グループに入れると、数値上は良くても用途に合わないノードへ切り替わることがあります。

以下は既存のプロファイルに統合して使うmihomoのプロキシグループ設定例で、完全な設定ファイルではありません。日常-Aと日常-Bは、現在の設定に実在するノード名に置き換えてください。また、2つのノードで倍率と出口の要件が同じであることを事前に確認します。テストURLへのリクエストはコアから送信されるため、現在のネットワークとプロキシ経路の両方で安定してアクセスできるURLを選びましょう。

proxy-groups:
  - name: 日常自動
    type: url-test
    proxies:
      - 日常-A
      - 日常-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日常選択
    type: select
    proxies:
      - 日常自動
      - 日常-A
      - 日常-B

interval: 300は自動測定の間隔が300秒であることを示します。tolerance: 50は50ミリ秒の切り替え許容値で、遅延が近いノード間で頻繁に切り替わるのを抑えるための設定です。許容される遅延の上限ではありません。この設定だけですべての通信が自動的にこのグループを使うわけではなく、接続をこのグループに振り分けるには、既存のルールから日常選択を参照する必要があります。

たとえば、DOMAIN-SUFFIX,example.com,日常選択というルールは、ドメインの末尾が一致する接続をこのプロキシグループに振り分けます。ルールは通常、上から順に照合されます。前のルールに一致した接続は、後続のルールでは処理されません。詳しい構文はプロキシグループの設定方法をご覧ください。

用途に合わせて最後に動作確認

Web閲覧・リモート操作：応答の安定性を重視

一般的なWeb閲覧では、倍率が低く、連続測定が安定しているノードを優先できます。SSH、リモートデスクトップ、管理画面では応答性と接続の継続性が重要です。自動切り替えがトラブル調査の妨げにならないよう、手動で出口を固定する方法がおすすめです。ノードのテストが正常でもターミナルが切断される場合は、接続先サーバー、ファイアウォール、アイドル接続のタイムアウトも確認してください。

動画視聴・ダウンロード：転送の継続性とコストを重視

動画では、まず対象サービスで正常に再生できるか確認し、バッファリングが続かないか観察します。大容量ファイルのダウンロードは、開始直後の速度だけで判断せず、同じ配信元から一定時間ダウンロードして比較してください。速度測定サイトでのスループットを、すべてのダウンロード元で得られる性能と見なさないようにしましょう。繰り返し測定してサブスクリプションの通信量を大量に消費することも避けてください。

ゲーム・音声通話：UDP経路を個別に確認

まずゲームや音声通話のアプリが実際にプロキシ経由になっているか確認し、そのうえでアプリに表示される遅延、ジッター、パケットロスを確認します。Webのテストが成功しても、初期確認の目安にしかなりません。ノードを切り替えても変化がない場合は、手当たり次第にプロトコルを変えるのではなく、ルールがDIRECTのままになっていないか、アプリが以前の接続を使い続けていないかを確認してください。

1. 安定して使えるメインノードと、動作確認済みの予備ノードを1つずつ保存し、それぞれの地域と倍率を記録します。
2. 対象サービスに接続し、グループ内で選択中の表示だけでなく、クライアントで実際の出口を確認します。
3. 実際の用途での動作を確認し、アカウント残量の変化が想定どおりか照合します。
4. 問題が起きたら、ノード、通信の取り込み方法、ルール、DNSのうち一度に1項目だけ変更し、その都度動作を確認します。

ノード選びでは、まず用途と地域の条件を満たし、倍率が許容範囲内で、プロトコルと通信の取り込み方式に互換性があることを確認します。そのうえで遅延と実際の安定性を比較しましょう。ミリ秒の数値は候補を絞る目安にはなりますが、あらゆる用途のノードをそれだけで決めることはできません。