Clash 初回接続の全手順:ノード選択・レイテンシ測定・接続確認まで

サブスクリプションのインポート後、プロキシページの表示内容を理解する

サブスクリプションリンクのインポートに成功したのは第一歩に過ぎません。設定ファイルの中で「どう繋ぐか」を実際に決めているのは proxy-groups の部分です。クライアントのプロキシページを開くと、通常「自動選択」「手動切り替え」「海外メディア」「フォールバック」といった複数のグループ名が表示され、各グループの下に具体的なノードが並んでいます。これらのグループは適当に名付けられた表示上の区分ではなく、設定ファイル内の type フィールドによって動作が決まる機能単位です。

• select:手動切り替えグループ。クリックしたノードをそのまま使用するため、繋ぎたい経路が明確な場合に向いています。
• url-test:自動測定グループ。設定された test-url と interval に基づき、クライアントが定期的にグループ内ノードのレイテンシを測定し、最速のノードへ自動的に切り替えます。手間をかけたくない日常利用に向いています。
• fallback:フェイルオーバーグループ。ノードの順序に従って可用性を確認し、メインノードが応答しなくなった場合にのみ次のノードへ切り替えます。絶対的な最低レイテンシよりも安定性を重視します。
• load-balance:負荷分散グループ。接続を複数のノードに分散させる方式で、複数経路を並行利用する場面でよく見られます。

初回接続時は、まず自分が使っているグループの種類を確認することをお勧めします。url-test の自動選択グループであれば手動でノードを選ぶ必要はなく、クライアントが自動的に測定・切り替えを行います。select の手動グループであれば、レイテンシ測定を行い、数値が低く経路が安定しているノードを選んで有効化する必要があります。

一括レイテンシ測定:どう測るのか、数値は何を意味するのか

プロキシページでは各ノードの横に通常レイテンシの数値または「測定」ボタンが表示されており、グループ名の横にある一括測定アイコンをクリックすると、グループ内すべてのノードのレイテンシ検査を一度に実行できます。このレイテンシは「クライアントから最終的なアクセス先サイトまで」の全経路の所要時間ではなく、クライアントの端末からそのノードのプロキシサーバーへ、さらにそのノード経由で測定用URL(設定ファイル内の test-url、多くは接続性の良い海外アドレス)へアクセスするまでの往復時間(ミリ秒)を示しています。

数値を読む際の大まかな目安は以下の通りです(ネットワーク環境によって差が出るため、あくまで参考基準です)。

• 200ms以内:応答が速く、動画視聴や音声通話などレイテンシに敏感な用途に適しています。
• 200〜500ms:実用可能な範囲で、ウェブ閲覧やファイルダウンロードで目立った引っかかりは基本的にありません。
• 500ms以上、またはタイムアウト表示:経路の混雑やノード障害の可能性が高く、同グループ内で数値の低い別のノードへ切り替えることをお勧めします。

注意すべき点として、レイテンシ測定が示すのは「接続の質」であり、必ずしもダウンロード速度と一致しません。数値上は良好でも帯域が限られているノードでは大きなファイル転送時の速度が伸びないことがあり、逆にレイテンシがやや高めでも帯域が十分なノードでは大容量転送がより安定することもあります。日常的なブラウジングではレイテンシを優先的に見て、大容量ダウンロード用途ではノードに表示された帯域クラスや線路タイプ(専用中継回線は一般的なノードより安定しやすい)も併せて確認しましょう。

一括測定はノード側サーバーの応答リソースを一定量消費するため、短時間に連続で何度も実行するのは避けたほうがよいでしょう。接続が不調な時やネットワーク環境を切り替えた時(自宅Wi-Fiからモバイルホットスポットへの切り替えなど)に一度実行すれば十分で、多くのクライアントは自動測定の周期設定にも対応しているため毎回手動で実行する必要はありません。

システムプロキシを有効化し、正しい動作モードを選ぶ

ノードを選んだら、次はシステム上のアプリケーションが実際にトラフィックを Clash に渡すよう設定します。クライアントのホーム画面や設定画面には通常「システムプロキシ」というスイッチがあり、これをオンにすると端末の HTTP/HTTPS プロキシ設定がクライアント自身が待ち受けるローカルポート(よく使われるのは 7890 など)を指すようになり、大半のブラウザやシステムプロキシ設定に対応したソフトウェアは自動的にこの経路を通ります。

システムプロキシのほかに、クライアントはより低レイヤーの動作モードを2つ提供しており、その違いを理解しておくと後のトラブル対応に役立ちます。

1. ルールモード(Rule):設定ファイル内の rules セクションを順番に照合し、マッチしたトラフィックは対応するグループへ、マッチしなかったものはデフォルト方針で処理されます。日常的に最も使われ、手間の少ないモードです。
2. グローバルモード(Global):ルールを参照せず、すべてのトラフィックを現在選択中の単一ノードにまとめて流します。一時的にすべての通信を特定の経路に通したい場合や、「あるルールの記述が間違っているのでは」と疑って比較検証する際にもよく切り替えられます。
3. ダイレクトモード(Direct):すべてのトラフィックがプロキシを経由せず、端末のネットワークを直接利用します。一時的にプロキシの効果をオフにして、問題がプロキシ自体にあるのかを確認する際に使われます。

