Clashのインストールと接続設定

サブスクリプションを読み込んで設定を有効化

Clash Verge Revを開き、左側の「サブスクリプション」を選びます。サブスクリプションリンクの入力欄にリンク全体を貼り付け、読み込みボタンをクリックしてください。サービス提供元がClashまたはmihomo対応と明記しているリンクを使い、アカウントページや購入ページ、通常のWebページのURLは使わないでください。コピー後、前後に空白や改行、チャットアプリが付けた句読点が混じっていないか確認します。リンクのパラメーターは削除しないでください。

読み込み後、クライアントがリクエストと解析を完了するまで待ちます。正常に完了すると、サブスクリプション一覧に設定項目が表示されます。名前はサブスクリプションの内容に由来する場合と、クライアントが付ける場合があります。その項目を選択して、現在使用する設定として有効にしてください。複数ある場合は、読み込んだばかりの項目に選択表示やハイライトが付いていることを確認します。一覧にカードが表示されただけでは、有効化されたとは限りません。

次に「プロキシ」画面を開き、ポリシーグループと選択可能な出口が表示されているか確認します。グループ名はサブスクリプションによって異なるため、ガイドの例と一致する必要はありません。画面が空の場合は、サブスクリプション画面に戻って現在の設定を確認し、エラー表示やログを調べてください。設定が正常に読み込まれる前にシステムプロキシを何度も有効にすると、ブラウザーが正常に動作していないローカルポートを参照するおそれがあります。

ローカルの .yaml または .yml ファイルを使う場合は、サブスクリプション画面のファイル読み込み機能からファイルを選び、有効化してください。URL入力欄にファイルの内容を貼り付けないでください。ファイル設定はリモートサブスクリプションのように自動更新されないことが一般的です。更新方法は設定の入手元によって異なるため、復元できるよう元のファイルを保管しておきましょう。

読み込みエラーが発生したら、まずエラーの種類を確認します。リクエストのタイムアウトなら、現在のネットワークからサブスクリプションサービスに接続できるか確認してください。解析エラーの場合は、返された内容がYAMLであり、ログインページや期限切れの通知など別の形式ではないことを確認します。ブラウザーでリンクを開けても、コアが読み取れる内容とは限りません。認証情報を含むリンクを、見知らぬオンライン変換ツールに渡さないでください。詳しい確認手順はサブスクリプションの読み込み・解析に失敗したときの確認リストをご覧ください。

ここまでで設定が有効になり、プロキシ画面にポリシーグループが表示されているはずです。まだ接続は開始せず、次のステップで通信を処理するルールと、プロキシが必要なリクエストの出口を決めます。

ルールモードとプロキシ出口を選ぶ

メイン画面または設定画面で「出站モード」を探し、まず「ルール」を選びます。ルールモードでは、現在の設定に基づいて宛先ドメインやアドレスなどの条件を照合し、リクエストを指定のポリシーグループまたは直結先に振り分けます。日常利用の出発点として適していますが、どのサイトがプロキシ経由になるかはサブスクリプション内のルールによって決まり、モードの切り替えだけで決まるわけではありません。

「グローバル」モードでは通常、コアに届いたリクエストがGLOBALポリシーグループに送られ、短時間の比較テストに使えます。「直結」モードでは、これらのリクエストはプロキシノードを経由しません。ただし「グローバル」でも、PC上のすべてのアプリが自動的に対象になるわけではありません。システムプロキシを使わず、TUNにも取り込まれないアプリの通信は、コアに届かない場合があります。初回設定では通信の取り込み方法と出站モードを同時に変更しないでください。問題が起きたときに原因を特定しにくくなります。

次に「プロキシ」画面を開き、メインの出口を選ぶポリシーグループを探します。「プロキシ選択」という名前の場合も、サブスクリプション独自の名前が付いている場合もあります。グループを展開し、サービス提供元が案内している有効なノードを選択してください。一覧に DIRECT がある場合、これは直結を意味し、リモートのプロキシノードではありません。プロキシ経由のアクセスをテストする場合は、メインの選択グループを誤ってこの項目に設定しないよう注意してください。

