Clashの初回接続トラブルシューティング｜ノード選択・遅延テスト・プロキシ確認

1. 設定・コア・通信の入口を確認する

サブスクリプションの読み込みに成功しても、クライアントが設定を取得・認識しただけで、通信がノード経由になったとは限りません。プロキシ通信は少なくとも、アプリがローカルの入口にリクエストを渡し、mihomo がルールに沿ってポリシーを選び、ポリシーグループがノードを決定し、そのノードが接続先へつなぐ、という4段階を経ます。何度もサブスクリプションを更新するより、この流れに沿って一つずつ確認するのが効果的です。

この記事では、mihomo コアを使うデスクトップクライアントを中心に説明します。クライアントによってボタンの位置は異なりますが、まず「設定」「プロキシ」「接続」「ログ」にあたる画面を探し、システムプロキシまたは TUN の状態を確認してください。Android は通常 VpnService で通信を制御するため、デスクトップのシステムプロキシ設定をそのまま当てはめる必要はありません。

テスト前に確認する4項目

1. 設定が有効になっている：サブスクリプション名が表示されるだけでなく、現在の設定として選択されていることを確認します。「ダウンロード済み」と「有効化済み」は別の状態です。
2. コアが動作している：設定の解析失敗、ポートの競合、プロセスの終了がログに繰り返し記録されていないことを確認します。プロトコルが未対応の場合は、クライアントが使用するコアを確認してください。
3. ルールモードを使う：最初の確認では「ルール」または rule を選び、現在選択されているポリシーグループを記録します。ルールと DNS を同時に変更しないでください。
4. 通信を制御する経路は一つにする：デスクトップでは、ほかのプロキシソフトや VPN を終了し、まずシステムプロキシだけでテストします。システムプロキシに従わないアプリも制御する必要がある場合に、TUN を試してください。

2. ノード選択：実際に適用されるポリシー経路を確認

「プロキシ」画面のカードは、ノードの場合もポリシーグループの場合もあります。手動選択グループ select は指定した項目を使用します。自動テストグループ url-test はテスト結果と許容範囲をもとに選択し、フェイルオーバーグループ fallback は通常、設定順に利用可能な項目を選びます。地域名の付いた項目が一つ表示されているだけで、出口が切り替わったと判断しないでください。

たとえば、ルールがリクエストを「ウェブ閲覧」グループに渡し、そのグループがさらに「自動選択」を選ぶと、最終的に特定のノードが使われます。この場合、別の「手動ノード」グループを変更しても、今回のアクセスには反映されないことがあります。プロキシ画面で強調表示されたカードだけを見るのではなく、接続の詳細でポリシーの経路を追ってください。

初回にノードを選ぶ手順

1. クライアントの「プロキシ」画面を開き、接続先へのアクセスに使われるポリシーグループを探します。まだ分からない場合は、メインの選択グループ名を記録してください。
2. 手動選択できるグループから、名前が明確でテストに成功したノードを一つ選びます。複数階層のグループを同時に切り替えるのは避けてください。
3. 接続先に再度アクセスし、「接続」画面でルール、ポリシーグループ、最終的に選択されたノードを確認します。
4. ノードを変更するときは、この項目だけを切り替えて同じテストを繰り返します。接続先の URL とネットワーク環境は変えないでください。

地域名はサービス提供者が付けたラベルであり、物理的な距離や実際の出口を証明するものではありません。初回のテストでは地理的に近い地域を候補にできますが、最終的には接続成功率、繰り返しテスト時の変動、実際のサービスへのアクセスで判断してください。サブスクリプションの期限切れ、通信量の超過、サーバー側の認証失効によって、複数のノードが同時に利用できなくなることもあります。

3. 遅延テスト：ミリ秒の数値から分かること

クライアントの遅延テストでは通常、指定したノード経由でコアがテスト用 URL にリクエストを送り、所要時間または失敗を表示します。一般に ICMP ping やダウンロード速度の測定とは異なります。接続確立を測定に含めるか、接続を再利用するか、成功をどう判定するかは、コアの実装や設定によって異なります。テスト先やクライアントが異なる数値を、そのまま横並びで比較するのは適切ではありません。

