Clash初回接続の実践：ノード選択・遅延テスト・プロキシ有効化を確認する3ステップ

開始前の確認：設定の読み込みとポート競合を確認

初回接続では、問題を3つに分けて考えます。設定が正常に読み込まれているか、ノードへの接続を確立できるか、アプリの通信が実際にClashへ入っているか、の3点です。クライアントのトップ画面に「起動中」と表示されているだけでは不十分です。通常これはコアプロセスが動作していることを示すだけで、購読中のノードが利用可能であることや、ブラウザがローカルプロキシポートを使っていることまでは意味しません。

クライアントを開いたら、まず「設定」または「Profiles」ページに移動し、先ほど読み込んだ購読設定が選択されていることを確認します。設定の横に更新日時、ファイル名、または購読名が表示されているはずです。解析失敗、空の設定ファイル、設定を切り替えた直後のコア終了などが表示される場合は、ノードテストの前に読み込みの問題を解決してください。

ローカル待受ポートを確認する

一般的な設定では、HTTPポートに 7890、SOCKS5ポートに 7891 を使います。比較的新しい設定では、mixed-port: 7890 により同じポートでHTTPとSOCKS5の通信を受け付けることもあります。具体的な番号は設定ファイルとクライアントの設定によって異なるため、特定のポートへ無理に変更する必要はありません。ただし、システムプロキシに入力するポートは、Clashが実際に待ち受けている番号と一致している必要があります。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

グラフィカルクライアントでは、ポートは通常「設定」→「詳細設定」→「ポート」、または「General」→「Port」にあります。7890 が別のプロキシソフトに使われていると、bind failed、address already in use、起動失敗などが表示されることがあります。その場合はポートを使用しているソフトを終了するか、Clashのポートを 7892 に変更してから、システムプロキシを再度有効にします。

ステップ1：ポリシーグループで適切なノードを選ぶ

購読設定を読み込んでも、ノードは通常ホーム画面に直接表示されず、「プロキシ」または「Proxies」ページのポリシーグループ内にあります。グループ名には「ノード選択」「プロキシ」「Proxy」「手動選択」などがよく使われます。まず、主要な通信の出口を担う選択型ポリシーグループを見つけ、グループ内からノードを1つ選びます。DIRECTやREJECTなどを含む一覧画面で、適当にクリックするだけでは不十分です。

手動選択グループから始める

1. 「プロキシ」→「ノード選択」に移動し、現在のモードが「ルール」またはRuleになっていることを確認します。
2. 主要なプロキシポリシーグループを開き、地理的に近く、情報が十分に記載されたノードを1つ選びます。
3. ほかのポリシーグループが「ノード選択」を参照している場合は、そのグループを参照先にしたままで構いません。グループごとに同じ指定を繰り返す必要はありません。
4. ホーム画面に戻り、コアの状態が実行中であることを確認してから、「システムプロキシ」を有効にします。

初回テストでは、ノードを手動で1つ固定するのがおすすめです。これにより、その後の速度テスト、IP検索、接続ログがどの出口に対応するかを明確にできます。最初からurl-test、自動選択、負荷分散グループを選ぶと、テスト中にクライアントがノードを切り替え、結果が前後で一致しなくなることがあります。

ノード名はあくまで絞り込みの手がかり

ノード名に含まれる地域、倍率、専用線などの情報は購読サービス提供元が定義したものであり、リアルタイムの品質を示すものではありません。実際の使用感は、端末からサーバーまでのネットワーク経路、サーバー負荷、プロトコルパラメータ、接続先サイトの回線に大きく左右されます。近い地域のノードは往復時間が短い傾向にありますが、ダウンロード速度が最速とは限りません。低倍率のノードが必ず安定しているわけでもありません。

ポリシーグループにDIRECTしかない、またはノード一覧が完全に空の場合、単に「ノードが選択されていない」のではなく、購読内容が現在のコアに対応する設定へ正常に変換されていない可能性があります。「設定」ページに戻って購読を更新し、エラーログを確認してください。また、使用中のクライアントのmihomoコアが、設定に含まれるプロキシプロトコルとフィールドを認識できるバージョンかどうかも確認します。

