Clashの初回接続でノードを選ぶ方法：遅延測定・ノード切り替え・プロキシ有効性の確認

接続経路を整えてからノードを比較する

Clash、またはMihomoカーネルを搭載したクライアントを初めて使うときは、まずノード一覧の遅延値だけを見ないでください。接続が正常に完了するには、少なくとも4つの段階があります。設定の読み込み、プロキシグループでのノード選択、システム通信のクライアントへの引き渡し、そしてノードから目的のWebサイトへアクセスできることです。どれか1つでも未完了だと、「ノードには遅延値が表示されるのに、Webページが開けない」状態になることがあります。

次の順番で操作するのがおすすめです。サブスクリプションを読み込み、設定を更新し、プロキシモードを選択してから、システムプロキシまたはTUNモードを有効にし、プロキシグループでノードを選びます。グラフィカルクライアントによって名称は多少異なりますが、一般的には「サブスクリプション」→「更新」の後、「プロキシ」→対象のプロキシグループへ進みます。クライアントを起動しただけでシステムプロキシを有効にしていない場合、ブラウザーは通常どおり既存のネットワークへ直接接続します。

1. 「サブスクリプション」または「設定」ページで、現在のProfileが有効になっていることを確認し、手動更新を1回実行します。
2. 「プロキシ」ページを開き、動作モードを「ルール」に設定します。初回テストでいきなり「直接接続」を使うのはおすすめしません。
3. 「設定」→「システムプロキシ」を開き、スイッチが有効になっていることを確認します。
4. 「プロキシ」→メインプロキシグループに戻り、遅延測定を完了できるノードを1つ選択します。
5. プロキシ有効化前後の出口IPを確認してアドレスが変わったことを確かめ、その後に実際のWebサイトへアクセスします。

手動選択・自動速度測定・フォールバックの違い

Clash設定での「ノード選択」は、実際にはプロキシグループで行います。プロキシグループとは、複数のプロキシノードと選択ロジックをまとめたものです。代表的なタイプには select、url-test、fallback、load-balance があります。サブスクリプションサービスによっては、「ノード選択」「自動選択」「フォールバック」「負荷分散」などの名称で表示されます。

初回接続では手動プロキシグループを優先する

初回テストには、変数が少ない手動選択が適しています。まず select タイプのプロキシグループでノードを1つ固定し、出口IP、Webサイトへのアクセス、コマンドラインのテストを行います。接続が正常なら、自動速度測定グループへ切り替えます。こうすれば自動選択の結果が良くない場合に、原因が速度測定のロジックなのか、システムプロキシやサブスクリプションの読み込みなのかを切り分けられます。

ノード名に含まれる地域、倍率、回線などのラベルは分類情報にすぎず、実測の代わりにはなりません。たとえば「香港 01」が必ず「日本 02」より速いとは限らず、「専用線」もローカルネットワークから入口サーバーまでの品質を直接示すものではありません。距離が近いほど往復時間の短縮には有利ですが、通信事業者間の接続、ピーク時間帯の混雑、ノード負荷によって結果は変わります。

自動速度測定は測定先を基準にする

url-test は、設定で指定されたテストURLへ定期的にリクエストを送り、候補ノードの応答時間を比較します。Mihomoでよく使われる設定例は次のとおりです。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 香港 01
      - 日本 02
      - シンガポール 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval: 300 は約300秒ごとに再測定することを示します。tolerance: 50 は候補間の差が小さい場合に現在のノードを維持し、頻繁な切り替えを抑える設定です。テストURLへの応答が速くても、そのノードがその測定先へのアクセスにおいて現在良好だという意味に限られ、動画、コードリポジトリ、業務サービスでも最速とは限りません。

遅延値の見方

クライアントに表示される遅延は、通常のICMP Pingとは異なります。多くのClash対応グラフィカルクライアントはプロキシ経由でHTTPリクエストを送り、接続の確立から応答の取得までにかかった時間を記録します。この値は、ローカルネットワーク、プロキシ入口、ノード出口、DNS、TLSハンドシェイク、テストサーバーの状態の影響を受けます。したがって、遅延値は選別の目安であり、帯域幅の測定ではありません。

1回だけ65 msだったからといって、ノードが安定しているとは限りません。より確実なのは、10秒間隔で3〜5回測定することです。たとえば同じノードが72、75、79、74 msなら変動は小さいといえます。一方、別のノードが48、210、93、タイムアウトとなる場合、最低値は魅力的でも実際の利用では不安定になりがちです。動画やダウンロードでは継続的なスループットも確認し、リモートターミナルやWeb操作では遅延とジッターをより重視してください。

速度測定がすべてタイムアウトするときの確認事項