テスト先を固定して3回繰り返す

約10秒間隔で3回テストし、結果を記録します。以下は判定例であり、本サイトでの実測値ではありません。ノードAが82、88、85 ms、ノードBが48、760 ms、タイムアウトだった場合、初めて使うならBの最小値だけで選ぶより、Aで安定性を確認するのが適切です。大容量ファイルの転送速度、動画のバッファリング、ゲームの UDP 通信は、それぞれ別にテストする必要があります。

すべてのノードが同時にタイムアウトする場合は、まずクライアントのテスト先を確認してください。特定の測定サイトに接続できないために、正常なノードまで失敗と表示されることがあります。クライアントの速度テスト設定で、信頼できて応答の軽い別の HTTPS アドレスに変更して比較できます。テストに失敗したからといって、サブスクリプション全体をすぐに上書きしないでください。

4. システムプロキシの確認：ローカルポートを指定してテスト

デスクトップのシステムプロキシ設定は、システム設定に従うアプリにローカルプロキシを使わせるものですが、すべてのプログラムを自動的に制御するわけではありません。コマンドラインツール、独自のプロキシ設定を使うブラウザー、一部のゲームや UDP アプリは、別の経路を使うことがあります。まずクライアントに表示されている HTTP ポートまたは mixed-port を確認し、プロキシを明示してテストすると、「ノードの問題」と「システム側の通信制御の問題」を切り分けられます。

ポートとシステム設定を確認する

• Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。クライアントが自動構成スクリプトを使う場合は、該当する項目も確認してください。
• macOS：「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開き、Web プロキシまたはセキュア Web プロキシの設定を確認します。
• クライアント：ローカルの待ち受けポートを確認します。以下では 7890 を例にします。実際の HTTP ポートまたは mixed-port がこの値の場合に限り、コマンドをそのまま実行できます。

ローカルプロキシのアドレスは通常 127.0.0.1 です。設定で SOCKS ポートしか公開していない場合、以下の HTTP プロキシ用コマンドをそのまま使わないでください。適切なプロトコルを選ぶか、クライアントの mixed-port を使います。ローカルでのテストに「LAN に接続を許可」を有効にする必要もありません。

# macOS / Linux：ローカルの HTTP ポートまたは mixed-port を明示して使用
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output /dev/null https://example.com/

# Windows PowerShell：古い環境でのコマンドエイリアスの違いを避けるため curl.exe を使用
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output NUL https://example.com/

--connect-timeout 10 は接続時の待ち時間を制限し、--max-time 20 はリクエスト全体の制限時間を設定します。例にある接続先は疎通確認用であり、すべてのサービスが利用可能かどうかは判断できません。--proxy で指定するのはコアへの入口だけです。最終的にリモートノードを経由するかは、現在のモードとルールによって決まります。

• ローカルポートへの接続が拒否される：コアが動作しているか、ポート番号が正しいか、そのポートが HTTP プロキシに対応しているかを確認してください。
• CONNECT 200 が表示される：プロキシがトンネル確立リクエストを受け付けたことを示します。続けて TLS と最終的な HTTP 応答を確認してください。この行だけでアクセス全体の成功とは判断できません。
• プロキシを明示すると成功するが、ブラウザーでは失敗する：サブスクリプションをすぐに変更せず、システムプロキシ、ブラウザー拡張機能、個別のプロキシ設定、既存の接続を優先して確認してください。

5. 接続パネルでルールと最終的な出口を確認

ブラウザーでページを開けても、リモートプロキシ経由とは限りません。DIRECT に振り分けられている場合もあれば、リクエストがコアに届いていない場合もあります。有効な確認には、接続パネルに新しいリクエストが表示されること、想定したルールに一致すること、ポリシー経路が想定したノードに到達すること、という3つの証拠が必要です。

通信量全体ではなく、1件のリクエストを確認する

