初回接続時の確認手順

まず設定を有効にし、次にノードを選択してから、通信のプロキシ経由を有効にします。Clash Meta が使用する mihomo コアは設定の解析、ルール判定、アウトバウンド接続を担当し、クライアントの画面ではサブスクリプションの管理や各種スイッチの操作を行います。「サブスクリプションの追加に成功」と表示されても、設定を取得できたことを示すだけで、ブラウザーの通信がプロキシ経由になったとは限りません。

  1. 設定が有効か確認する：設定一覧で追加したサブスクリプションを選択し、コアのログを確認します。YAMLの解析エラーや、参照先のないプロキシグループなどの問題がないか確認してください。
  2. ルールモードに切り替える：画面上では「ルール」または「Rule」と表示される場合があります。初回の動作確認では、サブスクリプションのルールをそのまま使い、DNSやルールセット、TUNの設定を同時に変更しないでください。
  3. 有効なアウトバウンドを選ぶ：プロキシまたはプロキシグループの画面を開き、対象サイトで使われるグループを見つけて、利用可能なノードを選択します。
  4. 通信の経路制御を有効にする：ブラウザーでの初回テストでは、まずシステムプロキシを使います。システムプロキシを参照しないアプリも対象にする場合は、TUNモードを別途検証してください。
  5. 新しいリクエストを送信する：接続履歴、ルールのマッチ状況、出口IPを確認して判断します。スイッチの色だけで動作を判断しないでください。

プロキシグループで選ぶノード

プロキシグループは、ルールとアウトバウンドの間にある選択レイヤーです。たとえば、あるサイトへの通信をルールが PROXY に振り分け、そのグループがノードまたは別のプロキシグループを選びます。グループ名は設定の作成者が付けるため、「ノード選択」「海外サイト」などさまざまです。名前だけで用途を判断しないでください。

ルールから最終的なアウトバウンドをたどる

  1. クライアントでプロキシ一覧を開き、手動選択グループを展開します。設定上のタイプは通常 select です。
  2. DIRECT と REJECT は選ばないでください。前者は直接接続、後者は接続拒否を意味し、いずれもリモートプロキシノードではありません。
  3. 別のプロキシグループが選択されている場合は、さらに展開して、最終的に具体的なノードへ接続されていることを確認します。直接接続に戻っていないかも確認してください。
  4. 選択後、対象サイトに再度アクセスし、接続履歴でリクエストが使ったグループとアウトバウンドを確認します。

初回接続では、ノードを一つ手動で固定するのがおすすめです。自動遅延測定グループ url-test は、設定されたテストURL、間隔、許容誤差に基づいてアウトバウンドを選びます。フェイルオーバーグループ fallback は通常、登録順に利用可能なメンバーを選択します。どちらも「ダウンロード速度が最速」という意味ではありません。最初にノードを固定すれば、テスト中の自動切り替えによる影響を抑えられます。

ノード名だけで実際の状態は判断できない

ノード名に含まれる地域、倍率、回線の説明はサブスクリプション提供元によるもので、コアが測定した事実ではありません。地域名が付いていても、出口IPの所在地が別の地域として表示される場合があります。また、位置情報データベースの更新が遅れていることもあります。初回接続では、まずノードが使えることとルールが正しいことを確認し、その後、利用するサービスに合わせて地域や安定性を比較してください。

ルールモードでは、日本国内のサイトは直接接続、海外のサイトはプロキシ経由となる設定がよく使われます。そのため、ルールで直接接続に振り分けられるサイトを開いても、選択したプロキシノードが通信に使われている証明にはなりません。

遅延テストの数値とタイムアウトの意味

クライアントの遅延テストは、通常のICMP Pingとは異なります。mihomoでは指定したURLへノード経由でHTTPまたはHTTPSのリクエストを送り、その応答時間を表示する方法がよく使われます。テスト先、接続の再利用、DNS、TLSハンドシェイク、接続先サイトの応答などが結果に影響します。クライアントやテストURLが異なる数値を、そのまま比較するのは適切ではありません。

同じURLで3回続けて測定する

