Clashのサブスクリプション、接続、動作確認

サブスクリプションURLからインポート

クライアントを開いたら、まず「サブスクリプション」「設定」「Profiles」ページを探します。デスクトップクライアントでは通常、ページ上部に入力欄とインポートボタンがあります。モバイル版では右上のプラスメニューに入口がある場合もあります。完全なサブスクリプションURLを入力欄に貼り付け、必要であれば「日常用設定」など識別しやすい名前を付けて、「インポート」「追加」「ダウンロード」をクリックします。クライアントがリモートの内容を取得し、新しい設定として登録します。

インポート後、すぐにシステムプロキシを有効にしないでください。まず設定に名前、更新日時、プロキシ数などが表示されているか確認し、プロキシページで少なくとも1つのプロキシグループが表示されることを確認します。設定ページに項目が追加されたのにプロキシページが空の場合は、サブスクリプションを正常に解析できていない可能性があります。クライアントが形式エラーを表示する場合は、コピーしたURLが完全か再確認してください。サービスによっては汎用サブスクリプション、Clash用、他クライアント用の形式を併用しているため、Clashまたはmihomo対応と明記された形式を優先します。

設定一覧に複数の項目がある場合は、対象の設定をクリックし、「有効化」「現在の設定にする」などの操作を行います。ダウンロードしただけでは、クライアントがその設定を使用しているとは限りません。設定項目に現在の状態を示すマークが付いているか確認するか、ホーム画面に戻って現在の設定名が変わっているか確認します。現在の設定を確定してから次へ進めば、以降に表示されるプロキシグループとルールが、今インポートした設定のものだと判断できます。

ローカルYAMLファイルからインポート

ローカルファイルを使う場合は、設定ページで「ファイルからインポート」を選ぶか、YAMLファイルをクライアントの指定領域へドラッグします。Androidでは通常、システムのファイル選択画面が開くため、選択したファイルを読み取る権限をクライアントに許可します。macOSではダウンロードフォルダや書類フォルダへのアクセス許可を求められる場合があります。インポート後は、そのファイルを現在の設定にすることも忘れないでください。YAMLの解析に失敗した場合は、プロキシモードを何度も切り替えるのではなく、インデント階層、コロン後のスペース、リスト項目の形式を確認します。

ローカル設定は、固定ルールやパラメータを自分で管理したい場合に適しています。ただし初回は、上書きスクリプト、グローバル拡張設定、複数のルールプロバイダーを同時に有効にしないことをおすすめします。設定の重なりが多いほど、問題が起きた際に実際の適用値を判断しにくくなります。まずは元の設定で接続を確認し、その後にカスタム内容を1つずつ追加してください。プロトコルのフィールド、サブスクリプションの互換性、設定の移行に関する詳しい違いは、プロトコルマニュアルのサブスクリプション形式の章を参照してください。

初回はルールモードを優先

設定の準備ができたら、クライアントの「モード」「Mode」またはプロキシ設定エリアを開きます。一般的な選択肢には、ルールモード、グローバルモード、直接接続モードがあります。初回は、一般的にRuleと表示されるルールモードを選択します。このモードでは、各リクエストが設定内のルールの順序に従って照合されます。特定のドメインやネットワークは直接接続し、別のリクエストは指定したプロキシグループへ渡し、どのルールにも一致しないリクエストは末尾のルールで処理します。サブスクリプションのルールが正常に読み込まれているか確認でき、多くの設定の初期設計にも適しています。

グローバルモードは、ほとんどのリクエストを1つのグローバルプロキシグループへ渡します。ルールによる接続差を短時間確認する用途には便利ですが、すべての問題を解決する方法として使うべきではありません。直接接続モードはプロキシを経由せず、一時的なネットワーク復旧や比較テストに使います。ルールモードで特定のサイトに接続できず、グローバルモードでは開ける場合は、ルールのマッチ先とプロキシグループの選択を確認します。両方のモードで失敗する場合は、設定、プロキシの可用性、システム接続を確認してください。

主要なプロキシグループにプロキシを指定

