接続前に設定が正常に動作していることを確認する
サブスクリプションのインポートに成功しても、クライアントが設定ファイルを取得しただけで、プロキシ接続が確立したとは限りません。初回操作では、設定、コア、動作モード、システムへの適用方法が一致しているか確認しましょう。クライアントによってメニュー名は多少異なりますが、一般的には「設定」→「サブスクリプション」で先ほど読み込んだ設定を選び、「設定」→「パラメーター設定」でコアが起動していることを確認します。
mihomoコアを使用するクライアントでは、動作状態、コアのバージョン、コントロールポートが表示されることが一般的です。メイン画面に「未起動」と表示されたまま、またはログに新しい記録がまったくない場合は、まずコアを起動してください。ノードの遅延測定はコアの機能を利用するため、コアが動作していないと、すべてのノードが同時にタイムアウトすることがあります。
初回接続で確認する4項目
- 設定が選択されている：設定一覧で現在の設定に指定されたファイルだけがルール判定に使われます。サブスクリプションを更新した後は、クライアントが古いローカル設定を使い続けていないかも確認してください。
- 動作モードが明確になっている：初回は「ルール」モードがおすすめです。設定内のルールに従って直接接続またはプロキシ接続を決めるため、接続ページで実際の判定過程を確認しやすくなります。
- プロキシの適用が有効になっている：デスクトップのブラウザーでは通常、「システムプロキシ」を有効にします。システムプロキシを参照しないアプリまで対象にする場合は、TUNモードを使用してください。
- ポートが競合していない：一般的な設定ではHTTPまたはmixed-portに
7890、SOCKSポートに7891が使われます。最終的な値は、現在の設定とクライアントの設定画面を確認してください。
システムプロキシとTUNを同時に有効にすると、2種類の適用経路が結果に混在する可能性があります。初回の切り分けでは、まずシステムプロキシだけを有効にしてブラウザーで確認し、必要に応じてTUNをテストしてください。これにより、TUNの経路が正常な状態をシステムプロキシの正常動作と取り違えたり、ブラウザー側のプロキシ設定をノード障害と誤認したりするのを防げます。
ステップ1：ポリシーグループで適切なノードを選ぶ
Clashの設定では、ルールから特定のノードを直接参照せず、まずポリシーグループを参照する構成が一般的です。ポリシーグループが使用するノード、または次のポリシーグループを決定します。よくある名称には「ノード選択」「プロキシ」「手動選択」「自動選択」「フォールバック」などがあります。名称はサブスクリプション提供元が定めるため、すべての設定で同じとは限りません。
まずルールが最終的に参照するポリシーグループを探す
「プロキシ」ページを開くと、複数のグループが表示されます。select は手動選択、url-test はテスト結果に基づく自動選択、fallback は利用可能なノードを優先し、load-balance は複数のノードに接続を振り分けます。初回接続では、結果を管理しやすい手動選択グループから始めるのがおすすめです。
地域別グループだけでノードを選んで終わりにせず、上位グループがその地域グループを実際に参照しているか確認してください。たとえば「ノード選択」が現在「自動選択」を選び、ユーザーが「香港ノード」で特定の回線を切り替えただけなら、最終的な出口は依然として「自動選択」が決める可能性があります。ポリシーグループは入れ子にできるため、画面上の選択状態を最上位から順に確認しましょう。
| ポリシーグループの種類 | 初回接続での使い方 | 確認するポイント |
|---|---|---|
select |
ノードを1つ手動指定して、同じ条件で検証する | グループ内での選択は、上位グループがそのグループを選択したことを意味しない |
url-test |
複数のノードをテストし、遅延の低いものを自動選択する | 低遅延でも帯域幅が大きいとは限らず、目的のWebサイトにアクセスできるとも限らない |
fallback |
メインノードが使えない場合に順番に切り替える | 表示中のノードはヘルスチェックによって変わることがある |
load-balance |
複数のノードで異なる接続を分担する | 単一の出口IPだけを判断材料にしない |
初回はどのようなノードを選ぶべきか
- まずは地理的に近く、遅延結果が安定しているノードを選びましょう。リスト上の最小値だけを追い求める必要はありません。
- 3回連続でテストします。結果が68 ms、71 ms、74 msなら、42 ms、190 ms、タイムアウトのように大きく変動する結果より、通常は安定しています。
- 名称に倍率、実験用、速度制限などが明記された回線は一旦避け、再現性のある基準結果を作りましょう。
- 同じ地域に複数のプロトコルのノードがある場合は、まずサブスクリプションで推奨されている標準回線を選び、実際のスループットと安定性を比較します。
ノード名は設定提供元が付けたラベルにすぎず、物理的な所在地や回線品質を単独で証明するものではありません。最終的には遅延、接続ログ、出口アドレス、実際のアクセス結果を組み合わせて判断してください。固定セッションが必要なログインサービスでは、短時間にノードを頻繁に切り替えると出口アドレスが変わる可能性もあります。切り替えるたびに接続を再確立してから検証しましょう。
ステップ2：遅延を測定し、結果を正しく読む
クライアントの遅延テストは、従来のICMP Pingとは異なります。Clashまたはmihomoは通常、指定されたテストURLへノード経由でリクエストを送り、プロキシ接続の確立から応答取得までにかかった時間を記録します。テスト先には、HTTP 204を返す https://www.gstatic.com/generate_204 や https://cp.cloudflare.com/generate_204 などがよく使われます。具体的なURLは設定またはクライアントの設定で決まります。
遅延の数値が示す意味
| テスト結果 | 一般的な見方 | 次に行うこと |
|---|---|---|
| 40–100 ms | 距離が近い、または経路が短く、操作への応答は通常速い | 実際の出口とWebサイトへのアクセスを引き続き確認する |
| 100–250 ms | 地域をまたぐ回線ではよく見られる値 | 3回の結果が安定しているか確認する |
| 250–500 ms | 経路が長い、混雑している、またはハンドシェイクに時間がかかっている | 同じ地域の他のノードと比較する |
| タイムアウト | テストURLが制限時間内に応答しなかった | ノード、DNS、ネットワーク、テスト先を確認する |
これらの範囲は初期選別の目安にすぎません。55 msのノードでも帯域が混雑してダウンロードが遅い場合があり、180 msのノードでも継続通信は安定することがあります。遅延は主に短い接続の応答性を示すもので、ダウンロード速度、パケットロス率、混雑時間帯の容量と直接同じではありません。
複数ノードをテストするときは、連続して素早くクリックしないでください。一度に数十ノードをテストすると大量の接続が瞬時に作成され、ルーター、DNSサービス、リモートサーバーがレート制限をかける可能性があります。今回の結果がすべて返るまで待ち、10〜20秒空けて2回目を実行しましょう。1回の最小値より、3回分のデータのほうが参考になります。
すべてのノードがタイムアウトするときはテスト経路を先に確認する
- 「ログ」を開き、遅延測定をクリックした後に接続試行が記録されているか確認します。ログがまったく出ない場合は、通常、コアが動作していないか、画面がコントロールポートに接続できていません。
- この端末からテスト先のアドレスを直接解決できるか確認します。DNSに失敗すると、正常なノードまで一斉にタイムアウトすることがあります。
- テストURLを別の安定した204レスポンスのURLに変更して、もう一度テストします。1つのテストサイトにアクセスできないからといって、すべてのノードが同時に使えなくなったとは限りません。
- 端末の時刻が正確か確認します。TLSを使う接続では、システム時刻が大きくずれているとハンドシェイクに失敗することがあります。
- ログにある
timeout、connection refused、network is unreachableなどの情報を確認し、タイムアウト、ポート拒否、経路到達不能をそれぞれ切り分けます。
ステップ3：通信が確実にプロキシを経由しているか確認する
プロキシの確認は、システムプロキシのスイッチが変色したか、ノードの横に遅延値が表示されたかだけで判断できません。信頼できる方法は、出口アドレス、Clashの接続記録、ルールのマッチ結果を同時に確認することです。3つが一致して初めて、リクエストが想定したノードを経由したと判断できます。
方法1：直接接続とプロキシの出口アドレスを比較する
- システムプロキシとTUNを無効にし、パブリックIPを表示するサービスへアクセスして、直接接続時の出口アドレスを記録します。
- システムプロキシを再び有効にし、先ほどテストしたノードを固定で選びます。
- 新しいシークレットウィンドウでパブリックIPをもう一度確認し、ページキャッシュの影響を避けます。
- 2つのアドレスを比較し、Clashの「接続」ページで該当ドメインのリクエストを探します。
ロードバランシングのポリシーグループを使っている場合、接続ごとに出口が変わることがあるため、毎回まったく同じ結果になるとは限りません。手動選択した単一ノードなら、出口は通常ある程度安定します。パブリックIPが変わらなくても、すぐに失敗と判断しないでください。現在のルールが確認サービスを DIRECT にしている可能性があるため、まず接続記録の出力ポリシーを確認します。
方法2：ターミナルでプロキシポートを明示的に指定する
ターミナルのプログラムは、デスクトップのシステムプロキシを自動的に読み取るとは限りません。curl でローカルプロキシを明示指定すれば、「ターミナルがシステム設定を継承しているか」と「Clashのポートが動作しているか」を分けてテストできます。以下のコマンドでは、HTTPまたはmixed-portが 7890 であることを前提とします。
curl --proxy http://127.0.0.1:7890 https://api.ipify.orgWindows PowerShellでは、旧バージョンの環境で curl が別のコマンドとして解釈されるのを避けるため、curl.exe の使用をおすすめします。
curl.exe --proxy http://127.0.0.1:7890 https://api.ipify.org設定でSOCKS5ポート 7891 を個別に開いている場合は、ドメイン名の解決もプロキシ側で行えます。
curl --proxy socks5h://127.0.0.1:7891 https://api.ipify.orgsocks5h の h は、ホスト名の解決をSOCKSプロキシに任せることを示します。コマンドが接続拒否を返した場合は、すぐにノードを替えるのではなく、実際に待ち受けているポートを確認してください。新しい設定では mixed-port だけが有効で、独立した socks-port が存在しない場合もあります。
方法3：接続の詳細とルールチェーンを確認する
クライアントの「接続」ページを開き、目的のWebページを更新します。リクエストの詳細には通常、対象ホスト、送信元アドレス、アップロード・ダウンロード通信量、マッチしたルール、最終的なポリシーチェーンが表示されます。たとえば、次のような記録になります。
example.com
ルール：DomainSuffix
ポリシーチェーン：ノード選択 → 香港ノード → HK-01
ネットワーク：TCP
状態：ActiveDIRECT と表示される場合、そのリクエストはルールに従って直接接続されています。具体的なノード名が表示される場合は、プロキシ経由で送信されています。REJECT はルールによって明示的に拒否されたことを示します。接続一覧に目的のリクエストがない場合、通信がClashに入っていない可能性があります。ブラウザーのプロキシ、アプリ内プロキシ、TUNの経路、端末のファイアウォールを重点的に確認してください。
「遅延は測れるのにプロキシを使えていない」見かけだけの接続を見分ける
見かけだけの接続で最もよくあるのは、ノードの遅延は正常でクライアントも動作中なのに、目的のアプリが直接接続を使い続ける状態です。原因は通常、ノードそのものではなく、ポリシーグループの選択、ルールのマッチ、アプリへの適用範囲にあります。サブスクリプションを何度も更新するより、次の順に確認するほうが効果的です。
最上位のポリシーグループでテストしたノードが選ばれていない
「香港ノード」グループでHK-01を選んでも、ルールが実際に参照しているのが「ノード選択」で、その「ノード選択」が「自動選択」を指したままということがあります。この場合、HK-01の遅延測定は正常でも、実際の通信はHK-01を経由しません。最上位グループに戻り、現在の選択項目を上から順にたどって、最終ノード名が想定どおりになるまで確認してください。
目的のドメインがルールで直接接続に指定されている
ルールモードでは、ルールが上から順に適用されます。DOMAIN-SUFFIX、GEOSITE、GEOIP、フォールバックの MATCH などによって出口が変わる可能性があります。接続記録に DIRECT と表示されるなら、システムプロキシ自体は動作していて、ルールが直接接続を選んでいる可能性があります。一時的にグローバルモードへ切り替えて比較し、確認後はルールモードに戻してルールの順序を確認してください。
ブラウザーやアプリがシステムプロキシを回避している
一部のブラウザーでは、拡張機能や企業ポリシーによってプロキシを個別に設定できます。開発ツール、ゲームランチャー、コンテナ、ターミナルプログラムも直接接続を確立することがあります。システムプロキシの影響を受けるのは、通常、OSのプロキシ設定を自ら参照するプログラムだけです。このようなアプリにはローカルのHTTP/SOCKSアドレスを設定するか、システムとの互換性を確認したうえでTUNモードを有効にしてください。
TUNは有効だが、経路または権限の準備が整っていない
TUNモードは仮想ネットワークインターフェースを使って、より広い範囲の通信を取り込みます。Windows、macOS、Linuxでは、管理者権限やシステム拡張機能のインストールが必要になる場合があります。有効化した後は、TUNの状態、仮想インターフェース、ログを確認してください。スイッチがオンになっているだけでは、経路が正常に追加されたとは限りません。インターフェース作成失敗や権限不足がログに出ている場合は、まず権限を修正してからノードをテストします。
ノードを切り替えても古い接続が再確立されていない
ノードを切り替えても、既存のTCP、QUIC、長時間接続がすべて直ちに移行するわけではありません。ブラウザーのタブ、動画クライアント、メッセージングアプリが古い接続を使い続けることがあります。切り替え後は該当する接続を閉じてページを再読み込みし、必要ならアプリを終了して再起動してください。テスト用Webページは新しいシークレットウィンドウで開くと、キャッシュ、Service Worker、永続接続の影響を減らせます。
IPv4とIPv6で異なる経路を通っている
目的のドメインはAレコードとAAAAレコードを同時に返すことがあります。アプリがIPv6を選択し、現在のプロキシまたはTUNの経路がIPv4しかカバーしていない場合、一部のリクエストが直接接続、一部がプロキシ経由になることがあります。接続ページとログで、リクエストが使用したアドレスファミリーを確認できます。1つのパブリックIP確認ページだけで、すべての通信経路を判断しないでください。
再現性のある初回接続チェック手順を作る
接続に一度成功したら、切り分け手順を固定できます。サブスクリプションの更新、ネットワークの変更、クライアントの切り替え後も同じ順序で確認すれば、設定、ノード、アプリへの適用のどこに問題があるかを素早く判別できます。
- 現在のサブスクリプション設定を選び、mihomoまたは互換性のある別のコアが動作していることを確認します。
- ルールモードを維持し、まずはシステムプロキシだけを有効にして、TUNを同時に使わないようにします。
- 最上位の手動ポリシーグループで、具体的なノードを1つ選びます。
- 10〜20秒間隔で3回テストし、遅延とタイムアウトの有無を記録します。
- 目的のページにアクセスし、「接続」と「ログ」に対応するリクエストが表示されるか確認します。
- マッチしたルール、ポリシーチェーン、最終ノード名を確認します。
- 直接接続とプロキシの出口アドレスを比較し、ターミナルで
127.0.0.1:7890を明示指定して個別に検証します。 - 基本経路が正常であることを確認してから、自動選択、フォールバック、TUNを有効にします。
ノード選択、遅延測定、プロキシ確認はそれぞれ独立した工程です。ノード選択は「誰を使うか」を決め、遅延測定は「探査リクエストが通るか」を確認し、出口アドレスと接続記録は「実際の通信がどこへ向かったか」を示します。3つを分けて判断することで、緑色の遅延値だけを接続成功の根拠にする誤りを防げます。