Clashの初回接続を確認する方法｜ノード選択・遅延測定・プロキシ動作確認

初回接続の確認ポイント：通信の取り込み・ルール適用・出口

サブスクリプションの追加に成功しても、クライアントが設定を取得できたことしか確認できません。ブラウザーやコマンドライン、ゲームがプロキシを使っているとは限りません。ノードに遅延時間が表示されても、指定されたテストリクエストが一度応答したことを示すだけです。アプリからの通信、ルールの判定、ノードへの接続、接続先からの応答まで、一連の流れを確認しましょう。

クライアントはサブスクリプションの管理やオン・オフ、画面表示を担当します。ClashやClash Meta（mihomo）などのコアは、ポートの待ち受け、ルールの照合、接続の確立を担います。メニュー名やポートの初期値はクライアントによって異なります。ここでは「設定」「プロキシ」「接続」「ログ」などの画面を使った確認方法を説明し、特定のクライアントの画面構成を標準として扱いません。

1. 設定が読み込まれている：現在の設定が有効で、コアに解析エラーが出ていない。
2. 通信が取り込まれている：新しいテストリクエストがクライアントの接続一覧またはコアのログに表示されている。
3. 想定どおりのポリシーが適用されている：リクエストに一致したルールがプロキシグループを指し、最終的な経路に選択したノードが含まれている。
4. 応答を確認できる：接続先から応答があり、プロキシ経由の出口を直接接続時の結果と比較できる。

サブスクリプション追加後に設定とプロキシグループを確認する

設定が有効になっているか確認する

「設定」画面で追加した設定を探し、一覧に表示されているだけでなく選択済みになっていることを確認します。続いて「ログ」画面を開き、YAMLの解析エラー、存在しないポリシー名、ポートの待ち受け失敗などがないか確認してください。サブスクリプションの更新に失敗しても、直前に正常に読み込んだ設定を使い続けるクライアントがあります。更新日時とノード一覧もあわせて確認しましょう。

• ノードが0件：まずサブスクリプションの取得結果を確認します。システムプロキシが原因とは限りません。
• ポリシー名が存在しないというエラー：ルール、プロキシグループ、ノードプロバイダーの参照先が一致しているか確認します。
• アドレスが使用中というエラー：別のクライアントがローカルプロキシのポートを使用していないか確認します。
• ノードは表示されるがすべて失敗する：サブスクリプションの有効期限、ネットワークへの到達性、コアのプロトコル対応を確認します。

プロキシグループをたどってノードを選ぶ

「プロキシ」画面を開き、まずモードを「ルール」に設定してから、ルールで実際に参照されているプロキシグループを探します。たとえば、設定内のルールが「Webプロキシ」を参照し、そのグループで「手動選択」が選ばれている場合は、「手動選択」を開いて具体的なノードを選ぶ必要があります。関係のない別のグループでノードを選んでも、このルールの出口は変わりません。

selectタイプは手動選択、url-testは通常ヘルスチェックの結果に基づく自動選択、fallbackは利用可能な項目を順番に選択します。load-balanceでは接続ごとに異なる出口が割り当てられる場合があります。初回の切り分けでは、既存の手動選択グループを使ってノードを1つに固定し、自動切り替えによる影響を抑えましょう。

グループ内で DIRECT が選択されている場合、その接続は直接接続されます。REJECT が選択されている場合は、接続が拒否されます。グループ名に「プロキシ」とあっても、プロキシノードが選ばれているとは限りません。現在の選択項目を確認してください。

ノードの遅延測定：数値の見方

「プロキシ」画面で行うノードの遅延測定は、通常、コアが測定対象のノード経由で指定URLにアクセスし、所要時間を記録するものです。OSのICMP pingやダウンロード速度の測定とは異なります。測定URL、タイムアウト時間、DNSの状態、TLSハンドシェイク、接続の再利用などが結果に影響します。

一度の順位だけで判断せず、条件をそろえて再測定する