クライアントでテストURLを設定できる場合は、たとえば https://www.gstatic.com/generate_204 に統一し、タイムアウトを 5000 ミリ秒に設定できます。このURLはよく使われるテスト先の一つですが、すべてのネットワークやノードからアクセスできるとは限りません。サブスクリプションでヘルスチェック用URLが指定されている場合は、まず元の値を記録してください。テスト先の障害をノードの障害と誤認するのを防げます。

  • 数値が小さい：今回のテストが短時間で完了したことを示します。動画の通信速度が速いことや、目的のサイトにアクセスできることを保証するものではありません。
  • 数値の変動が大きい：無線ネットワーク、異なるネットワーク間の経路、ノードの混雑、テスト先の応答などが原因として考えられます。同じ条件で再測定してください。
  • Timeout（タイムアウト）：制限時間内にテストが完了しなかったことを示します。ノードに接続できない場合だけでなく、テスト先がブロックされている、名前解決に問題がある、ノード認証に失敗している場合もあります。
  • 空欄または未測定：まずテストを実行してください。表示が空欄というだけで、ノードが使えないとは限りません。

たとえば、あるノードの測定値が 86 ms、92 ms、89 msで、別のノードが 45 ms、タイムアウト、610 msだった場合、初回接続では前者を優先して確認できます。この数値は判断方法を説明するための例であり、当サイトでの実測値ではありません。1回だけの最小値より、安定してリクエストが完了することのほうが参考になります。

システムプロキシとローカルポートの確認

クライアントの設定で「システムプロキシ」のスイッチと、実際の待ち受けポートを確認します。メニューの場所はクライアントによって異なるため、画面表示と有効な設定を基準にしてください。システムプロキシは、プロキシアドレスをOSの設定に反映する機能です。この設定に従うアプリだけが利用し、コマンドラインツール、ゲーム、独自のネットワーク機能を持つ一部のアプリは無視することがあります。

ローカルポートとノードのポートを区別する

127.0.0.1:7890 は、自分の端末上にあるプロキシの入口を示すもので、リモートノードのアドレスではありません。以下は説明用の mihomo 設定例です。7890 はサンプルのポート番号で、すべてのクライアントの標準値ではありません。この例は待ち受けとモードだけを示しており、接続可能なノード、プロキシグループ、ルールは含まれていません。サブスクリプション全体をこの内容で置き換えないでください。

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port は、同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。クライアントに実際のポートが 7897 と表示されている場合は、以降のコマンドでも 7897 を使用してください。コントロールAPI用のポート 9090 を通信プロキシのポートとして使わないでください。コントロールAPIはコアの管理用で、ここで説明しているHTTPプロキシの入口ではありません。

まず明示的なプロキシ接続で問題を切り分ける

macOSまたはLinuxでは、次のコマンドを実行できます。Windows PowerShellでは、環境によって同名のエイリアスが引数の解析に影響することがあるため、コマンド冒頭の curl を curl.exe に置き換えてください。

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

このコマンドはローカルのHTTPプロキシを明示的に使い、今回のリクエストではプロキシを使わない宛先の一覧を空にします。「ローカルプロキシの入口が動作しているか」と「アプリがシステムプロキシを使っているか」を切り分けるのに役立ちます。リクエストが mihomo に届いた後は、現在のルールが適用されます。そのため、IPが表示されてもリモートノード経由とは限りません。接続履歴も確認してください。

  • すぐに接続拒否になる：コアが起動しているか、ポート番号が正しいか、ほかのプログラムがポートを使用していないかを確認してください。
  • 接続後にタイムアウトする：ノードのハンドシェイク、DNS、上流への接続に関するログを確認してください。システムプロキシのスイッチを何度も切り替えるのは避けましょう。
  • コマンドは成功するのにブラウザーで失敗する：クライアントの再インストールを急ぐ前に、ブラウザー拡張機能、個別のプロキシ設定、PAC、既存の接続を確認してください。

ブラウザーと出口IPで動作を照合する

確認するのは、追跡できる通信経路ができているかどうかです。新しいリクエストが mihomo に届き、想定したルールに一致し、想定したアウトバウンドを選んで応答を受け取ることを確認します。出口IPは補助的な証拠です。接続履歴を見れば、そのリクエストが直接接続されたか、プロキシ経由になったかを確認できます。

基準値を記録してから、同じ宛先で比較する

  1. TUNとシステムプロキシを無効にし、ほかのVPNも使っていない状態で、ブラウザーから https://api.ipify.org にアクセスして現在の出口IPを記録します。このアクセスにより、IP確認サービスに出口アドレスが送信されます。
  2. システムプロキシを有効にし、同じネットワークとテスト先を使います。古いタブを閉じてから再アクセスしてください。必要に応じてブラウザーを終了して再起動し、既存の接続が再利用される影響を抑えます。
  3. クライアントの「接続」または「Connections」画面で api.ipify.org を探します。一致したルール、プロキシグループの経路、最終的なアウトバウンドを記録してください。短いリクエストはすぐに一覧から消えることがあるため、ログも併せて確認できます。
  4. このドメインが DIRECT に一致した場合は、現在のルールでプロキシ経由になるはずの別のテスト先を使います。または、影響を理解したうえで、一時的にグローバルモードでテストしてください。