ステップ2：遅延を測定し、ノードの可用性を判断する

ノードを選択したら、ポリシーグループの右側にある遅延テストボタンをクリックします。クライアントによっては、速度計アイコン、稲妻アイコン、「Test」などで表示されます。テスト先は通常、容量の小さいHTTPまたはHTTPSページです。クライアントが接続を確立して応答を受け取るまでの時間を記録し、結果をミリ秒で表示します。

遅延結果の見方

• 50–150 ms：ネットワーク的に近く、状態が安定したノードでよく見られる範囲です。ウェブ操作も比較的スムーズです。
• 150–300 ms：通常の閲覧やダウンロードには使えますが、リアルタイム操作では待ち時間を感じることがあります。
• 300–800 ms：迂回経路、混雑、またはノード負荷の高さが疑われます。同じ地域のほかのノードと比較してください。
• Timeout：テスト時間内に有効な応答を受け取れませんでした。テスト先に到達できないのか、ノードが停止しているのか、端末側のネットワークで遮断されているのかを切り分ける必要があります。

これらの範囲はトラブルシューティングの目安であり、固定の合格ラインではありません。1回目が 82 ms、次が 210 ms なら、回線に揺らぎがあると考えられます。一方、3回連続で 86 ms、91 ms、89 ms なら、単発の最小値だけを見るより有益です。初回の絞り込みでは、3回連続で成功し、変動の小さいノードを2～3個残すとよいでしょう。

遅延が正常でも、すべてのウェブサイトを開けるとは限らない

遅延テストで確認できるのは、「端末 → ノード → テスト先」という1本のリクエスト経路だけです。すべての接続先や大容量ファイルのスループットを測るものではありません。ノードの遅延が 95 ms でも、特定サイトがDIRECTルールに一致していたり、接続先の制限、DNS結果の異常、ノードの出口ネットワークの違いなどによりアクセスできない場合があります。

逆に、Timeoutだからといってノードが完全に使えないとは限りません。テストURLが接続先ネットワークで制限されている、またはクライアントのタイムアウト時間が短すぎる可能性があります。「設定」→「遅延テスト」でテスト先とタイムアウト値を確認してください。一般的なタイムアウト値は 5000 ms です。テスト先を変更してすべてのノードで結果が出るようになった場合、問題は購読設定全体ではなく、元のテスト先にある可能性が高いでしょう。

すべてのノードが同時にタイムアウトしたら、まず端末を確認する

十数個のノードが同時にすべてTimeoutになる場合、ノードを1つずつ変えても効果はほとんどありません。まず家庭のWi‑Fiからスマートフォンのテザリングへ切り替えるなど、別のネットワークで再テストしてください。テザリングで復旧するなら、ルーター、現在の回線、または端末側のネットワークフィルタリングに問題がある可能性があります。両方のネットワークで失敗する場合は、購読の更新日時、システム時刻、コアログ、ノードのプロトコルパラメータを確認します。

パソコンの時刻ずれがTLSハンドシェイクの失敗を引き起こすこともあります。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、自動設定を有効にして今すぐ同期します。macOSでは「システム設定」→「一般」→「日付と時刻」を開き、自動設定が有効か確認します。同期後はプロキシページを更新するだけでなく、コアを再起動してください。

ステップ3：通信が実際にプロキシを経由していることを確認する

ノードに遅延結果が表示された後は、通信経路も検証する必要があります。確実な判断には、システムプロキシまたはTUNが有効であること、出口IPが直結時と異なること、Clashの接続パネルに直前のリクエストが表示されることの3点を確認します。3つがそろって初めて、「ノードが使える」ことと「アプリがプロキシを経由している」ことを結び付けられます。

まず直結時の出口IPを記録する

1. Clashの「システムプロキシ」と「TUNモード」を一時的に無効にします。
2. ブラウザで信頼できるIP検索ページを開き、現在のグローバルIPアドレスと地域を記録します。
3. そのページを閉じ、Clashを再度有効にして、先ほど選んだノードを維持します。
4. IP検索ページをもう一度開き、グローバルIP、通信事業者、地域を比較します。

