1. 初回接続の確認手順

まずポリシーグループでノードを選び、疎通をテストしてから、アプリの実際の出口を確認します。クライアントに「接続済み」と表示されても、通常はコアやVPNインターフェースが起動したことを示すだけです。ノードに遅延が表示されても、テストリクエストに応答があったことしか分かりません。どちらの状態も、ブラウザーがプロキシを利用している証拠にはなりません。

この記事では、Clashまたはmihomoコアを採用したGUIクライアントを対象に説明します。メニュー名はクライアントによって異なるため、「設定」「プロキシ」「接続」「ログ」などの画面を探してください。初回の確認では、ブラウザー1つ、接続先サイト1つ、手動選択したノード1つに絞り、複数の項目を同時に切り替えないようにします。

  1. 「設定」画面で、サブスクリプションがリストにダウンロードされているだけでなく、有効になっていることを確認します。
  2. 「プロキシ」画面でルールモードを使い、対象サイトに適用されるポリシーグループを探します。
  3. ノードをテストし、利用可能なものを1つ手動で選択します。
  4. システムプロキシを有効にするか、用途に応じてTUNを有効にします。
  5. 新しいWebリクエストを実行し、出口IP、適用ルール、プロキシチェーンを確認します。

2. ポリシーグループで実際に使うノードを選ぶ

サブスクリプションをインポートすると、リストにはノードとポリシーグループの両方が表示されることがあります。ノードにはサーバーとプロトコルの設定が含まれ、ポリシーグループはノードを選択したり、別のポリシーグループを参照したりします。最上位のグループをクリックしただけでは選択が完了していない場合があるため、参照先をたどって最終的な出口を確認してください。

手動選択と自動選択を見分ける

種類・項目意味初回接続時の確認ポイント
selectグループ内のメンバーを手動で選択選択中の項目がノード、または正しい下位グループであることを確認
url-testテスト結果に基づいて自動選択グループ名だけでなく、実際に使われているメンバーを確認
fallbackメンバーの順に利用可能な出口を選択最初に利用可能なメンバーと、そのテスト状態を確認
DIRECTDIRECT（直結）プロキシが必要なリクエストの最終経路がこの項目にならないようにする
REJECT接続拒否誤選択、またはブロックルールに一致していないか確認

たとえば、最上位の「プロキシ選択」が「自動選択」を参照し、その先がノードを参照している場合、実際の経路はポリシーグループ2段とノード1つで構成されます。初回の切り分けでは、設定に手動ノードの選択肢があれば、ノードを直接指定すると自動切り替えによる変数を減らせます。グループ名はサブスクリプションの作成者が設定しているため、名前に「プロキシ」とあっても、プロキシノードが選択されているとは限りません。

ルールモードとグローバルモードの使い分け

  • 普段はルールモードを使用：コアは rules の記述順にルールを照合し、リクエストごとにプロキシ、直結、拒否のいずれかに振り分けます。
  • グローバルモードは比較用：一時的に切り替えた後、GLOBAL で実際に選択されているメンバーも確認します。グローバルモードにしても、システムプロキシやTUNによる通信の取り込みは代替できません。
  • テスト後はルールモードに戻す：IP確認ページに別のアドレスを表示させるためだけに、国内のサービスを含むすべての通信を同じ出口へ恒常的に流さないでください。

ルールモードでは直結、グローバルモードではプロキシ経由になるサイトがある場合、まずルールの照合結果とポリシーグループの選択を確認してください。すぐにクライアントを再インストールする必要はありません。

3. 遅延を一括測定して利用可能なノードを選ぶ

「プロキシ」画面で遅延テストや更新のボタンを探し、まず現在のポリシーグループをテストしてから、応答のあったノードを選びます。テストでは通常、ノード経由で指定URLにアクセスします。所要時間はテスト先、DNS、接続確立、TLS、テストの実装方法などに左右され、ノードサーバーへのICMP Pingとは異なります。

  1. ローカルネットワークが使えることを確認し、サブスクリプションのノードが読み込まれるまで待ちます。
  2. 現在のグループの一括テストを実行し、完了するまで待ちます。連続クリックによる不要な同時実行は避けてください。
  3. 応答のあったノードを1つ選び、約10秒間隔でさらに2回測定して、タイムアウトが繰り返されないか確認します。
  4. 同じWebページを開いて読み込みを確認し、その後で近隣地域の代替ノードと比較します。

