Clash PC版の初回接続ガイド|ノード選択・遅延テスト・プロキシの動作確認
クライアントをインストールしたばかりの方向けに、プロキシグループでのノード選択、遅延テスト結果の見方、システムプロキシの有効化、ブラウザーと接続ログによる動作確認を順に解説します。
1. 接続前の確認:設定・コア・待ち受けポート
初回接続では、「設定の読み込み → 出口の選択 → ノードのテスト → ブラウザーの接続 → 接続ログの確認」の順に進めます。サブスクリプションのインポートに成功しても、クライアントが設定を取得できたことしか分かりません。ノードの利用可否、ルールの適用、アプリの接続は、それぞれ個別に確認が必要です。システムプロキシ、TUNモード、ブラウザーのプロキシ拡張機能を同時に有効にすると、失敗時に原因を切り分けにくくなるため、最初は併用しないでください。
- 現在の設定を確認します。クライアントの「サブスクリプション」または「設定」画面を開き、インポートした設定を選択して、一覧に表示されているだけでなく使用中になっていることを確認します。画面名はクライアントのバージョンによって異なります。
- コアの起動状態を確認します。「ログ」画面を開き、設定の解析エラー、ポートの競合、コアの終了を示すメッセージがないか確認します。画面が開いているだけでは、コアが正常に起動したとは限りません。
- ローカルポートを確認します。設定で「ポート」「混合ポート」または
mixed-portを探します。この記事では127.0.0.1:7890を例にします。画面に別のポートが表示されている場合は、以降のコマンドも同じポートに変更してください。 - 重複するプロキシ設定を一時的に無効にします。ほかのプロキシクライアントとブラウザーのプロキシ拡張機能を終了し、接続経路を1つに絞ります。接続テストのためにファイアウォールや証明書の検証を無効にしないでください。
設定画面にノードがない場合は、インポート手順に戻って確認します。サブスクリプションが有効か、プランの期限が切れていないか、インポートしたものがClash YAML設定か、別形式のノードリストかを確認してください。この状態で遅延テストを何度繰り返しても、設定の不足は解消されません。
2. プロキシグループの選択:モードを決めてからノードを選ぶ
プロキシグループとノードは別のものです。グループには複数のノードを登録でき、ほかのプロキシグループを参照することもあります。ルールモードでは、アクセス先によって適用されるグループが異なる場合があるため、ノードを1つ選んでも、すべての通信がそのノードを経由するとは限りません。
初回接続ではルールモードを使用
クライアントの「プロキシ」画面を開き、動作モードを「ルール」(Rule)にします。通常のプロキシ通信に使うプロキシグループを探し、展開して実際のノードを選択します。グループ名は設定の作成者が決めているため、名前だけで用途を判断せず、ルールの対象と接続ログも確認してください。
| モード・項目 | 役割 | 初回接続時のポイント |
|---|---|---|
| ルールモード Rule | 設定したルールに従って直結またはプロキシを選択 | 日常的な動作確認の出発点としておすすめ |
| グローバルモード Global | グローバルポリシーで出口を選択 | ルールの問題を切り分けるため一時的に使えますが、有効な出口の選択が必要です |
| 直結モード Direct | 直結の出口を使用 | 通常のリクエストは選択したプロキシノードを経由しません |
| DIRECT | プロキシグループ内の直結アクション | プロキシノードではありません |
| 自動選択グループ | 通常は url-test などの仕組みで出口を決定 | グループ内で現在選択されているノードを確認 |
たとえば、あるWebサイトへの通信が「メディア」グループに割り当てられているのに、「デフォルトプロキシ」グループだけを変更しても、そのWebサイトの出口は変わらないことがあります。グループ名はあくまで例です。実際の操作では、使用中の設定にある名称を確認してください。グループ内に「自動選択」がさらにある場合は、それも展開して最終的なノードを確認します。
手動で選択した後の新しいリクエストは、通常、新しい出口を使います。一方、既存の長時間接続は以前の出口を使い続ける場合があります。テスト時はページを再読み込みするか、新しいブラウザーウィンドウを開いてください。接続を切る必要がある場合は、ダウンロードや会議を中断しないよう、すべての接続を一括で切断するのではなく、対象のテスト接続だけを終了します。
3. 遅延テスト:到達性を確認し、ミリ秒をダウンロード速度と混同しない
「プロキシ」画面でノードまたはプロキシグループの横にあるテストボタンを押し、テストが終わるまで待ってから結果を比較します。一般的なテストでは、コアがノード経由で指定されたHTTPまたはHTTPSアドレスにリクエストし、応答までの時間を記録します。単純なICMP pingでも、帯域幅を測るテストでもありません。
テスト結果の見方
- ミリ秒の値が表示される:今回のテスト条件では、そのノード経由で対象のリクエストを完了できたことを示します。結果はテスト先、ハンドシェイク、ネットワークの混雑、キャッシュなどの影響を受けます。
- タイムアウトまたは失敗:制限時間内に有効な結果が得られなかったことを示します。ノードに到達できない、テスト先へのアクセスが制限されている、DNSに問題がある、テスト条件が合っていないなどの原因が考えられます。
- 数値は低いのにWebページの表示が遅い:テスト先と実際のWebサイトでは、接続先までの経路が異なる場合があります。帯域幅の不足、パケットロス、Webサイト側の応答の遅さも、単一の遅延値だけでは判断できません。
例として、同じノードを3回テストして 82 ms、91 ms、87 ms、別のノードでは 45 ms、タイムアウト、310 ms という結果になったとします。初回接続の確認には、前者のほうが適していると考えられます。これらは数値の読み方を示す例であり、当サイトで測定した結果ではありません。また、ノードのダウンロード速度を示すものでもありません。
テスト条件をそろえて比較する
クライアントでテスト先を設定できる場合は、まず設定に含まれているアドレスを使い、現在のネットワークからアクセスできることを確認します。疎通確認によく使われるアドレスには https://www.gstatic.com/generate_204 があり、HTTP 204 が返る想定です。ただし、ネットワークによってはこのアドレスに到達できません。テスト先を変更した場合、変更前後の結果をそのまま比較するのは避けてください。
初回の切り分けでは、テストの間隔を約10秒空けて3回実施し、多数のノードに対する連続テストは避けます。失敗するノードが1つだけなら、別のノードで確認してください。すべて失敗する場合は、まず設定の有効期限、コアのログ、ローカルネットワークを確認します。タイムアウト時間を短くしても失敗を早く報告するだけで、ノードが速くなるわけではありません。
4. システムプロキシを有効化:ブラウザーのリクエストをクライアントに通す
ノードテストは通常コアが直接実行するため、システムプロキシが無効でも成功することがあります。システムプロキシ設定に従うブラウザーをクライアント経由で接続するには、クライアントの「システムプロキシ」も有効にする必要があります。初回の動作確認では、設定の変化を抑えるためTUNモードを無効にしておきます。
- クライアントで「システムプロキシ」を有効にし、スイッチがすぐに元に戻ったり、設定の書き込みに失敗したりしていないことを確認します。
- Windows 11で「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシ セットアップ」欄を確認します。必要に応じて「編集」をクリックし、アドレスとポートを確認してください。
- ローカルのプロキシアドレスは通常
127.0.0.1です。ポートはクライアントが提供するHTTPポートまたは混合ポートに合わせます。サブスクリプションURLをプロキシサーバーのアドレス欄に入力しないでください。 - 独自のプロキシ設定がないブラウザーウィンドウでテスト用Webサイトにアクセスし、同時にクライアントの「接続」画面を開いて、新しいリクエストが表示されるか確認します。
PAC方式で接続している場合、システム設定には手動サーバーではなく、自動構成スクリプトが表示されることがあります。切り分けのために別のプロキシ設定を手動で重ねて追加しないでください。初回接続では方式を1つに決め、接続を確認してから変更します。
TUNモードは、システムプロキシに従わないアプリを後から接続する場合に適しています。通常は追加の権限が必要で、仮想ネットワークアダプター、ルーティング、DNSの設定にも関わります。アプリの通信が取り込まれるかどうかは、実際の設定によって異なります。システムプロキシでブラウザーの接続を確認できたなら、「接続済み」の表示を見るためだけに、すぐTUNを有効にする必要はありません。
5. ブラウザーと接続ログ:ルールと出口を確認
プロキシが有効になったことを確認するには、対象アプリのリクエストが実際にクライアントへ届いていることと、そのリクエストが想定した出口を使っていることの両方が必要です。ブラウザーでページを開けても、直結かプロキシ経由かは分かりません。遅延テストに成功しても、ブラウザーが接続された証明にはなりません。
接続画面で同じリクエストを探す
- クライアントの「接続」画面を開き、ドメインで絞り込むか、新しく追加された記録を確認します。
- ブラウザーで、HTTPSに対応したアクセス先が明確なWebサイトを開き、アクセスした時刻とドメインを記録します。テスト先は一般公開されているページを使い、アカウントへのログインが不要なものを選んでください。
- 該当する接続の宛先ドメイン、適用ルール、プロキシグループの経路、アップロード・ダウンロード量の変化を確認します。表示される項目名はクライアントによって異なります。
- プロキシグループの経路が最終的に
DIRECTなら、リクエストはクライアントに届いたものの、直結に振り分けられたことを示します。最終的に選択したノードが表示されていれば、その接続は該当するプロキシ出口を使用しています。
短時間で終わる接続は、画面を切り替える前に表示から消えることがあります。先に接続画面を開いてからブラウザーを再読み込みするか、「ログ」画面で同じ時刻のルール適用記録を探してください。ログレベルが info なら通常は接続情報を確認できますが、表示内容はコアやクライアントによって異なります。決まった文言がないことだけを理由に、障害と判断しないでください。
補助的な確認には、信頼できるグローバルIPアドレス確認サイトを利用できます。プロキシの使用前後で出口IPアドレスとネットワークの割り当て情報を比較してください。国や地域の表示だけでノードの場所を判断しないでください。IPデータベースの更新が遅れている場合や、ルールによってWebサイトが直結に振り分けられている場合があります。接続ログとIP確認の結果を照らし合わせてください。
6. コマンドラインで再確認:ローカルの待ち受けとリモート側の失敗を切り分ける
ブラウザーの動作がはっきりしない場合は、Windows PowerShellまたはターミナルからHTTPプロキシを明示してリクエストできます。この方法はブラウザー側のプロキシ選択を経由しませんが、システムプロキシのスイッチが有効になっていることの証明にはなりません。例に使うポートが実際の設定と一致していることを確認してください。
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/
-I はレスポンスヘッダーを取得します。--connect-timeout 10 は接続段階の待ち時間を10秒に制限し、--max-time 20 はリクエスト全体の時間を20秒に制限します。ターミナルに NO_PROXY 環境変数が設定されている場合は、テスト対象のドメインが例外として指定されていないか確認してください。クライアントに該当する接続が表示されるかも併せて確認します。
- ローカルポートに接続できない:コアが起動しているか、ポート番号が正しいか、そのポートがHTTPプロキシに対応しているかを確認します。
- HTTP 200 Connection established が表示される:プロキシトンネルが確立されたことを示すだけです。続けてTLSと接続先のレスポンスを確認してください。この行だけでリクエスト全体の成功とは判断できません。
- 接続先のレスポンスヘッダーを受信した:明示的にプロキシを指定したリクエストで、該当するHTTP通信が完了したことを示します。接続先から
403が返された場合も、サイト側のアクセス拒否と接続自体の失敗を区別してください。 - 証明書エラーが表示される:システム時刻、証明書の信頼状態、ネットワーク環境を確認してください。証明書の検証を回避する方法を恒常的な対処にしないでください。
ポートの待ち受け状態を確認するには、Windowsターミナルで次のコマンドを実行します。
netstat -ano | findstr ":7890"
ローカルアドレス欄でポートが 7890、状態が LISTENING の記録を確認します。この検索結果には関連する別の行も含まれる場合があるため、各列を確認してください。PIDに対応するプロセスは、タスクマネージャーの「詳細」タブで確認できます。ポートが待ち受け中でも、何らかのプログラムが使用していると分かるだけです。現在のクライアントのコアが使用していることも確認してください。
7. よくある結果の見分け方と初回接続の仕上げ
| 状態 | まず確認する項目 | 次の手順 |
|---|---|---|
| 遅延テストは成功するが、ブラウザーの接続記録がない | システムプロキシ、ブラウザー独自のプロキシ、除外リスト | システム側のポートを確認し、重複するプロキシ設定を無効にする |
| ブラウザーの記録はあるが、出口が DIRECT | 動作モードと適用されたルール | そのWebサイトが本来直結される設定か確認する |
| 明示的なプロキシ指定のコマンドは成功するが、ブラウザーは失敗する | ブラウザーの設定、拡張機能、システムプロキシの状態 | クリーンなブラウザーウィンドウで再テストし、同じドメインの接続を確認する |
| 特定のノードだけタイムアウトし、ほかのノードは正常 | 該当ノードの状態とテスト先との相性 | 利用可能なノードに切り替え、サブスクリプションの提供元に連絡する |
| すべてのノードと明示的なプロキシリクエストが失敗する | 設定、コアのログ、ローカルネットワーク、サブスクリプションの状態 | 具体的なエラーに対処し、モードを何度も切り替えない |
| ブラウザーは正常だが、特定のアプリだけ接続できない | そのアプリがシステムプロキシに従うか | アプリのプロキシ設定を確認し、必要に応じてTUNを検討する |
初回接続が完了したら、再現しやすい状態を保管しておきます。ルールモード、利用できることを確認したノード、実際の待ち受けポート、接続画面で確認できるテストリクエストを記録してください。グローバルモードに一時的に切り替えた場合はルールモードに戻します。ログレベルを一時的に上げた場合も、通常使うレベルに戻してください。
クライアントを終了する前にシステムプロキシを無効にしてください。無効にしないと、待ち受けが停止したローカルポートをシステムが参照し続ける場合があります。終了後にブラウザーがインターネットへ接続できなくなった場合は、Windowsのプロキシ設定に残った項目を確認してください。今後、自動起動やTUNによる通信の取り込みを設定するときは、一度に1つだけ変更し、ブラウザーと接続ログで再度確認します。
接続成功の最終的な判断基準は、緑色のステータス表示や特定の遅延値ではありません。「アプリのリクエストがクライアントに届く」「想定どおりのルールが適用される」「最終的なノードが確認できる」「接続先から正常な応答が返る」という一連の流れで判断します。基本操作は使用ガイドをご覧ください。具体的なエラーが発生した場合は、ヘルプセンターで症状に応じた対処方法を確認できます。