グローバルモードではルーティング先が変わりますが、グローバル用プロキシグループでリモートノードを選ぶ必要があります。DIRECT を選べば直接接続のままです。テスト後はルールモードに戻し、一時的なテスト設定を日常の設定として使わないようにしてください。

出口IPが基準値と異なり、接続履歴にも選択したノードが表示されていれば、動作していることを示す有力な証拠になります。IPが変わらない場合は、ルールも確認してください。リクエストが直接接続されている可能性のほか、プロキシの出口と元のネットワークが同じパブリックIPを共有している可能性もあります。反対に、別のVPNやネットワークの切り替えによってIPが変わる場合もあるため、IPだけで判断しないでください。

よくある失敗の切り分け手順

ノードに遅延値は表示されるが、Webページが開かない

まず明示的なプロキシ接続のコマンドを実行します。コマンドが成功する場合は、ブラウザーがシステムプロキシを使っているか確認してください。コマンドも失敗する場合は、そのリクエストに適用されたルールとアウトバウンドを確認します。テストURLには接続できても目的のサイトにアクセスできない場合、接続先の制限、DNS、プロトコルの違い、ノードの回線などが原因として考えられます。一つのテスト結果をすべてのサイトに当てはめないでください。

IPは変わったが、コマンドラインは直接接続のまま

ブラウザーとターミナルでは、通信の経路制御が異なります。ターミナルのツールでは、独自のプロキシ引数や http_proxy、https_proxy 環境変数の設定が必要な場合があります。初回の確認では、単一コマンドに --proxy を指定して動作を検証してください。成功を確認してから、環境変数の常時設定を検討します。変数を変更した場合は、新しいプロセスに設定が引き継がれていることも確認してください。

通常のWebページは開くが、ゲームやUDPを使うアプリは動かない

HTTPリクエストの成功で確認できるのは、その通信経路が使えることだけで、UDPの利用可否は分かりません。アプリの通信経路制御、ノードのプロトコル、サーバー側のUDP対応をそれぞれ確認してください。TUNで通信を制御できる範囲は広がりますが、UDP非対応のリモートノードが対応するようになるわけではありません。TUNを有効にする前に、システム権限、仮想ネットワークアダプター、ほかのVPNとのルート競合も確認してください。

ノードを切り替えても、サイトに以前の出口IPが表示される

すでに確立した長時間接続は、すぐに別のノードへ切り替わるとは限りません。対象のページやアプリを閉じ、必要に応じてクライアントで関連する接続を閉じてから、リクエストを送り直してください。すべての接続を切断すると、ダウンロードや会議なども中断されます。実行前に影響を確認してください。また、変更したプロキシグループが対象ルールから実際に参照されているかも確認し、使われていないグループだけを変更していないか確かめましょう。

初回接続後に記録しておくこと

「使えた」と記録するだけでなく、再現できる情報を手元に残しておくと、後から問題を調べやすくなります。次の5項目を保存するのがおすすめです。サブスクリプションURL、認証情報、設定全体を公開する必要はありません。

  • 実行環境：OSのバージョン、クライアントのバージョン、画面に表示される mihomo コアのバージョン。
  • 有効な設定：現在の設定名、最終更新日時、ルールモードまたは一時的なグローバルモード。
  • アウトバウンドの選択：ルールが参照するプロキシグループ、最終ノード、同じ宛先で測定した3回分の遅延値。
  • 通信の経路制御：システムプロキシまたはTUN、実際のローカルポート、ほかのVPNを同時に実行しているかどうか。
  • 確認結果：テスト日時、テストドメイン、一致したルール、出口IP、リクエストの結果。

最後にルールモードへ戻し、安定して使えるノードを一つ選んでから、ターミナル、ダウンロードツール、ゲームを一つずつ確認します。サブスクリプションの更新でプロキシグループ名やルールが変わった場合は、最終的なアウトバウンドを改めて確認してください。初回接続の完了は、遅延値が一つ表示されることではありません。対象アプリの新しいリクエストが想定したルールで転送され、安定して応答を受け取れることが完了の目安です。