1. 同じ測定URLを使い、まず候補ノードを2～3個、1つずつ順番に測定します。一括測定による結果への影響を避けてください。
2. 候補ノードごとに3回測定します。各回の間隔を約5秒空け、成功回数と結果のばらつきを記録しましょう。
3. ネットワーク環境を統一し、測定中にWi-Fi、モバイル回線、有線接続を切り替えないでください。
4. ノードを選んだら、実際に利用するサイトやサービスへアクセスし、新しい接続と応答を確認します。

たとえば、測定例の一方が 85 / 92 / 88 ms、もう一方が 48 ms / Timeout / 410 ms なら、前者のほうが安定性を引き続き確認する候補として適しています。これらの数値は判断方法の例であり、本サイトでの測定結果ではありません。遅延の小さいノードでも、出口の混雑、接続先による制限、帯域上限の影響を受ける場合があります。ダウンロード速度を保証するものではありません。

通信経路の入口を確認する：システムプロキシと明示的なプロキシテスト

ブラウザーではまずシステムプロキシを試す

クライアントで「システムプロキシ」を有効にし、システムプロキシ設定に従うブラウザーで新しいページを開きます。システム設定を上書きしないよう、ブラウザー独自のプロキシ拡張機能は一時的に無効にしてください。クライアントの「接続」画面を開いてから新しいリクエストを実行し、該当するドメイン、宛先ポート、ポリシーの経路が表示されるか確認します。

システムプロキシは、システム全体の通信を取り込む機能ではありません。一部のコマンドラインツール、ゲーム、アプリはシステムプロキシを無視します。ブラウザーでは接続できてもターミナルでは接続できない場合、ノードが使えないとは限りません。ツール固有のプロキシオプションを使うか、必要に応じてTUNを設定してください。

curlでローカルポートを明示する

以下では、現在の実行設定でHTTPまたは混合プロキシのポートが 7890 であると仮定します。コマンドを実行する前に、クライアントのポート設定で実際の値を確認してください。例をそのまま使うためにサブスクリプション全体を書き換えないでください。混合ポートはHTTPとSOCKSの両方のプロキシ接続を受け付けますが、SOCKS専用ポートは以下のHTTPプロキシ形式には使えません。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

Windows PowerShellでは curl.exe を使うと、旧環境の同名エイリアスによる引数の解釈違いを避けられます。200 Connection established と表示されても、ローカルプロキシがHTTPSトンネルのリクエストを受け付けたことを示すだけです。続けて接続先からの応答、または最終的なエラーを確認してください。接続先が 301 や 403 を返しても、プロキシ接続の失敗とは限りません。

ローカルポートがSOCKS5に対応している場合は、次のように指定すると、curlが接続先ドメインをローカルで名前解決せず、ドメイン名を含むリクエストをSOCKS経由でプロキシ側に渡せます。

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

ルールの適用状況と出口IPでプロキシの動作を確認する

モードのオン・オフより接続の詳細を確認する

「接続」画面でテスト対象のドメインを絞り込み、宛先アドレス、適用されたルール、接続経路を確認します。表示項目はクライアントによって異なりますが、見るべき点は同じです。リクエストがコアに届いているか、どのルールがポリシーを決めたか、プロキシグループが最終的にどの出力先を使っているかを確認しましょう。通信量のカウンターが増えていても、バックグラウンド更新や別のアプリの接続かもしれません。対象のリクエストを確認する代わりにはなりません。

• ドメインルールに一致：ルールの適用先が想定したプロキシグループか確認します。
• フォールバックルールに到達：末尾の MATCH がプロキシと直接接続のどちらを指しているか確認します。
• ポリシーの経路にDIRECTが含まれる：これは直接接続の結果です。システムプロキシを有効にしていても変わりません。
• 切り替え後も古いノードが使われる：既存の接続では以前の経路が再利用されることがあります。接続を作り直してから確認してください。

ルールは通常、上から順に照合され、最初に一致したルールで処理が決まります。切り分けでは末尾のフォールバックだけでなく、それより前のドメインルール、IPルール、ルールセットによってリクエストが処理されていないかも確認してください。カスタムルールとサブスクリプション更新後の保持方法については、使い方ガイドのカスタムルールの説明をご覧ください。

直接接続の基準を確認してからプロキシ出口を調べる