「プロキシ」または「Proxies」ページを開くと、設定で定義された複数のプロキシグループが表示されます。名称は「ノード選択」「自動選択」「フェイルオーバー」「メディアサービス」など、設定によって異なります。まず通常の通信を担当する主要なプロキシグループを探し、明確なプロキシ項目を1つ選びます。グループ内にDIRECT、自動テストグループ、複数のプロキシがある場合、初回確認では状態が正常なプロキシを手動で選ぶと、自動切り替えによる変数を減らせます。

クライアントの遅延テストで分かるのは、テスト先にその時点で到達できるかどうかと、リクエスト確立にかかるおおよその時間だけです。すべてのサイトやアプリが正常に使えることを単独で証明するものではありません。遅延が低く表示された項目でも、プロトコルのパラメータ、ネットワーク経路、対象サービスの違いによって実際のリクエストに失敗する場合があります。速度テストは候補を絞るために使い、最終的には4番目の手順で確認する実際の接続履歴とページ表示を基準にしてください。

プロキシグループがurl-test、fallback、load-balanceを使っている場合、クライアントでは「自動選択」「フェイルオーバー」「負荷分散」などと表示されます。これらは選択ロジックが異なります。自動テストは通常、テスト結果のよいプロキシを優先し、フェイルオーバーは現在のプロキシが使えなくなった場合の切り替え順を重視し、負荷分散は複数のプロキシへ接続を振り分けます。初回は主要なプロキシグループに利用可能な選択肢があることだけ確認し、テスト間隔、許容差、ハッシュ方式をすぐに調整する必要はありません。詳しい違いはプロトコルマニュアルで確認できます。

まずコアが実行中であることを確認

クライアントのホーム画面または設定画面に戻り、コアの状態を確認します。mihomoを採用したクライアントでは通常、「実行中」「Service Running」または操作可能な起動ボタンが表示されます。デスクトップクライアントの中には起動時にコアを自動起動するものもあれば、手動で起動をクリックする必要があるものもあります。サービスモードを使う場合、Windowsでは管理者権限の確認が表示され、macOSでは補助サービスのインストールにシステムパスワードが必要になることがあります。許可した後、状態が安定するまで待ち、システムプロキシを有効にします。

コアを起動できない場合は、まずポートの使用状況とエラーログを確認します。別のプロキシクライアントがバックグラウンドで動作している、または古いプロセスが設定内のmixed-port、HTTPポート、SOCKSポートを使用していることがよくあります。他のクライアントを終了してから再起動するほうが、複数のポートを同時に変更するより原因を特定しやすくなります。ログに認識できない設定フィールドが示されている場合は、現在のコアが設定の機能に対応していない可能性があります。その場合はクライアントを更新するか、互換性のある設定形式を選択してください。

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

WindowsとmacOSでは、コアの実行後に「システムプロキシ」「System Proxy」「システムプロキシとして設定」などのスイッチを有効にします。この操作でプロキシアドレスがOSのネットワーク設定に書き込まれ、ブラウザやシステムプロキシに対応するアプリがClashへリクエストを送るようになります。有効化後すぐにクライアントを終了しないでください。システムプロキシは通信をローカルの待受ポートへ向けるだけで、実際の接続処理は実行中のコアが行います。

一部のブラウザは独自のプロキシ設定を使い、コマンドラインツールの中にもシステムプロキシを自動で読み取らないものがあります。初回確認では、OS標準のブラウザや一般的なデスクトップブラウザを使い、挙動に特徴のあるアプリでいきなりテストするのは避けてください。ブラウザで利用できることを確認してから、対象アプリのネットワーク設定に応じてHTTPまたはSOCKSアドレスを個別に入力するか、より広い通信を対象にできるTUNモードを使います。

モバイル端末でシステム接続を許可

AndroidとiOSのクライアントは通常、システムVPNインターフェースを通じて通信を処理します。接続ボタンをタップすると、システムにネットワーク接続の許可が表示され、許可後はステータスバーに接続アイコンが表示されます。この許可はクライアントによるローカルネットワーク経路の作成を認めるもので、適切なプロキシが選択されたことを意味しません。そのため、2番目の手順で選んだプロキシグループを維持してください。別のVPNが実行中と表示された場合は、既存の接続を切断してからClashクライアントを再起動します。

TUNモードを検討するタイミング

