Clashの使い方ガイド

ステップ1：サブスクリプションを追加して設定を有効化

サブスクリプションの項目を開き、URLの種類を確認

クライアントを開き、サイドバーから「サブスクリプション」または「設定」の画面に移動します。Clash Verge Revでは通常、サブスクリプション画面にURL入力欄と追加操作があります。サービス提供元がClashまたはmihomo向けとして案内しているサブスクリプションURLをコピーし、入力欄にすべて貼り付けます。前後に空白や改行、チャットアプリが付け加えた文字列がないことを確認してから追加してください。複数の形式が案内されている場合は、アカウント管理ページのURLではなく、使用中のコアに対応していると明記されたものを選びます。

追加後、クライアントがリモートの内容をダウンロードするまで待ちます。成功すると通常、設定名と更新操作を含む設定カードが表示されます。失敗した場合は、リクエストエラー、解析エラー、形式の不一致などが表示されます。メッセージの内容を確認してから次の操作を決めてください。リクエストエラーの場合はURLの有効期限と、現在のネットワークからサブスクリプションサービスにアクセスできるかを確認します。解析エラーの場合は、取得した内容がログインページやエラーページ、別のクライアント用の設定形式ではないか確認してください。似た名前の設定が複数作成されないよう、追加操作を何度も繰り返さないでください。

設定を有効化してプロキシ画面を確認

設定カードが表示されたら、選択または有効化する必要があります。バージョンによって、カードをクリックする、「使用する」を選ぶ、操作メニューを開くなど手順が異なります。ダウンロード成功の表示だけで判断せず、カードが選択状態になっていることを確認してください。次に「プロキシ」画面を開き、プロキシグループと選択可能なノードが表示されているか確認します。設定があるのにプロキシ画面が空の場合は、サブスクリプション画面に戻って選択中の設定を確認し、ログで読み込みや解析に関する情報を調べてください。

ローカルのYAMLファイルを受け取った場合は、クライアントのファイル読み込み機能を使います。ディスク上のパスをリモートサブスクリプションの入力欄に貼り付けないでください。ファイルを読み込んだ後も設定の有効化が必要です。ノード情報だけを含むサブスクリプションと、ルール、DNS、プロキシグループを含む完全な設定は別物です。クライアントによっては独自のテンプレートでプロキシグループを生成できますが、完全な設定が必要なものもあります。追加後に想定したルールがない場合は、まずサービス提供元が提供する内容の範囲を確認してください。すぐにファイル全体を手作業で補完する必要はありません。

この手順の完了条件は、サブスクリプションまたは設定が有効になり、プロキシ画面に想定したプロキシグループが表示され、ログに設定読み込みエラーが繰り返し出ていないことです。この時点ではDNSやポートの初期設定を維持し、次の手順で動作モードを選択します。サブスクリプション形式と設定ファイルの関係は用語集、設定の互換性とマージの仕組みはプロトコルガイドで確認できます。初回接続の前にすべてを把握する必要はありません。

ステップ2：プロキシモードと出口を選択

初回はルールモードを選択

プロキシ画面または実行設定で「ルール / グローバル / DIRECT」のモード選択を探します。初めて使う場合は「ルール」を選ぶのがおすすめです。このモードでは設定内のルールに従い、接続先ごとにDIRECT、プロキシグループ、拒否のいずれかが決まります。必要な設定が揃っている場合に適したモードです。選択後、画面でルールが現在のモードとして表示されていることを確認してください。トレイメニューに切り替え項目がある場合は、メインウィンドウとトレイの状態が一致しているかも確認します。

グローバルモードでは、コアに渡された接続がグローバル用のポリシーで処理されます。実際の出口を使うには、対応するプロキシグループでも選択が必要です。DIRECTモードでは、コアに渡された接続が接続先へ直接アクセスします。ここで選ぶモードは、コアが受け取った通信の処理方法を決めるもので、すべてのアプリからコアに通信を渡す設定ではありません。したがって、グローバルに切り替えても端末上のすべてのプログラムがプロキシを使うわけではなく、次の手順で行うシステムプロキシやシステムVPNの設定の代わりにもなりません。

プロキシグループで実際の出口を選択

ルールモードのまま、プロキシ通信を担当するプロキシグループを開きます。グループ名は設定の作成者が決めるため、「プロキシ選択」の場合も、用途別の名前の場合もあります。名前だけで機能を判断しないでください。手動選択のグループではノードを選びます。自動選択のグループでは通常、設定されたテスト条件に基づいて出口が決まります。グループから別のグループが参照されている場合は、さらに下の階層を確認し、最終的に実際のノードが選ばれていることを確かめてください。意図せず DIRECT または REJECT になっていないか確認します。