判断方法を説明用のデータで見てみましょう。ノードAの3回の結果が82、89、86ミリ秒で、ノードBが45ミリ秒、タイムアウト、310ミリ秒だったとします。初回接続ではAを選ぶほうが適切です。Bは最小値こそ小さいものの、ばらつきとタイムアウトがあり、このテストでは安定性に欠けています。これは特定サービスについて当サイトが実測したランキングではありません。

遅延の小ささはダウンロード速度を示すものではありません。低遅延のノードでも、帯域幅、混雑、接続先サイトの制限、出口の共有状況などの影響を受けます。初回接続の確認では、小さなHTTPSページが安定して開けることを確認すれば十分です。すぐに大容量の速度テストを行う必要はありません。

4. 通信の入口を有効にする：システムプロキシまたはTUN

ノードが使えるようになったら、アプリのリクエストをコアに渡す設定も必要です。システムプロキシは、システムのプロキシ設定に従うブラウザーやアプリに適しています。TUNは仮想ネットワークインターフェース経由で通信を取り込み、システムプロキシを参照しないアプリにも対応できますが、ルーティング、除外設定、クライアントの構成に左右されます。

まずシステムプロキシでブラウザーを確認する

クライアントで「システムプロキシ」を有効にします。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」、macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で設定内容を確認できます。OSのバージョンによって画面名は異なるため、クライアントに表示された待ち受けアドレスとポートを基準にしてください。

以下は各フィールドの意味を確認するためのYAMLの抜粋であり、サブスクリプション全体ではありません。7890は例示用のポートです。クライアントの表示が7897なら、以降のコマンドでも7897を指定してください。クライアントの上書き機能でサブスクリプションの値が変更される場合があるため、実際に動作している設定と待ち受け状態を確認してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
  • mixed-port：同じポートでHTTPとSOCKSのプロキシリクエストを受け付けます。
  • allow-lan: false：LANにプロキシを公開しません。初回のローカル環境での確認では、通常有効にする必要はありません。
  • mode: rule：出口はルールによって決まります。すべてのリクエストがノード経由になるわけではありません。
  • log-level: info：通常の接続情報を確認しやすくします。実際に表示される内容はクライアントとコアによって異なります。

必要な場合にTUNを有効にする

ブラウザーは使えるのにゲームやほかのアプリが直結する場合は、そのアプリがプロキシに対応しているかを確認してから、TUNの利用を検討してください。デスクトップクライアントではサービスモードや管理者権限が必要なことが多く、モバイル端末では通常、システムVPNの許可が必要です。ルートを取り込むVPNクライアントを複数同時に動かすと、デフォルトルートやDNS設定が競合するおそれがあります。

TUNを有効にした後は、テスト接続を新たに確立してください。既存のTCP接続は以前の経路を使い続けることがあります。同じ接続を再利用したページを更新するだけでは、新しい設定が反映されたか確認できない場合があります。

5. 出口IPと接続ログを照合して確認する

確実に確認するには、2種類の証拠が必要です。1つは照会サービスから見た送信元アドレス、もう1つはコアに記録された実際のプロキシチェーンです。照会ページではそのリクエストの出口が分かり、接続ログではコアがその経路を選んだ理由を確認できます。

まず直結時の基準値を記録し、プロキシ利用時と比較する

  1. システムプロキシとTUNを一時的にオフにし、通常のネットワークから公開IPを一度調べます。日時、アドレス、通信事業者の情報を記録してください。
  2. プロキシ設定を元に戻し、先ほどのテストで応答があったノードを選択します。
  3. もう一度IPを調べながら、クライアントの「接続」画面を開き、照会サービスのドメインを検索します。
  4. 一致したルール、宛先アドレス、プロキシチェーンを確認し、最終的なメンバーがDIRECTではないことを確かめます。

IP確認サイトへの通信自体が、ルールによって直結に振り分けられることもあります。アドレスが変わらない場合は、まずログを確認してください。アドレスは変わったのにログに該当リクエストがない場合は、ブラウザー拡張機能や別のVPNがプロキシ処理していないかも調べます。IPの位置情報データベースは更新が遅れることがあり、国名や都市名はあくまで参考情報です。

コマンドを使ってブラウザー設定の影響を切り分ける

以下ではローカルのHTTP混合ポート7890を例に、api.ipify.orgで出口IPv4を調べます。WindowsではPowerShellからcurl.exeを使用し、macOSとLinuxでは同じ引数でcurlを実行します。

# Windows：アプリケーション層のプロキシを使用しない
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows：ローカルHTTPプロキシ経由であることを明示
curl.exe -4 --proxy http://127.0.0.1:7890 --noproxy "" --max-time 15 https://api.ipify.org