プロキシ経由の出口IPが直結時と異なり、地域もノードの出口とおおむね一致していれば、ブラウザのリクエストはプロキシを経由している可能性が高いと判断できます。ただし、IP検索で確認できるのはそのアクセスの出口だけで、すべてのアプリやプロトコルがプロキシ経由になったことまでは証明できません。ブラウザがページをキャッシュしている場合もあるため、テストにはシークレットウィンドウを使うか、強制更新を行ってください。

接続パネルでリクエスト経路を確認する

クライアントの「接続」または「Connections」ページを開き、ブラウザでこれまで開いていないウェブサイトにアクセスします。接続一覧には、新しいドメイン、接続先アドレス、ルール名、ポリシーグループ、実際に使われたノードが表示されるはずです。記録の例：

Host: example.com
Network: TCP
Rule: DomainSuffix
Chain: ノード選択 → HK-01
Upload: 3.2 KB
Download: 18.7 KB

ChainまたはChainsは、ポリシーグループが最終的にどのノードへ到達したかを示します。経路が「ノード選択 → HK-01」なら、リクエストはそのノードを経由しています。「DIRECT」なら、ルールに従って直接接続されています。ルールモードでDIRECTが表示されるのは正常です。LANアドレス、日本国内のサイト、設定で指定されたドメインなどは、もともと直結するよう設定されている場合があります。

接続パネルに新しいリクエストがまったく表示されない場合、アプリがClashを使っていない可能性があります。「設定」→「システムプロキシ」が有効か確認し、システムプロキシのアドレスが 127.0.0.1、ポートがClashのHTTPまたはmixedポートと一致しているか確認してください。ブラウザにプロキシ拡張機能を入れている場合は、システム設定を上書きして別のポートを指定していないか確認します。

システムプロキシとTUNモードの適用範囲

システムプロキシは、OSのプロキシ設定に従うアプリに主に影響します。一般的なブラウザや一部のデスクトップアプリがその例です。一部のゲーム、コマンドラインプログラム、ストアアプリ、UDP通信はシステムプロキシを自動的に読み取りません。こうした通信も取り込みたい場合は、クライアントの「設定」→「ネットワーク」→「TUNモード」でTUNを有効にします。

TUNは仮想ネットワークインターフェースを作成し、より多くのIP層の通信をmihomoに処理させます。初回の有効化には管理者権限が必要な場合があり、Windowsでは関連するネットワークコンポーネントのインストールや有効化を求められることもあります。有効化後は「接続」パネルを再度確認し、対象プロセスの接続が表示されることを確認してください。システムプロキシを別のプログラムへ誤って同時指定すると、HTTPリクエストとTUN通信で異なる結果になる可能性があります。

よくある3つの誤解：接続済みに見えても問題が残る場合

誤解1：ホーム画面のスイッチだけを見る

ホーム画面に「実行中」と表示されるのは、コアの起動に成功したことを示すだけです。完全な動作確認には、設定の読み込み成功、ノードの遅延テスト結果、システムプロキシまたはTUNの有効化、接続パネルへのリクエスト表示が少なくとも必要です。どれか1つでも欠けると、クライアントは動作しているのにウェブページが直結のままだったり、アクセスできなかったりします。

誤解2：遅延が最も低いノードが最速だと考える

遅延テストで転送されるデータは少なく、主に応答時間を反映します。ダウンロード速度は、サーバー帯域、回線の混雑、ノード負荷、単一接続の速度制限、接続先サイトの性能にも左右されます。2つのノードがそれぞれ 70 ms と 110 ms でも、後者のほうが安定したダウンロード速度を出すことがあります。日常利用では、ページの応答、接続の安定性、実際の転送速度を合わせて確認してください。

誤解3：出口IPが変わらないからノードが使えないと決めつける