設定によっては、メインのポリシーグループがノードではなく自動選択グループを参照します。この構成のままでも問題ありません。次の階層を開き、利用可能なプロキシが含まれていることを確認してください。クライアントのテストボタンは、テスト先に接続できるかを確認するのに役立ちますが、結果が示すのはそのテスト先と実行時のネットワーク状況だけです。一度成功したからといって、すべてのサイトにアクセスできるとは限りません。数値を追いかけて出口を頻繁に切り替える必要もありません。

選択したノードが利用不可と表示される場合は、まずサブスクリプションの期限切れや停止がないか確認し、同じサブスクリプション内の別の出口を試します。すべてのノードで失敗するなら、ルールを書き換える前にローカルネットワークとサブスクリプションサービスの状態を確認してください。ポリシーグループ、ノード、ルールの違いは用語ガイドで確認できます。カスタムルールを追加する場合は、YAMLリファレンスのルール構文をご覧ください。

「ルール」モードと明確な出口の選択を維持したまま、接続の設定に進みます。あとでグローバルモードと比較する場合は、現在の選択を覚えておき、テスト後に戻してください。一時的なトラブル調査用の設定を普段使いの設定にしないよう注意しましょう。

システムプロキシを有効にして接続

クライアントの「設定」を開き、コアが正常に起動していることを確認します。起動失敗、設定の読み込み失敗、待ち受け失敗などの表示が繰り返されていないか確認してください。「システムプロキシ」を見つけて有効にします。このスイッチをオンにすると、Windowsのプロキシ設定がクライアントのローカル待ち受けアドレスに向けられ、システムプロキシに対応したブラウザーやアプリで利用できるようになります。初回テストでは通信経路を単純にするため、TUNはオフのままにしてください。

システムプロキシを有効にしたらブラウザーに戻り、プロキシ経由でアクセスする必要のあるページを開き直します。確立済みの長時間接続は以前の経路を使い続ける場合があり、スイッチを切り替えただけではすぐに反映されないことがあります。元のタブを閉じ、新しいタブで再試行してください。ブラウザーにプロキシを個別管理する拡張機能がある場合は、システム設定を上書きしていないか確認します。クライアントと拡張機能がそれぞれ別の出口を指定すると、想定と異なる結果になることがあります。

Windows側の設定を確認するには、「設定 → ネットワークとインターネット → プロキシ」を開き、手動プロキシのアドレスとポートがクライアントと一致するか確認します。混合プロキシのポートはクライアントに表示されている値を使い、ほかのガイドのポートをそのままコピーしないでください。Windowsの設定とクライアントの設定を交互に変更することも避けましょう。終了時の復元状態を確認しやすくするため、基本的にはクライアントのスイッチで管理してください。

有効にした直後にローカル接続の拒否エラーが出たら、まずクライアントでコアの状態とログを確認します。別のプロキシプログラムが同じポートを使用していると、コアが待ち受けできない場合があります。ほかのクライアントを終了して再試行してください。複数のポート項目をむやみに変更しないでください。ポートを変更する必要がある場合は、クライアントの設定を変更してシステムプロキシを有効にし直し、Windowsが新しい待ち受けポートを参照していることを確認します。

TUNを有効にするタイミング

ブラウザーでは正常にアクセスできるのに、特定のアプリだけクライアントを経由しない場合は、まずそのアプリに独自のプロキシ設定があるか確認してください。Windowsのシステムプロキシを参照しないアプリでは、TUNの利用を検討します。TUNは仮想ネットワークアダプターを通じて通信を取り込むため、ルーティング、DNS、権限が関係します。システムプロキシの強化版と考えるのは適切ではありません。初めてWebページを開くために、複数の通信取り込み機能を同時に有効にしないでください。