クライアントの接続テストや遅延テストを使えば、明らかに失敗する選択肢を事前に除外できます。ただし、テストは通常、指定されたアドレスだけを対象とし、結果はテスト先、リクエスト方法、その時点のネットワーク状況に左右されます。テスト結果の遅延が低いノードでも、すべての接続先に適しているとは限りません。タイムアウトも実際のアクセス状況と合わせて判断してください。初回の確認ではテストを通過したノードを1つ選び、アクセス中に何度も切り替えないようにします。後からログを照合しやすくなります。

この手順の完了時には、ルールモードを使用していること、プロキシ通信を担当するプロキシグループ、最終的に選択した出口を把握できている状態にします。負荷分散、テスト間隔、複雑なルールを同時に変更する必要はありません。特定のルールがDIRECTになる理由が分からない場合は、接続後に適用結果を確認し、よくある質問で該当する説明を探してください。設定の構成を維持しておくと、接続の問題とルール調整の問題を切り分けやすくなります。

ステップ3：システムからコアへの接続を設定

デスクトップでは先にシステムプロキシを有効化

クライアントの設定画面に戻り、現在の設定が読み込まれ、コアがエラー状態になっていないことを確認してから「システムプロキシ」を有効にします。通常、これによりOSのプロキシ先がローカルの待ち受けポートに設定され、システムプロキシに対応したブラウザーやアプリがクライアントにリクエストを渡すようになります。設定画面にあるポート番号の例を、そのまま他のプログラムに入力しないでください。手動設定が必要な場合は、クライアントに現在表示されているアドレスとポートを確認し、対応する待ち受けが有効であることを確かめます。

スイッチを有効にしたら、ブラウザーを開いて次の手順の確認を行います。TUNを同時に有効にしたり、システム設定で別の手動プロキシを追加したりしないでください。システムプロキシのスイッチがすぐにオフに戻る場合や、システム設定のアドレスが繰り返し書き換わる場合は、別のクライアントがプロキシを管理していないか確認します。競合するツールを停止してから再度有効化し、状態が安定するか確認してください。ブラウザーにプロキシ拡張機能が入っている場合は、システム設定を上書きしていないかも確認します。

モバイルではシステムの案内に従って接続を許可

AndroidやiOSのクライアントには通常、接続または起動ボタンがあります。サブスクリプションとプロキシの選択を確認してから接続をタップし、OSに表示されるVPN構成または接続の許可を確認してください。許可後にクライアントへ戻り、接続状態を確認します。ステータスバーやシステム設定にVPNの状態が表示される場合もあります。これはアプリがOSのネットワーク機能を通じて通信を取り込んでいることを示しますが、アイコンだけでは対象のリクエストが想定したノードを使ったかどうかは判断できません。

他のVPN接続があるとOSに表示された場合は、元の接続を切断する必要があるか確認してから続行してください。一部のAndroidクライアントにはアプリごとの通信振り分け機能があり、対象外に設定したアプリは現在のプロキシを経由しないことがあります。初回の確認では、除外されていないブラウザーを使います。許可画面をキャンセルした場合、クライアントのボタンが一時的に変化してもシステムへの接続が完了したとは限りません。接続操作をやり直し、許可の結果を確認してください。

より多くのアプリの通信を取り込む場合はTUNを検討

TUNは仮想ネットワークインターフェースを通じて通信を取り込み、システムプロキシに従わない一部のアプリにも対応できます。一方で、サービスのインストール、管理者権限、ルーティング、DNS設定が必要になることがあります。ブラウザーで基本的な動作確認を済ませ、特定のアプリがシステムプロキシを迂回する場合に、クライアントの説明に従ってTUNを有効にしてください。権限の確認が表示されたら操作元を確認し、有効化後はスイッチの色だけで判断せず、仮想インターフェースやルートの初期化エラーが報告されていないか確認します。

初回のトラブル対処では、通信の取り込み方法を一度に1つだけ変更し、変更前後の状態を記録します。システムプロキシとTUNを同時に有効にする必要があるかどうかは、クライアントの実装や用途によって異なります。両方のスイッチを入れれば解決するとは限りません。ネットワークスタックやDNSの取り込み方の違いについては、プロトコルガイドを参照してください。この手順では、追跡可能な通信経路を1つ確立し、実際のリクエストで確認すれば十分です。

