Clashの初回接続チェックリスト｜ノード選択・遅延テスト・プロキシ動作確認

1. 接続前の確認：設定・コア・通信の入口

サブスクリプションのインポートに成功しても、クライアントが設定を取得できたことを示すだけで、通信がmihomoコアに入ったとは限りません。初回の動作確認は、設定の読み込み、通信の入口、プロキシグループのノード選択、対象接続の実際の出先の4段階に分けて行います。DNS、TUN、ルールを同時に変更すると、問題の原因を特定しにくくなるため避けましょう。

1. 現在の設定を確認。クライアントの「設定」または「Profiles」画面を開き、選択中の項目がインポートしたばかりのサブスクリプションか確認します。ダウンロードしただけで有効化していない設定は、実行中のルールやノードを置き換えません。
2. コアの稼働を確認。起動ログに設定の解析エラー、待ち受けポートの競合、プロセスの終了記録がないか確認します。YAMLの解析エラーがある場合は、ノードを切り替える前に設定を修正してください。
3. ルールモードを選択。初回接続は通常、Rule／ルールモードから始めます。Global／グローバルモードは一時的な比較用です。Direct／直結モードは、ノード経由のプロキシ動作を確かめる際の出発点には適しません。
4. 実際のポートを確認。クライアントの設定または有効な設定ファイルでHTTP／混合ポートを確認します。たとえば mixed-port: 7890 は、HTTPとSOCKSのプロキシ接続を受け付ける入口を表します。ポート番号は現在の設定に従ってください。

システムプロキシとTUNの使い分け

デスクトップでは、まずシステムプロキシを使ってブラウザーのリクエストを確認すると、問題を切り分けやすくなります。システムプロキシを有効にすると、その設定に従うアプリが該当の入口を使用します。一部のコマンドラインツール、ゲーム、独自にネットワークを管理するアプリはシステムプロキシに従いません。TUNモードは仮想ネットワークインターフェースを通じてルーティングされたIP通信を受け取りますが、対象範囲はルート、除外設定、プラットフォームの権限にも左右されます。スイッチを有効にするだけで、すべての接続がコアに入るわけではありません。

初回テストでは、システムプロキシを制御したりプロキシ用のルートを作成したりするクライアントを同時に2つ起動しないでください。AndroidとiOSでは通常、システムのVPN許可を通じて接続します。許可が完了し、接続が有効な状態を保っているか確認してください。デスクトップのブラウザー向けシステムプロキシの手順をそのまま適用することはできません。

2. プロキシグループの選択：出先を決めるノードを見つける

「プロキシ」→「プロキシグループ」画面には、個別のノードだけでなく、別のプロキシグループが表示されることもあります。ルールが使用するプロキシグループを決め、そのグループが最終的なノードを選択します。対象ルールから参照されていないグループのノードを変更しても、そのWebサイトの通信には影響しません。

初回確認ではノードを固定

1. 対象サイトのルールが参照しているプロキシグループを見つけます。ルールの参照先が不明な場合は、まずサイトにアクセスし、接続記録から逆にたどって確認してください。
2. そのグループで手動選択が可能なら、特定のノードを選びます。テスト中に自動で切り替わると、結果を比較しにくくなります。
3. グループ内で「自動選択」などのサブグループが選ばれている場合は、さらに展開し、外側のグループ名だけでなく実際に使われるノードを確認します。
4. 切り替え後、新しいテスト接続を確立します。既存のTCP長時間接続、HTTP/2接続、QUICセッションは、切り替え直後に新しいノードへ移行するとは限りません。

DIRECTは直結を表し、特殊な名前のプロキシノードではありません。REJECTは接続拒否を表します。ノードが正常に表示されていても、対象ルールの最終出先がこのどちらかなら、遅延テストの値が低くてもリクエストは想定どおりプロキシを経由しません。

3. 遅延テスト：数値・タイムアウト・通信速度の違い

クライアントに表示されるノードの遅延は、単純なICMP pingの値とは限りません。mihomoのURLテストでは、ノード経由で設定されたテスト先にアクセスします。その結果は、ノードへの接続確立、プロトコルのハンドシェイク、テスト先の応答、ローカルネットワークの状態に左右されます。クライアントの計測方法は呼び出し方によっても異なるため、同じテスト条件での比較にのみ使用してください。

条件をそろえてから比較する

• 同じURLを使う：有効な設定の url を確認します。よく使われるテスト先は https://www.gstatic.com/generate_204 です。テスト先が異なる場合、数値をそのまま比較することはできません。
• 同じネットワークで測定：同じWi-Fiまたは有線ネットワークで一連のテストを行い、モバイル回線の結果を混ぜないでください。
• 複数回測定する：3回続けてテストし、各回の結果を記録します。一方の例が82、91、86 ms、もう一方が65、460、タイムアウトなら、安定性の確認には前者を優先するのが適切です。これは数値の例であり、当サイトでの実測値ではありません。
• 単発テストと定期測定を区別する：手動テストではその時点の結果が1回得られます。プロキシグループのヘルスチェックは独自の設定に従って実行されるため、結果が更新されるタイミングが異なることがあります。

以下はプロキシグループの設定例です。各項目を確認するための抜粋であり、既存の PROXY グループを参照しているため、そのままでは完全な設定として動作しません。interval: 300 の単位は秒、tolerance: 50 の単位はミリ秒です。後者は小さな遅延変動による切り替えを抑えるためのもので、リクエストのタイムアウト時間ではありません。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - PROXY
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

遅延が小さくてもダウンロードが速いとは限らない