• パソコン自体から通常のWebサイトへ直接アクセスできることを確認し、Wi-Fiの切断やゲートウェイ障害を切り分けます。
• 「サブスクリプション」→「更新」から設定を再取得し、期限切れのノード情報を使わないようにします。
• システム時刻とタイムゾーンを確認します。時刻のずれが大きいと、TLS証明書の検証に失敗することがあります。
• 一時的にTUNを無効にし、システムプロキシだけを有効にしてテストします。複数の通信取り込み方式による干渉を避けるためです。
• ローカルの混合ポートが他のプログラムに占有されていないことを確認します。一般的な値は 7890 です。
• クライアントのログを確認し、timeout、connection refused、network unreachable を重点的に探します。

ノードを切り替えてもすぐに変化しない理由

プロキシグループで新しいノードを選ぶと、新しく作成される接続には通常その選択が使われます。ただし、確立済みの接続は古い経路を使い続けることがあります。ブラウザーのHTTP/2・HTTP/3の長時間接続、ダウンロードツールの分割タスク、メッセージアプリの常時接続などにより、古い出口が一時的に維持されるためです。そのため、切り替え直後に同じページを更新しても、出口の変化が確認できない場合があります。

次の順番で新しい接続を確立する

1. 「プロキシ」→メインプロキシグループを開き、新しいノードへ選択マークが移動したことを確認します。
2. テスト中のWebページのタブを閉じ、5〜10秒待ちます。
3. 新しいシークレットウィンドウを開き、ページキャッシュや既存の接続による影響を避けます。
4. 出口IPを再度確認し、切り替え前のアドレスと比較します。
5. 変化がない場合はブラウザーを再起動し、必要に応じてクライアントの接続ページで古い接続を閉じます。

ルールモードでテストサイトが想定したプロキシグループに割り当てられているかも確認してください。ルールモードはドメイン、IP、プロセス、ルールセットを上から順に照合します。出口IP確認サイトのドメインが DIRECT に一致すると、メインプロキシグループでプロキシを選択していても、ページにはローカルのグローバルIPが表示されます。調査時はクライアントのログまたは接続一覧でそのドメインを見つけ、適用ルール、プロキシグループ、実際のノードを確認します。

比較テストとして、一時的にグローバルモードへ切り替えることもできます。グローバルモードでは通常、通信が指定したプロキシノードへ一律に送られます。グローバルモードで出口が変わり、ルールモードでは変わらない場合、原因はルール照合またはプロキシグループの参照にある可能性が高いです。テスト後はルールモードへ戻し、本来直接接続すべきLANや中国国内のサービスまでプロキシ経由にならないようにしてください。

出口IPページでプロキシの有効性を確認する

最も分かりやすい方法は、まずシステムプロキシを無効にしてグローバルIP確認サービスへアクセスし、現在の出口アドレスを記録することです。次にシステムプロキシを有効にしてページを更新します。2回の結果が異なり、プロキシ使用後の地域が選択したノードとおおむね一致すれば、ブラウザーの通信がプロキシ経由になっています。ページに表示される国や都市だけで判断せず、IPアドレスそのものを比較してください。

1. Clashの「システムプロキシ」を無効にし、IP確認ページを開いてIPv4またはIPv6のアドレスを記録します。
2. 「システムプロキシ」を再び有効にし、プロキシグループでノードを1つ固定します。
3. 新しいシークレットウィンドウを開き、出口IPをもう一度確認します。
4. 別の地域のノードへ切り替え、確認ページのタブを閉じてから開き直し、アドレスが再び変わることを確認します。
5. クライアントの「接続」ページに戻り、確認用ドメインが対象のプロキシグループを経由しているか確認します。

IPv4は変わったのにIPv6がローカル通信事業者のアドレスのままなら、クライアントがIPv6を取り込んでいるか、ブラウザーが利用する確認サービスがIPv6を優先して返しているかを確認してください。IPv6の扱いは、OS、TUN設定、ネットワーク環境によって異なります。IPv4だけをテストしても、すべてのIPv6通信が同じ経路を通っているとは判断できません。

コマンドラインで直接接続とプロキシ接続を個別にテストする

コマンドラインテストなら、ブラウザー拡張機能、キャッシュ、長時間接続の影響を避けて、ローカルのプロキシポートが動作しているかを確認しやすくなります。以下ではMihomoの混合ポートが 127.0.0.1:7890 であると仮定します。混合ポートはHTTP接続とSOCKS接続の両方を受け付けます。クライアントで別のポートを使っている場合は、「設定」→「ポート設定」に表示される値を使用してください。

Windows PowerShell

Windows 10またはWindows 11では、PowerShellの古いバージョンが curl を別のコマンドとして解釈するのを避けるため、まず curl.exe が実際のプログラムであることを確認できます。直接接続とプロキシ接続をそれぞれ実行します。

curl.exe --noproxy "*" https://api.ipify.org
curl.exe -x http://127.0.0.1:7890 https://api.ipify.org

macOSとLinux

curl --noproxy "*" https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