TUNを使う場合は、クライアントの案内に従ってサービスモードをインストールまたは有効化し、必要な権限を許可してからTUNをオンにします。バージョンによって設定場所が異なる場合があるため、現在の画面に表示されるサービス状態やエラーメッセージを確認してください。ほかのVPNや仮想ネットワークアダプターと同時に使用すると、ルートが競合することがあります。問題が起きたらTUNをオフにし、先ほど動作したシステムプロキシの経路に戻してから、原因を一つずつ調べます。DNSの詳しい設定はDNS設定リファレンスを参照してください。初回接続時にあわせて変更する必要はありません。

スイッチをオンにしただけでは通信の取り込み設定が完了したにすぎません。実際のリクエストと接続ログを照合して確認する必要があります。現在のウィンドウを開いたまま、最後のステップに進みましょう。

ルールの適用と接続状態を確認

まず、設定上プロキシ経由になるはずのWebページをブラウザーで開き、クライアントの「接続」画面に戻ります。ページを再読み込みし、対象のドメインやアドレスに対応する新しい接続が表示されるか確認してください。ログの適用ルール、ポリシーグループ、実際のプロキシ経路を確認します。リクエストが想定したポリシーグループに入り、最後に先ほど選んだ出口へ送られている必要があります。「システムプロキシ有効」の表示だけで確認を終えないでください。

接続一覧に該当するリクエストがまったく表示されない場合は、まずフィルターが設定されていないか確認し、次にブラウザーのプロキシ拡張機能、アプリ独自の設定、Windowsのシステムプロキシを調べます。ページが既存の接続を再利用している場合があるため、タブを閉じてから再度アクセスしてください。ブラウザーでページを開けてもクライアントに記録がない場合、もともと直結できただけの可能性があります。それだけではプロキシが有効になったとは判断できません。

接続ログが表示されても実際の出口が DIRECT なら、そのリクエストは直結で処理されています。まず適用されたルールを確認し、対象が本来直結すべきものかを調べてください。直結だからといって設定の失敗とは限りません。ルールモードでは一部の通信が直結します。短時間の比較テストが必要なら、グローバルモードに切り替え、GLOBALの出口がプロキシになっていることを確認して同じ宛先を再試行します。テスト後はルールモードに戻してください。

信頼できる出口IP確認サイトを使い、有効化前後の出口情報を比較します。確認サイト自体もルールの対象であり、直結になっている場合はローカルネットワークの出口が表示されても正常です。出口IP、Webサイトへのアクセス可否、接続ログをあわせて判断してください。どれか一つだけでは、PC全体の通信経路を判断できません。独自のネットワークスタックを使うアプリは、そのアプリから実際にリクエストを送って確認する必要があります。

最後に、直結する想定の一般的なサイトにもアクセスし、普段のネットワークが正常か確認します。プロキシが必要な宛先と直結先の両方にアクセスでき、接続ログも設定どおりであれば、基本設定は完了です。サブスクリプションを更新して、更新後の設定も読み込めるか試しておくとよいでしょう。その後で自動起動を検討します。システムプロキシの自動有効化はクライアントの項目ごとに確認してください。自動起動を有効にすれば通信も自動的に取り込まれるとは限りません。

テスト後に終了して設定を戻す方法

プロキシを使わないときは、まずシステムプロキシをオフにします。TUNを有効にしていた場合はTUNもオフにしてから、通知領域のメニューでクライアントを終了してください。ウィンドウを閉じても、通知領域に最小化されただけで終了していないことがあります。この順序で操作すれば、プロキシ設定と仮想ネットワークアダプターの状態が戻ったことを確認しやすくなり、プロセスの強制終了に頼らずに済みます。

プログラムが異常終了してブラウザーがネットに接続できなくなった場合は、Windowsのプロキシ設定を開き、停止したローカル待ち受けポートが参照されたままになっていないか確認します。個人PCでは、今回クライアントが設定した手動プロキシをオフにできます。もともと組織や別のソフトが設定したプロキシがある場合は、記録しておいた以前の値に戻し、すべて一律に消去しないでください。それでも解決しない場合はクライアントを再起動してログを確認し、エラーが発生した時刻と表示内容を記録したうえで、サブスクリプション、出口、通信の取り込み、ルールの順に調べます。