まずTUNとシステムプロキシを無効にし、ほかのVPNやプロキシツールも停止して、次のコマンドで現在のネットワークのパブリックIPv4アドレスを調べます。この操作では外部のIP検索サービスにリクエストを送信します。サービス側に接続元が記録される可能性があることを了承した場合のみ実行してください。

curl -4 --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

続いてTUNは無効のままローカルプロキシを起動し、明示的なプロキシオプションを付けてもう一度調べます。検索ドメインへの通信が、選択したノードを通るルールになっていることを確認してください。

curl -4 --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "*" はcurlにアプリケーション層のプロキシ設定を使わせないオプションであり、動作中のTUNやほかの透過型の通信取り込みを回避するものではありません。そのため、基準値を調べる前にこれらを無効にすることが重要です。2回の結果が異なり、2回目の接続経路に選択したノードが含まれていれば、プロキシ出口が機能している有力な証拠になります。結果が同じ場合は、ルールによる直接接続、検索結果のキャッシュ、プロキシとローカル回線で出口を共有している可能性などを確認してください。

IPアドレスの地域情報はデータベースに基づく推定であり、古くなっている場合があります。IPv4の検索結果だけでは、IPv6やすべてのUDP通信の経路はわかりません。また、それだけでDNS漏えいがないことも証明できません。検証対象を具体的なアプリ、アドレスファミリー、プロトコルに絞り、一度の成功を「すべての通信がプロキシ経由」と拡大解釈しないようにしましょう。

TUNとよくある失敗：レイヤーごとに切り分ける

システムプロキシに従わないアプリの通信も取り込みたい場合は、TUNを検討してください。仮想ネットワークアダプターとルーティングを使って通信を取り込むため、通常はサービスの権限、ルート設定、DNSの処理が関係します。スイッチをオンにしただけでは有効化の操作を始めたことしかわかりません。仮想ネットワークアダプターとルートが作成されたか、対象アプリの新しい接続がどうなったかも確認しましょう。mihomoベースのクライアントでも初期設定は異なる場合があります。画面が似ているだけで動作も同じだと判断しないでください。

詳細ログへの変更は一時的にする

まず通常のログレベルで問題を一度再現します。情報が足りない場合は、一時的に debug に上げ、失敗時刻と接続先ドメインを記録してください。確認後は元のレベルに戻します。エラーの内容によって問題の段階は異なります。接続拒否はローカルの待ち受け、名前解決失敗はDNS、ハンドシェイク失敗はノードのパラメーターや証明書、サーバー側の問題が考えられます。タイムアウトの場合は、発生箇所とあわせて判断してください。

スクリーンショットやログを共有する前に、サブスクリプションURL、認証情報、コントロールインターフェースのキー、個人のアクセス履歴を隠してください。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、トラブル対応のために公開コメント欄へそのまま貼り付けないでください。システムに関するよくある質問は、Clashのよくある質問もご覧ください。

初回接続後の確認チェックリスト

一連の確認が終わったら、一度の遅延順位を覚えるより、繰り返し使えるテスト方法を記録しておくと便利です。ネットワーク、ノード、ルールの更新後も、同じ対象を使って再確認できます。毎回クライアントを再インストールする必要はありません。

1. 現在有効な設定、コアの名称、実際のローカルプロキシポートを記録する。
2. 使用可能なノードを1つに固定し、同じ条件で遅延を3回以上測定する。
3. 明示的なプロキシリクエストでローカルの入口が使えることと、接続先から応答があることを確認する。
4. 総通信量だけでなく、接続の詳細でルール、プロキシグループ、最終ノードを確認する。
5. 直接接続時の結果とプロキシ出口を比較し、IPv4とIPv6のどちらを測定したか記録する。
6. 必要に応じて自動選択に戻すかTUNを有効にし、実際のアプリで改めて確認する。

プロキシが機能しているかは、「対象リクエストがコアに届く」「ルールが正しいポリシーを指す」「最終的な出力先が想定どおり」の流れで判断します。遅延の数値は候補ノード選び、出口の検索は経路の確認、接続ログは両者の関連付けに役立ちます。この3種類の情報は互いに代用できません。