システムプロキシはブラウザやシステム設定に従うデスクトップアプリに適しており、設定手順が短く、初回のトラブル対策も分かりやすくなります。TUNモードは仮想ネットワークインターフェースを通じてより多くの通信を対象にするため、システムプロキシを読み取らないアプリ、一部のコマンドラインプログラム、DNSを一元的に処理したい場合に適しています。TUNの有効化には管理者権限、補助サービス、追加のネットワークコンポーネントが必要な場合があるため、まずシステムプロキシでブラウザを確認し、必要に応じて有効にすることをおすすめします。

TUNへ切り替えた後は、他のネットワークツールが同時にルーティングやDNSを変更しないようにしてください。接続に変化があった場合は、まずTUNを無効にしてシステムプロキシが正常か確認し、その後TUNスタック、DNSのリダイレクト、ルート除外項目を確認します。システムプロキシ、TUN、DNSモード、各OSの権限に関する詳しい説明は、プロトコルマニュアルのネットワークとシステムの章を参照してください。

まずブラウザから新しいリクエストを送る

クライアントを前面またはバックグラウンドで実行したまま、ブラウザで開いているテストページを閉じ、新しいタブで安定したサイトにアクセスします。古いページを更新するより、新しいページを開くほうが確実です。ブラウザのキャッシュ、既存の接続、DNSキャッシュによって、古いタブでは完全な新規リクエストが発生しない場合があるためです。ページが読み込めることは最初の確認にすぎません。クライアントに戻り、接続一覧に対象ドメインが表示されているか確認してください。

「接続」「Connections」「ログ」ページを開き、先ほどアクセスしたドメインを探します。通常は、リクエスト先、マッチしたルール、使用したプロキシグループ、最終的に選ばれたプロキシまたはDIRECTを確認できます。設定どおり対象サイトがプロキシ経由になっていれば、履歴に対応するプロキシチェーンが表示されます。本来直接接続するサイトがDIRECTと表示される場合も、ルールモードが機能している証拠です。重要なのはすべてのリクエストが同じ経路になることではなく、実際の結果がルール設計と一致していることです。

ブラウザの成功とシステム全体の成功を区別

ブラウザでアクセスできたら、実際に使いたいアプリを開いてテストし、接続一覧も同時に確認します。ブラウザの履歴はあるのに対象アプリの新しい接続がまったくない場合、そのアプリがシステムプロキシを読み取っていないか、独自のネットワークスタックを使っている可能性があります。アプリ独自のプロキシ設定を確認し、デスクトップでは権限要件を理解したうえでTUNモードを試します。接続一覧にリクエストはあるもののタイムアウトする場合、通信はすでにClashへ入っているため、問題はプロキシ項目、プロトコルパラメータ、DNS、対象ネットワーク経路にある可能性が高くなります。

コマンドラインツールは個別に判断する必要があります。システム環境変数を読むツール、独自のプロキシパラメータを使うツール、TUNモードでのみ処理できるプログラムがあります。1つのコマンドラインリクエストだけでシステムプロキシの状態を否定しないでください。まずブラウザとクライアントの接続履歴を基準にし、その後で対象ツールにプロキシアドレスを設定すると、システム接続の問題とアプリ設定の問題を切り分けられます。

モード切り替えが想定どおりか確認

ルールの影響を確認するには、同じサイトで比較テストを行います。プロキシ項目は変えずに一時的にグローバルモードへ切り替え、ページを新しく開いた後、ルールモードへ戻します。グローバルモードでは成功し、ルールモードでは失敗する場合は、どのプロキシグループにマッチしたか、そのグループで直接接続や利用できない項目を誤って選んでいないか確認します。両方のモードで失敗する場合は、現在の設定、主要なプロキシグループ、プロキシ自体を確認してください。比較後はルールモードに戻し、以降のリクエストがグローバル設定を使い続けないようにします。

復旧テストも実施できます。システムプロキシを無効にするかモバイル端末の接続を切断し、クライアントの状態とシステムの接続アイコンが連動して変化することを確認してから、再接続します。これにより、権限とスイッチが繰り返し正常に機能するか確認できます。デスクトップでシステムプロキシを無効にしてもブラウザがローカルポートを向いたままの場合は、システムのネットワーク設定でプロキシ項目が残っていないか確認します。モバイル端末で切断後もシステムアイコンが残る場合は、別のVPNアプリが接続を引き継いでいないか確認してください。