デバイスやシステム側のプロキシ設定をソフトごとに個別設定するのが手間な場合は、TUNモードも検討できます。クライアントがシステム内に仮想ネットワークアダプタを作成し、デバイスのネットワーク層のトラフィックを丸ごと引き受けるため、個々のプログラムがシステムプロキシ設定を認識しているかどうかに依存しません。コマンドラインツールやブラウザ以外のクライアント系アプリには特に有効です。TUNモードを初めて有効化する際は通常より高いシステム権限(管理者権限や該当プラットフォームのネットワーク拡張機能の許可など)が必要で、クライアントの案内に従って許可を進めれば問題ありません。許可に失敗する場合は権限が一部しか付与されていないケースが多く、手順をやり直すことで大抵解決します。

ブラウザでプロキシが本当に有効か確認する

システムプロキシまたはTUNモードを有効にした後は、「オンにしたから効いているはず」と思い込まず、確認の習慣をつけることが大切です。最も直感的な方法は、現在の接続元情報を表示するページをブラウザで開き、プロキシのオン・オフ前後でネットワークの位置情報が変わるかを比較することです。地理的位置や経路情報がプロキシの切り替えに応じて変化していれば、トラフィックが確実に Clash 経由のノードを通過していることになります。

さらに一歩踏み込んだ確認方法として、クライアント内蔵のログページや接続ページを開く方法があります。

• 接続ページには現在 Clash を経由しているすべてのネットワーク接続がリアルタイムで表示され、アクセス先のドメイン、使用しているノード、適用されたルールが確認できます。ページを開いた後にこのページで対応するレコードが確認できれば、トラフィックが確実に引き渡されている証拠になります。
• ログページはレベル(Info、Warning、Error など)でフィルタできます。ブラウジング中にルールマッチのログが頻繁に出ていれば、プロキシ経路が正常に機能していることを間接的に確認できます。

ページを開いても接続ページが空のまま、ログにも新しい記録がない場合は、システムプロキシが実際には有効になっていない可能性が高いです。よくある原因はブラウザが独自のプロキシ設定を使っていて(システムプロキシに追従していない)、あるいはシステムプロキシのスイッチ自体が正しくオンになっていないことです。まずはシステムのネットワーク設定でプロキシのアドレスとポートがクライアントの待ち受け設定と一致しているか手動で確認してみましょう。

コマンドラインでより厳密に確認する

GUIでの確認方法は日常利用には十分ですが、より厳密にプロキシ経路を確認したい場合は、コマンドラインツールの方が明確な証拠を得られます。ターミナル環境を例にすると、プロキシを直接指定してリクエストを送り、返ってくる応答情報を確認できます。

curl -x http://127.0.0.1:7890 https://example.com -I

上記のコマンドは、端末の7890ポートで待ち受けているプロキシを強制的に経由してリクエストを送信します。接続タイムアウトや拒否ではなく正常なレスポンスヘッダーが返ってくれば、ローカルのプロキシポートが通っており、外部リクエストを正常に転送できていることが分かります。想定している経路のノードを実際に通っているかをさらに確認したい場合は、プロキシを指定しない場合の同じコマンドの応答速度・結果と比較してみてください。明確な差があれば、プロキシ経路が形だけでなく実際に機能していると確認できます。

また、Clash Meta(mihomo)コアをベースとするほとんどのクライアントはローカルAPIとコントロールパネルを提供しており、デフォルトで独立したポート(よく使われるのは 9090)で待ち受けています。コマンドラインから現在グループが選択しているノードを直接確認することもできます。

curl http://127.0.0.1:9090/proxies/自動選択

返ってくる JSON には now フィールドが含まれており、そのグループで現在実際に有効になっているノード名が示されます。これは画面表示を目視するよりも「設定レベルで実際に使われているノード」という事実に近い情報であり、特に自動測定グループでノードが頻繁に切り替わる場合、API で確認する方が画面を見続けるより信頼できます。

接続は正常なのにアクセスが依然として遅い場合

確認手順を経てプロキシが有効になっていることは分かったものの、一部のページの読み込みが依然として遅い場合は、すぐにノード自体を疑うのではなく、以下の順序で切り分けることをお勧めします。

1. まず現在のグループが自動測定グループかどうかを確認します。最近ネットワーク環境が変わった(Wi-Fiを切り替えたなど)場合、ノードがまだ最適な結果を再測定していない可能性があるため、一括測定を手動で実行してみます。
2. グローバルモードに切り替え、ルールマッチを経由しない状態で単一のノードの挙動を単独でテストし、あるルールがトラフィックを効果の悪いグループへ誘導していないかを排除します。
3. ログページに大量のルール未マッチや解析失敗の記録がないか確認します。設定ファイル内でルールの順序が逆になっていたり、正規表現の記述が誤っていたりすると、想定と異なるトラフィックの流れになることがあります。
4. 中国本土から海外リソースへアクセスする用途の場合は、アクセス先のサイト自体の負荷状況にも注意してください。遅さのすべてがプロキシ経路の問題とは限りません。

この手順を一通り行えば、問題がノード、ルール、アクセス先サイトのいずれにあるのかを大体特定できます。遅いと感じるたびにサブスクリプションを再インポートしたりノードを一から交換したりする必要はありません。