1つ目のコマンドはプロキシを強制的に無視し、ローカルネットワークのグローバル出口を返します。2つ目はリクエストをClashの混合ポートへ明示的に送ります。2つのコマンドで異なるアドレスが返り、かつ2つ目のリクエストがクライアントの接続記録にも表示されれば、HTTPプロキシ経路は有効です。2つ目で 127.0.0.1:7890 に接続できないと表示された場合は、クライアントが起動しているか、ポートが正しいか、待ち受けアドレスがローカル接続を許可しているかを確認してください。

SOCKS5もテストし、ドメイン名の解決をプロキシ側で行わせることができます。

curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org

--socks5-hostname と単純な --socks5 には重要な違いがあります。前者はドメイン名の解決をSOCKSプロキシに任せるため、ローカルDNSの結果がテストへ与える影響を切り分けるのに適しています。HTTPプロキシは利用できるのにSOCKS接続が失敗する場合は、現在のポートが混合ポート、HTTPポート、単独のSOCKSポートのどれなのかを確認してください。

ローカルポートが待ち受け中か確認する

Windowsでは次を実行します。

netstat -ano | findstr :7890

macOSでは次を実行します。

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linuxでは次を実行します。

ss -lntp | grep 7890

127.0.0.1:7890 または 0.0.0.0:7890 がLISTEN状態なら、そのポートで接続を受け付けているプログラムが存在します。ただし、これだけでノードの利用可能性を証明することはできません。プロキシリクエストの結果とクライアントログも確認してください。待ち受けプロセスが現在のClashクライアントでない場合は、ポート競合の可能性があります。競合するプログラムを終了するか、クライアントのポートとシステムプロキシ設定を同じ値に変更します。

ブラウザーは使えるのに他のアプリが通信できない場合

ブラウザーからアクセスできても、すべてのプログラムがシステムプロキシを読み取るとは限りません。一部のゲーム、コマンドラインツール、ストアアプリ、独自のネットワークスタックを使うソフトウェアは、HTTPプロキシ設定を無視します。まずアプリ側にプロキシ設定があるか確認してください。対応していれば、HTTPプロキシに 127.0.0.1:7890 を入力するか、同じ混合ポートをSOCKS5プロキシとして指定します。

アプリ側にプロキシ設定がない場合は、TUNモードを検討できます。一般的な操作手順は「設定」→「Mihomo」または「カーネル設定」→「TUNモード」です。初回の有効化には管理者権限が必要で、仮想ネットワークアダプターが作成されることがあります。有効化後は出口IPと対象アプリを再テストし、LAN機器、プリンター、社内ネットワークがルールどおり直接接続できることも確認してください。

TUNモードで確認すべきポイント

• クライアントログに、対象アプリが新しく作成した接続が表示される。
• 接続記録に正しいルールとプロキシグループが表示され、意図せず DIRECT に一致していない。
• DNSリクエストが正常に完了し、名前解決のタイムアウトが連続して発生していない。
• システムプロキシを無効にしても、TUNモードで対象アプリがルールどおり接続できる。
• クライアント終了後にネットワークが復旧し、デフォルトルートとDNSに異常な設定が残っていない。

システムプロキシ、TUN、グローバルモード、複数のノードを何度も同時に切り替えないでください。一度に変更する変数は1つだけにして、結果を記録します。たとえば、まず「日本 02」を固定してシステムプロキシだけを有効にし、コマンドラインのプロキシ接続を確認してからTUNを有効にします。最後にルールモードへ戻します。この順番なら、問題がノード、ポート、ルール、通信の取り込み層のどこにあるかをすばやく特定できます。

初回接続の安定性チェックリスト

遅延が比較的小さいノードを選んだら、連続テストをもう一度行います。種類の異なるWebサイトを3つ開いて5分間維持し、約50 MBの公開テストファイルをダウンロードして速度が持続するか確認します。さらにページを2回切り替え、クライアントの接続記録を確認してください。短時間の測定には成功しても数分後にタイムアウトが多発する場合、ノード負荷、回線のジッター、ローカルネットワークの不安定さが原因であることが多いです。

• Profileが更新され、クライアントに表示される設定更新時刻が想定どおりである。
• メインプロキシグループでノードが明確に選択され、誤って DIRECT を選んでいない。
• 遅延測定を3回連続で行っても、数値が大きく変動したり頻繁にタイムアウトしたりしない。
• システムプロキシまたはTUNの少なくとも一方が有効で、テスト対象に合っている。
• プロキシ使用前後で出口IPが異なり、接続ログに対象ノード名が表示される。
• ルールモードで普段使うWebサイトが想定したプロキシグループに一致する。
• クライアントを終了すると、システムネットワークが正常に復旧する。

最終的な選択で、一覧の最低値だけを追い求める必要はありません。110 ms前後で安定し、連続使用にも問題がないノードのほうが、45〜400 msの間を激しく変動するノードより日常の作業に適しています。まず利用可能で安定していることを優先し、動画速度、ページ応答、特定地域へのアクセスなどの要件に応じてプロキシグループを調整してください。