短いリクエストの完了時間と、継続的な通信のスループットは別の指標です。遅延が70 msのノードでも、出口の帯域幅、混雑、サーバー側の速度制限によってダウンロードが遅くなることがあります。一方、160 msのノードでも、長時間の通信がより安定する場合があります。初回接続では、まずWebページを正常に開けることを確認し、その後、実際の用途に合わせて動画、ファイル転送、応答性をテストしてください。リスト内の最小値だけで常用するノードを決めるのは避けましょう。

4. プロキシ動作の確認：入口・ルール・出口の3つを検証

接続スイッチを見るだけでなく、同じリクエストについて証拠を順に確認するのが確実です。通信がコアに入り、想定したルールに一致し、指定したノードから出ていることを確認します。ブラウザーでWebサイトを開けても、それだけではプロキシが有効とは限りません。サイトがもともと直結可能なら、接続できたことだけではプロキシ経由の証明になりません。

明示的なプロキシ指定でローカルの入口を確認

混合ポートが 7890 と確認できている場合は、以下のコマンドで「アプリがシステムプロキシに従うか」という要因を切り分けられます。Windows PowerShellでは、環境によって同名のエイリアスが引数の解析に影響するのを避けるため curl.exe を使います。macOSとLinuxではコマンド名を curl に変更できます。

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

--noproxy "" は、このコマンドのプロキシ除外リストを空にします。このコマンドで確認できるのは明示的に指定した入口が使えることだけです。システムプロキシが正しく設定されていることを示すものではなく、ルールにプロキシノードを選ばせるものでもありません。ルールによってこのIP確認サービスが直結に振り分けられている場合、表示されるのはローカルネットワークの出口IPである可能性があります。

接続記録で同じアクセスを追跡

1. クライアントの「接続」画面を開き、たとえば api.ipify.org のような対象ドメインで絞り込みます。
2. 新しいリクエストを送信し、対象のドメインまたはIP、適用されたルール、プロキシグループの経路、最終ノードを確認します。短時間で終了する接続はすぐ消えることがあるため、履歴やログもあわせて確認してください。
3. 経路が DIRECT ではなく、最終ノードが手動で選択したものと一致することを確認します。サブグループ名が表示される場合は、実際に選ばれているメンバーも確認してください。
4. 接続記録がまったく見つからない場合は、遠隔ノードの問題と決めつけず、ポート、アプリのプロキシ設定、TUNのルートを先に確認してください。

通常の接続やルールの確認には、ログの info レベルで十分です。さらに詳しく調べる必要がある場合は、一時的に debug を有効にし、調査後に元のレベルへ戻します。クライアントによってログの表示形式は異なるため、文字列の形式が完全に同じである必要はありません。対象、ルール、出先を確認してください。

出口IPを照合

まず直結が許可されたテスト環境で、同じIP確認サービスに直接接続した結果を記録します。次に、プロキシを通ることを確認済みのルールで同じサービスを再度確認します。2回の結果が異なり、プロキシ経由の接続記録が想定したノードを示していれば、より確かな判断ができます。IPの位置情報データベースは更新が遅れることがあり、ノード名の都市とデータベースに表示される都市が一致するとも限りません。

2回の結果が同じ場合は、まずIP確認リクエストが直結ルールに一致していないか確認し、次にプロキシの出口が現在のネットワークと同じパブリックIPを共有していないか調べます。デュアルスタック環境ではIPv4とIPv6を区別してください。IPv4を1回確認しただけでは、IPv6通信もプロキシ経由であることは証明できません。確認画面に特定の結果を表示させるために、IPv6をむやみに無効化しないでください。まずクライアントのIPv6、DNS、ルーティング設定を確認しましょう。

5. よくある問題：症状から確認範囲を絞る

TUNを有効にした後だけ問題が起きる場合は、管理者権限やシステム拡張の許可、仮想ネットワークアダプター、ルート、DNSの取り込みを重点的に確認してください。auto-route や dns-hijack を含む設定例でサブスクリプション全体を上書きしないでください。これらの設定はプラットフォーム、コアのバージョン、クライアントの管理方法によって異なり、誤って上書きすると次回のサブスクリプション更新で置き換えられることもあります。

メンテナーに報告する場合は、OS、クライアントのバージョン、mihomoコアのバージョン、現在のモード、入口ポート、対象ドメイン、個人情報を隠したエラー情報を添えてください。サブスクリプションURL、認証情報、コントロールインターフェースのキーは伏せてください。接続ログにアクセス履歴が含まれる場合もあるため、ファイル全体をそのまま公開しないでください。

6. 初回接続の確認基準

• 現在のProfileが有効になっており、コアが継続して稼働し、ログに設定の読み込みエラーがない。
• テスト対象のアプリの通信がコアに入り、接続画面で該当する宛先を確認できる。
• 対象が想定したルールに一致し、プロキシグループの経路と最終出先が選択内容に一致する。
• 同じテスト条件で遅延を複数回測定し、実際の接続先へのアクセスで利用可能か確認する。
• 出口IPの確認結果と接続記録が一致し、IPv4とIPv6の検証範囲が明確に区別されている。

これらの確認を終えたら、自動選択グループに戻すか、TUNの利用範囲へ広げます。設定を1つずつ変更し、そのたびに新しい接続を確立してください。サブスクリプションの再読み込み、ノードの切り替え、クライアントの再インストールを繰り返すより、問題の原因を見つけやすくなります。基本操作は使い方ガイドで、用語の違いは用語クイックリファレンスで確認できます。