--noproxy "*"で回避できるのはcurlのアプリケーション層プロキシだけです。TUNや上流VPNは回避できないため、直結時の基準値を測る前に、これらの通信取り込み機能もオフにする必要があります。2つ目のコマンドはローカルポートの使用を明示しますが、コアではルールが適用されます。「必ずリモートノード経由にする」コマンドではありません。該当リクエストのルールと最終的な出口も確認してください。

正常な接続ログの見方

「接続」画面で絞り込みを設定してから、コマンドをもう一度実行します。短いリクエストはすぐに終了することがあり、接続リストがアクティブな接続しか表示しない場合は「ログ」画面を確認してください。特定の固定形式にこだわらず、次の項目を確認します。

  • 宛先：ドメインが先ほどアクセスしたサービスと一致し、ポートは通常443です。
  • ルール：ドメインルール、ルールセット、または最後のMATCHが該当する場合があります。実際に一致した項目を記録します。
  • プロキシチェーン：想定したポリシーグループを経由し、選択したノードに到達していることを確認します。
  • 結果：リクエストからアドレスが返され、認証、ハンドシェイク、接続のタイムアウトが継続して発生していないことを確認します。

6. 初回接続で問題が起きたときの切り分け

ノードに遅延が表示されるのにブラウザーで開けない

まず、プロキシを明示したcurlコマンドでテストします。コマンドが成功してブラウザーだけ失敗する場合は、ブラウザーが独自のプロキシ拡張機能を使っていないか、システムプロキシを無視していないか、既存の接続を再確立する必要がないかを確認してください。127.0.0.1:7890に接続できないというエラーが出た場合は、待ち受けポートとコアの状態を確認します。この段階では、リクエストはまだリモートノードに到達していません。

出口IPは変わらないのにWebページは開ける

まず照会先のドメインがDIRECTに一致していないか確認し、次にポリシーグループの最終選択を確認します。必要に応じて一時的にグローバルモードに切り替えて比較し、GLOBALのメンバーも確認してください。検証後は元のモードに戻します。企業ネットワーク、上流VPN、同じ出口を使うサービスなどの影響で、アドレスの比較が分かりにくいこともあります。単独の位置情報より、プロキシチェーンの記録を重視してください。

すべてのノードがタイムアウトする

  • サブスクリプションの有効期限、アカウントの通信量、ノードリストの更新状況を確認します。
  • 端末の時刻を確認します。時刻が大きくずれていると、TLS証明書の検証に失敗することがあります。
  • 自宅のWi-Fiからスマートフォンのテザリングに切り替えるなど、別のネットワークでも比較します。
  • ログで名前解決、認証、ハンドシェイクのエラーを確認し、そのうえでDNSを調整するか判断します。

一部のアプリだけプロキシ経由にならない

この場合は、すべてのノードを再測定するより、通信の取り込み設定を確認するのが一般的です。アプリがシステムプロキシを参照するか、UDPやQUICを使うか、TUNのルートにそのアプリが含まれているかを確認してください。HTTPプロキシのコマンドが成功しても、そのHTTPプロキシ経路が使えると分かるだけで、すべてのUDP通信も取り込まれている証拠にはなりません。

問い合わせ時は、クライアント名、コアのバージョン、OSのバージョン、待ち受けポート、操作した時刻、エラーの種類を残してください。スクリーンショットを共有する前に、サブスクリプションURL、認証情報、個人のネットワークアドレスを隠し、設定全体を公開の掲示板に貼らないようにしてください。

7. 初回接続の完了チェック

以下の項目を確認したら、通常の利用に戻れます。以降はノードだけを切り替えるのであれば、システムプロキシ、DNS、TUNの設定を改めて変更する必要はほとんどありません。

  • 現在の設定が有効で、コアが正常に動作し、待ち受けポートがクライアントの表示と一致している。
  • 対象のポリシーグループが最終的に利用可能なノードを選択し、繰り返しテストしてもタイムアウトが続かない。
  • ブラウザーまたは対象アプリの通信がコアに取り込まれている。
  • 出口の照会結果と接続記録が一致し、対象リクエストが想定したノードを経由している。
  • テスト用に切り替えたグローバルモードが元に戻され、ほかのVPNやプロキシの入口と競合していない。

プロキシが機能しているかを判断するときは、「どのアプリが、どの宛先へ送った、どのリクエストか」を具体的に確認します。この範囲を明確にすれば、ノードへの疎通、ルールの正しさ、通信の取り込みという3つの異なる問題を切り分けられます。