ルールモードでは、IP検索サイトがDIRECTに設定されているため、ローカルの出口IPが表示されることがあります。まず「接続」ページで、そのドメインにどのルールが一致したかを確認してください。記録がDIRECTなら、一時的にグローバルモードへ切り替えて再テストします。グローバルモードで出口IPが変わるなら、ノード自体は利用可能です。必要なのはルールまたは正しいプロキシポリシーグループの調整です。

別の可能性として、ブラウザのセキュアDNS、独立したプロキシ拡張機能、企業ポリシーが有効になっていることもあります。これらは名前解決やプロキシ経路を変える場合があります。切り分けでは、まず追加の拡張機能を無効にし、入口をシステムプロキシ1つに絞ってから接続パネルを確認します。DNSの問い合わせ結果とウェブのTCP接続は別の段階であり、DNSサーバーの所在地だけを見て通信全体がプロキシ経由かどうかを判断してはいけません。

初回接続に失敗したときの固定トラブルシューティング手順

ウェブページを開けない、速度テストがすべてタイムアウトする、出口IPが変わらないといった場合は、設定を無作為に切り替えるより、決めた順番で確認するほうが早く解決できます。毎回変更する変数は1つだけにし、変更後はリクエストを再実行してください。

1. 設定：購読が選択状態にあり、更新時に解析エラーがなく、ノード一覧が空白ではないことを確認します。
2. コア：状態が実行中で、ログにポート競合、フィールドエラー、権限エラーがないことを確認します。
3. ノード：1つのノードを固定して3回テストし、同じ地域の別ノードと比較します。
4. ポート：mixed、HTTP、SOCKS5のポートとシステムプロキシ設定が一致しているか確認します。
5. アプリの入口：ブラウザではまずシステムプロキシを使ってテストし、システムプロキシを読まないアプリではTUNを検討します。
6. ルール：接続パネルで、DIRECT、REJECT、プロキシポリシーグループのどれに一致したか確認します。
7. ネットワーク：スマートフォンのテザリングに切り替えて再テストし、クライアント設定と現在のLANの問題を切り分けます。
8. ログ：timeout、connection refused、TLS handshakeなど、具体的な情報から問題の段階を特定します。

たとえば、ノードの遅延は正常なのにIP検索では直結のままで、接続パネルにも記録がない場合、まず疑うべきはシステムプロキシが有効になっていないことです。接続パネルに記録があり、選択したノードへ経路が向いているのにリクエストがtimeoutになるなら、ノードと接続先ネットワークを引き続き確認します。記録にREJECTと明確に表示される場合は、ポートではなくルールを確認してください。

確認後におすすめする日常設定

接続に成功したら、モードをRuleにしておくと、ドメイン、IP、ルールセットに基づいてDIRECTまたはプロキシを自動的に選べます。主要なポリシーグループは安定したノードに固定しても、url-testの自動選択グループへ切り替えても構いません。自動グループを使う前に、グループ内の各ノードが単独で接続できることを確認してください。自動テストは利用可能なノードから選ぶだけで、壊れた設定を修復することはできません。

• システムプロキシを使う場合は、ローカルの待受アドレスを 127.0.0.1 にし、LANで共有しないならAllow LANを無効にします。
• ゲーム、コマンドライン、システムプロキシを読み取らないソフトで通信するときだけTUNを有効にし、接続パネルでその通信を認識できることを確認します。
• 購読更新後にノード名が変わった場合は、手動ポリシーグループが有効なノードを参照しているか再確認します。
• ウェブページに問題があるときは、まず接続記録とルールの一致状況を確認し、設定全体をすぐに削除しないでください。
• 遅延テストを3回行い、実際のアクセスでも確認した予備ノードを1つ残しておくと、すばやく比較できます。

初回接続で重要なのは、すべてのスイッチを一度にオンにすることではありません。具体的なノードを1つ選び、遅延テストで基本的な疎通を確認し、最後に出口IPと接続パネルでリクエスト経路を確認する、という明確な検証手順を作ることです。この3ステップを終えておけば、速度低下、特定サイトだけ開けない、特定アプリだけプロキシを使わないといった問題が起きても、原因がノード、ルール、通信の入口のどこにあるかを切り分けられます。