まず選ぶ順番を決める
ノード一覧で目立つのは地域名と遅延の数値ですが、最小遅延だけで選ぶことはできません。遅延は応答速度を示すもので、ダウンロード帯域を直接表すわけではありません。倍率は通信量アカウントの消費量に影響しますが、回線品質を示すものではありません。地域はアクセス経路とコンテンツの対象地域を左右し、プロトコルは互換性、ハンドシェイクの負荷、ネットワークへの適応性に関係します。4つの指標はそれぞれ異なる問題を判断するためのものです。
安定した選び方は、まず用途に合わせて地域を絞り、タイムアウトやパケットロスの多いノードを除外し、次に夜間の混雑時間帯の速度を比較し、最後に倍率とプロトコルを確認することです。これにより、遅延は低いのに実際のダウンロードが遅い混雑ノードや、数ミリ秒の差のために高倍率回線を使い続ける状況を避けられます。
1分でできる選び方
- ウェブ閲覧では、まず距離の近い香港、日本、シンガポールのノードをテストします。
- ストリーミングでは、先にコンテンツの対象地域に対応するノードを選び、アカウントとコンテンツが利用できるか確認します。
- 同じ地域で遅延が低いノードを3つ選び、1位だけを残さないようにします。
- それぞれ5回連続でテストし、タイムアウト、変動幅が100msを超えるもの、頻繁に数値が跳ね上がるものを除外します。
- 同じダウンロード元を使って30秒間テストし、開始直後の瞬間的なピークではなく、安定した速度を記録します。
- 速度が近い場合は、倍率が低く、現在のネットワークと互換性の高いプロトコルを使うノードを選びます。
たとえば、香港Aは遅延42ms、ダウンロード速度18MB/s、倍率1.5、香港Bは遅延58ms、ダウンロード速度27MB/s、倍率1.0とします。普段のウェブ閲覧では応答差は目立ちませんが、継続的なダウンロードにはBが適しています。Aが夜間の混雑時間帯でもジッターを低く保ち、Bが頻繁に2MB/sまで低下するなら、普段使いのノードをAに戻します。
遅延の数値をどう見るか
Clashクライアントの遅延テストでは通常、プロキシノード経由でテストURLへアクセスし、接続またはHTTPリクエストの完了にかかった時間を記録します。完全な帯域テストではなく、従来のICMP Pingと同じものでもありません。ノード側がICMPを禁止していてもプロキシ接続は正常な場合があります。逆に、遅延テストが40msでも、大容量ファイルのダウンロードが速いとは限りません。
遅延・ジッター・パケットロスの意味
- 遅延:1回のリクエストが往復するまでの時間で、通常はms単位で表します。数値が低いほど、ページの初回応答や操作の反応が速くなる傾向があります。
- ジッター:複数回のテスト結果に生じるばらつきです。32ms、180ms、70msよりも、50ms、52ms、55msのほうが安定しています。
- パケットロス:データパケットが正常に届かない状態です。継続的なパケットロスは、読み込みの停止、音声の途切れ、接続の再送を引き起こします。
- スループット:単位時間あたりに転送できるデータ量で、一般的な単位はMbpsまたはMB/sです。実際にデータを転送して判断する必要があります。
遅延は用途ごとの目安として判断できます。30msから80msなら、ほとんどのウェブ閲覧、メッセージング、動画再生に適しています。80msから150msでも通常は利用できますが、操作感はやや遅くなります。200msを超えると、ウェブの初回読み込み、リモートターミナル、リアルタイム操作で遅延を強く感じます。これらは品質を保証する基準ではなく、ジッターとパケットロスも合わせて確認してください。
テスト結果の例
45ms / 48ms / 47ms / 51ms / 46ms:平均は約47msで変動も小さいため、実効速度のテストを続けられます。
38ms / 220ms / timeout / 75ms / 310ms:最低値は優秀ですが回線が不安定なため、自動選択の第一候補には向きません。
同じノードでも結果が毎回変わる理由
テストリクエストは、ローカルWi-Fi、通信事業者のアクセス網、国際回線、ノードの入口、テストサーバーを通過します。どこか一箇所が混雑すれば数値は変化します。クライアントが複数ノードのテストを同時に実行すると、ローカルの帯域や接続数も互いに影響します。そのため、一度に全ノードを測定した結果は初期選別にしか使えず、長期的な判断材料にはなりません。
クライアントの「プロキシ」画面でまずノード全体をテストし、その後候補ノードを個別に5回テストするのがおすすめです。Clash Verge Rev 2.xでは通常、「プロキシ」→ポリシーグループを選択→遅延テストを実行、と進みます。ディストリビューションによってボタン名は「速度テスト」「遅延テスト」「URL Test」など異なる場合があります。テスト中は大容量ダウンロードとクラウド同期を停止し、日中と20:00から23:00の結果を分けて記録してください。
倍率の計算方法
倍率は通信量アカウントの課金係数であり、速度の倍率ではありません。倍率2.0のノードで1GBのデータを転送すると、通常はアカウントから2GB分が差し引かれます。倍率0.5のノードなら、通常は0.5GB分です。具体的な集計方法はサブスクリプションサービスによって異なり、アップロードとダウンロードの合計で計算するサービスもあれば、特定回線に個別の倍率を設定するサービスもあります。
| 実際の転送量 | ノード倍率 | 予想される消費量 |
|---|---|---|
| 5GB | 0.5 | 2.5GB |
| 5GB | 1.0 | 5GB |
| 5GB | 1.5 | 7.5GB |
| 5GB | 2.0 | 10GB |
ノード名にある「0.5x」「1x」「2x」は通常、倍率を示しています。ただし、Clashの設定形式自体に統一された倍率フィールドはありません。クライアントが表示するのはサブスクリプション提供元がノード名に記載した文字列であり、アカウント残量を計算するわけではありません。倍率、プランの通信量、リセット日はサブスクリプションサービスのアカウントページで確認してください。
高倍率ノードを使う価値がある場面
- 低倍率ノードが夜間の混雑時間帯に継続して混雑し、高倍率の専用回線が安定した速度を保てる場合。
- オンライン会議、短時間のデモ、ファイル納品などで接続の安定性が明確に求められる場合。
- 対象地域で利用できるノードが少なく、地域アクセスを優先する必要がある場合。
- 通常ノードのパケットロスが目立ち、高倍率回線のルートや入口の品質が優れている場合。
高倍率だからといって必ずしも高品質とは限りません。名称にある「専用回線」「プレミアム」も回線の目印にすぎず、最終的には連続テストで判断します。2つのノードが夜間でも安定して50Mbpsに達し、遅延が62msと70ms、倍率が2.0と1.0であるなら、通常のウェブ閲覧や動画では後者を優先するのが一般的です。
用途に合わせて地域を選ぶ
地域名は通常、プロキシの出口IPの所在地を示すもので、サーバーが通る物理経路全体を示すとは限りません。「日本」と表示されたノードでも、まず現地の中継拠点に接続し、別の地域を経由して日本の出口へ到達する場合があります。地域を選ぶ際は、対象サービス、回線距離、地域制限に注目し、国や地域名を固定的な性能ランクとして扱わないでください。
香港・日本・シンガポール
中国本土の多くのネットワークでは、香港ノードは物理的な距離が近く、遅延はおよそ30msから80msであることが多いため、ウェブ閲覧、メッセージング、一般的なダウンロードに適しています。日本ノードはおよそ50msから120msが一般的で、ソフトウェアリポジトリ、開発サービス、日本向けコンテンツに適する場合があります。シンガポールノードはおよそ70msから150msが一般的で、東南アジア向けサービスに適しており、香港や日本の回線が混雑したときの代替にもなります。
これらの数値は初期選別にのみ使ってください。通信事業者によって国際出口は大きく異なり、同じ都市でも通信会社ごとに結果がまったく変わることがあります。モバイルホットスポットと固定回線も分けてテストし、あるネットワーク環境の結果を別の環境にそのまま当てはめないでください。
アメリカ・ヨーロッパ
アメリカノードは、アメリカの出口を明確に要求するサービス、北米サーバーの管理、地域限定コンテンツに適しています。距離が長いため、遅延はおよそ140msから260msが一般的です。ヨーロッパノードはさらに高く、一部の回線では250msを超えます。動画視聴では、遅延が安定して200msでもプレーヤーのバッファリングによりスムーズに再生できる場合があります。一方、リモートデスクトップ、SSH入力、リアルタイムゲームでは遅さを明確に感じます。
ストリーミングとアカウントの地域
ストリーミングの利用可否は地域だけで決まりません。サービスはIPの種類、出口IPの評判、アカウント登録地域、支払い方法、位置情報の権限などから地域を判定する場合があります。ノードテストに成功してもコンテンツを再生できないときは、ClashのDNS、ポート、ルールを変更する前に、同じ地域の別の出口へ切り替えてください。切り替え後は元の再生ページを閉じて接続を再確立し、古い接続が再利用されないようにします。
プロトコルの違いは気にすべきか
サブスクリプションのノードでは、Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUICなどのプロトコルが使われることがあります。Clash Meta、つまり現在よく使われているmihomoカーネルは、多くのプロトコルと通信オプションに対応していますが、旧版のClashカーネルや古いクライアントではすべてのフィールドを認識できない場合があります。サブスクリプションをインポートしてもノードがまったく表示されない場合は、まずクライアントのカーネルが対象プロトコルに対応しているか確認し、すぐにノードの無効化を疑わないでください。
代表的なプロトコルの選び方
- Shadowsocks:設定が比較的簡単で、互換性の範囲も広いプロトコルです。実際の品質は、暗号化方式、サーバー性能、回線に大きく左右されます。
- Trojan:TLSと組み合わせて使われることが多いプロトコルです。システム時刻のずれ、証明書のドメイン不一致、SNI設定の異常があるとハンドシェイクに失敗します。
- VMessとVLESS:WebSocket、gRPC、TLS、Realityと組み合わせる場合があります。ノードパラメータは完全に一致させる必要があり、アドレスとポートだけをコピーしてはいけません。
- Hysteria2とTUIC:UDPベースの通信は、高遅延またはパケットロスのある回線で良好に動作する場合があります。ただし、ローカルネットワーク、ルーター、通信事業者のUDP方針の影響を受けます。
プロトコル名だけで速度ランキングを決めることはできません。同じ高品質な回線ならShadowsocksノードが、混雑した回線上のHysteria2より速い場合があります。プロトコルの違いを比較するには、同じ回線、サーバー、負荷条件でそろえる必要があります。初心者はプロトコルのために設定を頻繁に変更する必要はありません。まずはサブスクリプションが提供する完全なノードパラメータを使い、実際の接続結果で選んでください。
UDPノードに接続できないとき
Hysteria2やTUICが固定回線では使えるのに、スマートフォンのテザリングではタイムアウトする場合、問題はUDP通信層にある可能性があります。まず同じ地域のTCP系ノードへ切り替えて基本ネットワークを確認し、次にクライアントが対応するmihomoカーネルを有効にしているか確認します。UDP系ノードだけが失敗する場合、システムプロキシのポートを変更し続けても通常は解決しません。
TUNモードを有効にしても、ノードの速度が自動的に上がるわけではありません。TUNはより多くのシステム通信を引き受け、システムプロキシ設定を読み取らないアプリもClash経由にする機能です。ノードの混雑、出口帯域の不足、リモートサーバーの速度制限がボトルネックなら、TUNを有効にしても解消できず、確認すべき通信処理層が増えるだけです。
実測でメインノードを決める
信頼できるテストには条件の統一が必要です。すべての候補ノードで同じネットワーク、同じ端末、同じ時間帯、同じダウンロード元を使います。ノードAでは動画サイト、ノードBではソフトウェアミラーを測定して、そのまま速度を比較してはいけません。ブラウザー拡張機能、システムVPN、ゲーム用アクセラレーター、その他のプロキシアプリも一時的に終了し、通信経路が変わらないようにします。
3段階のテスト手順
- 第1段階、接続テスト:ポリシーグループの全ノードで遅延テストを実行し、2回連続でタイムアウトするノードを除外します。
- 第2段階、安定性テスト:残ったノードをそれぞれ5回測定し、平均遅延、最大遅延、タイムアウト回数を記録します。
- 第3段階、スループットテスト:固定のテストファイルまたは信頼できる速度測定サイトを使い、各ノードを30秒から60秒間継続して測定します。
ノードAの5回の遅延が42、45、47、44、46msで、ダウンロード速度が12MB/sで安定しているとします。ノードBは35、38、190、41、220msで、速度が3MB/sから25MB/sの間で変動しています。Bの最低遅延がより小さくても、日常のメインノードにはAのほうが適しています。動画やファイル転送では、特に継続的な安定性が重要です。
MbpsとMB/sを混同しないでください。速度測定ページに100Mbpsと表示された場合、理論上は約12.5MB/sです。プロトコルのオーバーヘッドやネットワークの変動を考慮すると、実際のダウンロードは9MB/sから12MB/s程度になることがあります。ブラウザーに8MB/sと表示されても、8Mbpsしかないという意味ではありません。
100 Mbps ÷ 8 = 12.5 MB/s
50 Mbps ÷ 8 = 6.25 MB/s
20 MB/s × 8 = 160 Mbps
自動選択ポリシーグループ
設定のurl-testポリシーグループは、ノードを定期的にテストし、条件に合う低遅延ノードを自動選択できます。同じ地域で用途が近い候補ノードの管理に適しています。香港、アメリカ、ストリーミング専用、高倍率のノードをすべて同じ自動グループに入れないでください。テスト遅延だけで、用途に合わない出口へ切り替わる可能性があります。
proxy-groups:
- name: HK-AUTO
type: url-test
proxies:
- HK-01
- HK-02
- HK-03
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
interval: 300は300秒ごとにテストする設定で、tolerance: 50は数十ミリ秒の差による頻繁な切り替えを抑えるために使います。テストURLには、安定していてレスポンスボディが小さく、ノード経由でアクセスできるアドレスを指定します。このテストで分かるのは応答速度の目安だけで、大容量ファイルのスループットは測定できません。
ノードを変えるべきか、設定を変えるべきか
障害がノード側にあるのかクライアント側にあるのかを先に切り分ければ、無駄な操作を減らせます。特定のノードだけがタイムアウトし、同じグループの他ノードが正常なら、まずノードを変更します。すべてのノードが同時に失敗する場合は、サブスクリプション、ローカルネットワーク、クライアントポート、システムプロキシ、DNS、カーネルを確認します。1つのノードが混雑しているときにクライアントを何度も再インストールしたり、すべてのノードが失敗しているときに無闇に何十個も切り替えたりしないでください。
| 現象 | まず確認すること | 次の対応 |
|---|---|---|
| 1つのノードだけタイムアウトする | ノードまたは単一回線の異常 | 同じ地域のノードに切り替えて再テストする |
| すべてのノードがタイムアウトする | サブスクリプション、ローカルネットワーク、クライアント層 | サブスクリプションの状態、直接接続のネットワーク、システム時刻を確認する |
| 速度テストは正常だがブラウザーが開けない | システムプロキシまたはルール層 | システムプロキシのスイッチと接続ログを確認する |
| ウェブページは正常だが特定のアプリだけ直接接続になる | アプリがシステムプロキシを読み取っていない | アプリのプロキシ設定を確認し、必要に応じてTUNモードを検討する |
| 日中は速いが夜間の混雑時間帯は遅い | 回線の混雑 | まずDNSを変更せず、回線または地域を変更する |
| すべてのノード速度が直接接続の上限に近い | ローカル接続帯域の制限 | Wi-Fi、LANケーブル、通信事業者の帯域を確認する |
ポートとシステムプロキシの確認
多くのClash設定では混合ポート7890を使いますが、実際のポートはクライアント側で別の値に変更されている場合があります。クライアントに現在表示されている値を優先し、チュートリアルの既定値をそのまま入力しないでください。ブラウザーでプロキシを手動設定する場合、アドレスは通常127.0.0.1で、ポートは「設定」→「ポート設定」または「設定」→「パラメータ設定」にあるMixed Portと一致させます。
クライアントの接続ログにブラウザーのリクエストがまったく表示されない場合、問題はまだノード層に到達していない可能性が高いです。まずシステムプロキシを有効にし、別のVPNやプロキシアプリが通信を占有していないことを確認します。接続ログにリクエストが表示され、特定のプロキシノードに接続した後でタイムアウトしているなら、そのノード、ポリシーグループ、リモートサービスのテストを続けます。
DNSでは帯域の混雑は解消できない
DNSはドメイン名をアドレスに変換し、ルールのマッチングや接続確立にも関わります。名前解決の異常は、ドメインが開けない、意図しないルールに一致する、初回接続が遅いといった問題を起こしますが、常時5Mbpsしか出ない混雑回線を100Mbpsに変えることはできません。IPへの直接接続は正常でドメインだけ失敗する場合にDNSを調べ、すべてのダウンロードが遅い場合は、まずノードのスループットとローカル帯域を確認してください。
4つの観点から選ぶ結論
遅延は応答速度の判断に使い、複数回の結果とジッターを重視します。倍率は通信量の消費量を見積もるためのもので、性能を示すものではありません。地域は対象サービスと物理的な距離で選び、プロトコルはまずクライアントの互換性を確認したうえで、現在のネットワークにおけるTCP、UDP、各通信方式の実測結果を見ます。4つの観点は互いに代用できません。
普段使いでは、まず近い地域のノードを3つ選び、遅延テストを5回、30秒間のダウンロードテストを1回実施します。そのうえで安定したノードを手動ポリシーグループに入れます。遅延は低くても変動が大きいノード、速度のピークは高くても持続的なスループットが低いノード、倍率が高いだけで品質面のメリットがないノードは、長期的な既定ノードには向きません。
障害が発生したら、特定のノードだけが異常ならノードを変更し、すべてのノードが異常ならサブスクリプション、ネットワーク、クライアントを確認します。一部のアプリだけが異常なら、システムプロキシ、ルール、TUNの対象範囲を確認します。DNS、ポート、プロトコルのパラメータを繰り返し変更するより、層ごとに切り分けるほうが早く解決できます。