ステップ4：アクセス、ルール、出口を確認

新しいリクエストを実行して接続ログを確認

クライアントを起動したまま、ブラウザーで新しいタブを開き、見慣れた安定したサイトにアクセスします。ページが読み込めても分かるのはアクセスできたことだけです。どの経路を通ったかも確認してください。クライアントの「接続」画面に戻り、先ほどアクセスしたドメインまたはアドレスを探して、適用されたルール、使用したプロキシグループ、出口の経路を確認します。クライアントによって表示項目は異なりますが、確認する順序は同じです。リクエストを受信したか、ルールがどこへ渡したか、最終的にどの出口を使ったかを確認します。

ブラウザーのキャッシュ、バックグラウンドリクエスト、再利用された長時間接続が確認の妨げになることがあります。ページを開いたのにログが見つからない場合は、再読み込みする、同じサイトの別のページにアクセスする、プライベートブラウジングのウィンドウを開いて新しい接続を試すなどしてください。現在アクティブな接続だけを表示するクライアントでは、短いリクエストが終了すると消えることがあります。必要に応じてログも確認してください。トラブル対処のスクリーンショットを共有するときは、サブスクリプションURL、認証情報、公開する必要のないアクセス先を隠します。

出口アドレスを確認する場合は、同じネットワーク条件でDIRECTの経路と想定するプロキシ経路を比較し、クライアントのログも確認します。ルールモードでは、IPアドレス確認サイト自体がDIRECTになることがあるため、出口アドレスが変わらないことだけではプロキシの失敗を証明できません。まず確認リクエストに適用されたルールを見てから、結果を判断してください。特定の確認サイトで違うアドレスを表示させるためだけに、グローバルモードへ恒常的に切り替えないでください。

ログの有無から問題の範囲を絞り込む

ページを開けず、クライアントにも該当するリクエストがない場合は、まずステップ3の通信経路を確認します。システムプロキシが有効か、ブラウザーがシステム設定を使用しているか、モバイルのVPN接続が維持されているか、アプリが通信振り分けの対象外になっていないかを確認してください。この場合、ノードを何度も切り替えても解決しないことがあります。通信がコアに届いていない可能性があるためです。通常のアクセスは成功するのに特定のアプリだけログがない場合は、そのアプリ独自のプロキシ設定や接続方法を優先して確認します。

リクエストログがあるのに接続先へつながらない場合は、現在のプロキシグループと最終ノードを確認します。まず出口を1つ切り替えて同じ接続先を試してください。1つの出口だけ失敗する場合は、その出口のサービス状況を重点的に確認します。複数の出口で失敗する場合はログのエラーを読み、名前解決、接続タイムアウト、認証失敗、証明書に関する警告を切り分けてください。証明書の検証を無効にする、DNSを変更する、ルールを書き換えるといった操作を一度に行わないでください。接続できるようになっても、原因を特定しにくくなります。

一部のサイトだけに問題がある場合は、DIRECT、拒否、専用プロキシグループのどれに振り分けられたかを確認し、アプリ独自のDNS、ブラウザーのセキュアDNS、古い接続のキャッシュの影響も調べます。使い始めの段階で一度失敗しただけでDNS設定全体を書き換える必要はありません。具体的な確認手順はトラブル対処に関するよくある質問を、Fake-IPやルールプロバイダーなどの用語は用語集を参照してください。

接続状態を保存してテストを終了

正常に使えることを確認したら、現在の設定名、モード、プロキシグループの選択を記録し、以降の変更前にこの状態を残しておきます。リモートサブスクリプションの更新によって内容が上書きされる場合があります。永続化したい変更は、更新で置き換えられるファイルを直接編集せず、クライアントが対応するオーバーライドやマージ機能を使ってください。まず初回の接続を完了してから、これらの機能を確認しましょう。操作の詳細はプロトコルとコアのリファレンスを参照してください。

使用を終了する場合は、デスクトップでは先にシステムプロキシを無効にしてからクライアントを終了します。TUNを有効にしている場合は、クライアントの手順に従って停止してください。モバイルでは切断ボタンを使い、システムVPNが終了したことを確認します。終了後に通常のネットワークアクセスに問題がある場合は、設定をすべて削除するのではなく、OSにローカルアドレスを使う手動プロキシ設定が残っていないか確認してください。操作手順を再現できる形で記録しておけば、次回は設定、モード、通信の取り込み、動作確認の順にチェックできます。