1. 「接続」画面を開いて現在時刻を記録し、ブラウザーで新しいウィンドウを開いて確認対象にアクセスします。
2. 接続先のドメインで接続を絞り込みます。接続がすぐ終了する場合は、あらかじめログを開いて確認してください。終了済みの接続を保持しないクライアントもあります。
3. 詳細を展開し、接続先のドメインまたは IP、適用ルール、ポリシー経路、送受信バイト数を確認します。プロセス名が表示されるかはプラットフォームや権限によるため、必須の証拠ではありません。
4. DIRECT と表示された場合は、ルールの設計どおりかを確認してください。ルールモードでは、ローカルサービスや一部のサイトが直接接続になるのは正常な振り分けです。
5. ノードを変更したら、古いタブを閉じるか該当する既存の接続を終了してから、新しいリクエストを送ります。確立済みの TCP 接続は、ポリシーを切り替えても通常は自動で移行しません。

出口 IP の確認は補助的な方法として使えます。同じ確認サービスを使って、直接接続時と想定したプロキシ経由時の結果を比較し、そのアクセスが実際にプロキシのポリシーに一致したことを接続パネルで確認してください。異なるサイトが表示する地域名だけを比べないでください。データベースや IPv4・IPv6 の違いで誤判定することがあります。出口 IP が変わっても、その確認リクエストの経路が分かるだけで、すべてのアプリが制御されている証明にはなりません。

6. TUN とよくあるトラブル：変更する条件は一つずつ

プロキシを明示したテストには成功するのに、特定のプログラムが接続パネルに表示されない場合は、TUN を検討します。TUN は仮想ネットワークインターフェースと関連するルートを使って通信を制御し、システムプロキシに従わないアプリに適しています。ただし、引き続きコアのルールとポリシーグループが使われるため、すべてのリクエストがリモートノード経由になるわけではありません。有効化には管理者権限、サービスモード、ドライバーの対応が必要な場合があります。クライアントの案内に従ってください。

短時間だけグローバルモードで比較し、確認後にルールモードへ戻す

ルールモードで接続先にアクセスできない場合は、一時的にグローバルモードへ切り替え、GLOBAL グループで同じ利用可能なノードを明示的に選んでから、接続をやり直します。グローバルモードでは成功し、ルールモードでは失敗する場合は、接続先に適用されたルールとポリシーを確認します。どちらでも失敗する場合は、ノードと接続先のサービスを引き続き調べてください。グローバルモードは比較診断用です。コアに届いていないアプリの通信が、自動的にプロキシへ流れるわけではありません。

トラブルシューティング中に、ノードの切り替え、DNS の変更、TUN の有効化、ルールの更新を同時に行わないでください。原因を特定できなくなります。各手順で「時刻、接続先、モード、入口ポート、ノード、エラー内容」を記録すると、問題を再現しやすくなります。ログに記録された timeout、connection refused、認証エラーは、それぞれ問題の箇所が異なります。「ネットワークにつながらない」と一括りにせず、エラーに応じて対処してください。

7. 初回接続が成功したと判断する基準

• 現在の設定が有効で、mihomo コアが正常に動作し、ローカルプロキシのポートに接続できる。
• 候補ノードで同じテスト先への接続を繰り返し確認でき、タイムアウトが続かない。
• アプリから送った新しいリクエストが接続パネルに表示され、想定したルールに一致する。
• プロキシが必要なリクエストは想定したノードに到達し、直接接続するリクエストは想定どおり DIRECT になる。
• 実際に利用するサービスへアクセスできる。グローバルモードでの結果だけで終わらせず、ルールモードに戻して再確認する。

この5項目を確認すれば、ローカルの入口から最終的な出口までの経路を裏付ける証拠がそろいます。今後接続が切れたときも同じ順序で確認し、まず変化した箇所を特定してから設定を調整できます。サブスクリプションの読み込みやシステム通信の制御手順は入門ガイドを、設定の仕組みやパラメーターはドキュメントをご覧ください。