Clashの使い方ガイド：
サブスクリプションの追加と接続確認

準備：クライアントとサブスクリプションURL

まずダウンロードページから、OSとプロセッサアーキテクチャに合ったクライアントを選び、インストールしてメイン画面を開きます。このガイドは一般的なClash系GUIクライアントを対象としており、YAMLファイルの編集は不要です。クライアント選びに迷ったら、クライアントの選び方ガイドをご覧ください。初めて設定する場合は、現在のOSに対応し、継続してメンテナンスされているクライアントがおすすめです。アーカイブ済みのクライアントは、入門用の標準的な選択肢として推奨しません。

次に、サービス提供元が発行したClashまたはmihomo対応のサブスクリプションURLを用意します。クライアントは設定を読み込んでリクエストを転送するソフトウェアであり、インストールしただけで利用可能なノードが自動生成されるわけではありません。サブスクリプションURLは、通常、サービス提供元のユーザーセンターで確認できます。対応形式が明記されたURLを使い、ユーザーセンターのページURLや注文ページ、ブラウザーの共有リンクは使わないでください。

サブスクリプションURLにはアカウントを特定できる情報が含まれる場合があります。パスワードと同じように管理してください。URL全体が写った画像を公開したり、問い合わせやオンラインチャットに貼り付けたりしないでください。問題を伝える際は、エラーメッセージを残し、URLの機密部分を隠せば十分です。初回の設定では既存の構成をなるべく残し、古い設定の削除とネットワーク接続方法の変更を同時に行わないようにしましょう。失敗したときに元へ戻しにくくなります。

サブスクリプションを追加する前に、通常のネットワーク接続でサービス提供元のページを開き、デバイスがインターネットに接続できることを確認します。別のプロキシやVPNツールが動作している場合は、設定を控えてから一時停止してください。複数のツールが同時に通信を制御し、設定が競合するのを防げます。準備ができたら、次の手順でサブスクリプションを追加します。

01 サブスクリプションを追加：設定をダウンロードして有効化

サービス提供元のページでサブスクリプションURLをコピーし、クライアントに戻って「設定」「サブスクリプション」または「Profiles」を開きます。「新規作成」「追加」「URLからインポート」などの項目を選び、リモート設定としてURL入力欄に完全なアドレスを貼り付けてください。名前には「日常用設定」など、見分けやすい短い名前を付けられます。名前は設定を区別するためのもので、ノードの接続可否には影響しません。

URLの前後に空白や改行が入っていないか確認し、「ダウンロード」「インポート」または「保存」をクリックします。クライアントがサブスクリプションサーバーにアクセスし、返された設定を解析します。正常に完了すると、設定一覧に新しいカードが表示されます。最終更新日時、ノード数、ダウンロード状況などが表示される場合もあります。表示項目はクライアントによって異なるため、特定の項目が見つからないからといって、何度もインポートし直す必要はありません。

設定のダウンロードが完了しても、有効になったとは限りません。新しいカードの「使用」「有効化」をクリックするか、選択済みの状態にして現在の設定として適用します。次に「プロキシ」画面を開き、ノード一覧またはプロキシグループが表示されていることを確認してください。前回使用した設定が保持されるクライアントもあります。インポート成功の表示だけで終わらせず、必ずこの手順を確認しましょう。確認を省くと、ノードを切り替える際に古いサブスクリプションの内容が表示される場合があります。

エラーが表示されたら、取得と解析を切り分ける

タイムアウト、接続失敗、HTTPステータスエラーが表示された場合は、サブスクリプションの取得段階で問題が発生しています。まずURLが完全か、サブスクリプションが有効かを確認し、現在のネットワークでもう一度更新してください。ブラウザーでサービス提供元のホームページを開けても、サブスクリプションAPIが利用できるとは限りません。また、クライアントからのリクエスト内容によって応答が変わる場合があるため、ブラウザーに表示された内容だけで判断しないでください。

YAMLの解析エラー、非対応形式、インポート後にノードが表示されないなどの問題がある場合は、Clash対応のURLをコピーしたか確認してください。通常のノード共有リンクと、完全なYAML設定は別のものです。どのURLでもそのままインポートできるとは限りません。サブスクリプションの変換では、サービスへの信頼性やパラメーターの保持にも注意が必要です。初回設定では、提供元から対応URLを入手してください。形式の違いについては、サブスクリプション形式と変換方法をご覧ください。

リモートサブスクリプションを維持し、生成された設定を直接上書きしない

クライアントによってはローカルファイルから設定をインポートできます。完全なYAMLファイルを入手済みの場合はこの方法を使い、インポート後に設定を有効化してプロキシ画面を確認してください。リモートサブスクリプションを使う場合、初回接続の前にダウンロード済みの設定を直接編集するのは避けましょう。次回の更新で変更が上書きされる可能性があります。ノードとプロキシグループが表示されたら、次にプロキシモードを選択します。この段階ではDNS、ルールセット、スクリプトを変更する必要はありません。

02 プロキシモードを選択：ルールモードとノードの選択

クライアントのホーム画面または「プロキシ」画面に戻り、「モード」の選択欄で初めて使う場合はルールモード（Rule）を選びます。ルールモードでは、現在の設定にあるルールの順序に従って、リクエストを直接接続するか、プロキシグループ経由にするか、拒否するかが決まります。すべてのサービスに最適な経路を自動で判定する機能ではありません。実際の動作は、サブスクリプションに含まれるルールとプロキシグループによって異なります。

よく使われるほかの選択肢に「全般（Global）」と「直接接続（Direct）」があります。全般モードでは、通常、コアに届いたリクエストを全般ポリシーに渡します。問題の切り分けで一時的に使うことはできますが、直接接続モードでは通常、リクエストが宛先へ直結するため、プロキシノードの確認には適しません。初めて使うときは3つのモードを次々に切り替えず、まずルールモードのままにしてください。接続記録から問題の発生箇所を判断しやすくなります。

プロキシグループを開いて出力先を選ぶ

プロキシ画面で、設定内のプロキシ出力用グループを探します。「ノード選択」「プロキシ」「PROXY」などの名前や、サービス提供元独自の名前が付いている場合があります。グループを開き、利用可能なノードを選ぶか、設定済みの自動選択グループを使ってください。グループから別のグループへ接続される構成もあるため、「自動選択」と表示されていても、固定のノードが選ばれているとは限りません。現在どのノードが使われているか、さらに確認しましょう。

遅延テストのボタンがある場合は、一度実行して、明らかにタイムアウトする候補を除外します。テスト結果の数値が示すのは、指定されたテストリクエストをクライアントが完了できたかどうかです。対象サイトでの実際の速度を示すものではなく、サービスがその接続元を受け入れる保証にもなりません。地域名や一度のテスト結果だけで何度も切り替えず、まずテスト可能なノードを1つ選んで一連の手順を完了してください。必要に応じて、動作確認の段階で対象サービスに合わせて調整します。

サブスクリプションによっては、動画、開発サービス、メッセージアプリなどが別々のプロキシグループに設定されています。アクセスするサービス用の専用グループがある場合は、そのグループが適切なプロキシポリシーを参照しているか確認してください。誤ってDIRECTを選ばないよう注意しましょう。この段階ではテスト対象に関係するグループだけを変更し、ほかはサブスクリプションの初期設定のままにすると、変更の影響を比較しやすくなります。

プロキシモードと通信の入口は別の設定

ルールモードは「リクエストがコアに届いた後の処理方法」を決め、システムプロキシやTUNは「アプリのリクエストをコアに届ける方法」を決めます。そのため、ルールモードを選び、ノードテストに成功しても、ブラウザーがプロキシを使っているとは限りません。この手順を終えたら、モードがRuleになっていることと、該当するプロキシグループで出力先が選択されていることを確認してください。次にシステム接続を有効にします。「全般モード」を「すべてのアプリの通信が取り込まれた状態」と混同しないでください。

ルールの作成、プロキシグループのネスト、カスタムの通信振り分けは、初回接続に必須の操作ではありません。ドメインルールの追加や適用順序を確認したい場合は、全プラットフォーム向け設定ガイドをご覧ください。まずは、このガイドで紹介する最短の手順で接続しましょう。

03 接続：コアを起動してシステムに接続

設定とノードの選択はそのままにして、ホーム画面で動作状態を確認します。デスクトップクライアントの中には、起動時にコアも自動起動するものと、「起動」や「接続」をクリックする必要があるものがあります。まず、コアの起動失敗やポートの競合などのエラーがないことを確認してから、通信の入口を有効にしてください。コアが動いていない状態でシステムプロキシをローカルポートに向けると、ブラウザーがすぐに接続できなくなる場合があります。これはサブスクリプションのノード自体の障害とは限りません。

デスクトップ：まずシステムプロキシでブラウザーをテスト

WindowsとmacOSでは、通常、ホーム画面またはトレイメニューから「システムプロキシ」を有効にできます。Linuxでは、デスクトップ環境がクライアントによるプロキシ設定の自動変更に対応しているかも確認してください。スイッチをオンにしてもシステムに反映されない場合は、使用中のデスクトップ環境のネットワークプロキシ設定を確認しましょう。他のデバイスのポート番号をそのまま使わず、現在のクライアント設定で実際の待ち受けポートを確認してください。

有効にしたら、初回テストではシステムプロキシに従う標準のブラウザーを使います。ブラウザーに独自のプロキシ管理拡張機能が入っている場合や、個別のプロキシアドレスを設定している場合は、一時的にシステム設定に従う状態にしてください。拡張機能がシステム設定を上書きするのを防げます。システムプロキシが有効になるのは、その設定を使うアプリだけです。ターミナルツール、ゲーム、一部のバックグラウンドプログラムは自動では利用しないため、必要に応じて後から個別に設定します。

モバイル：接続してシステムのVPN許可を確認

AndroidとiOSでは、クライアントで「接続」をタップします。初回はシステムの案内に従い、VPN接続の作成またはVPN構成の追加を許可してください。許可したらクライアントに戻り、接続状態が維持されていることを確認します。システムにVPNアイコンが表示されれば接続インターフェースは確立されていますが、ノードや対象サイトとの通信が正常とは限りません。次の手順で実際のアクセスを確認してください。

ホーム画面に戻ると接続が切れる場合は、まずクライアントの状態とシステムのバックグラウンド制限を確認し、別のVPNアプリが接続を引き継いでいないか調べてください。多くのデバイスでは、通常のVPN接続を複数同時に使えないよう制限されています。ツールを繰り返し起動すると、原因を特定しにくくなります。クライアントを1つだけ起動し、ほかの通信制御ツールを停止してから再接続してください。

TUNが必要な場合は、通信を取り込む範囲を広げる

システムプロキシ経由でブラウザーが正常に動作する一方、システムプロキシに従わないアプリが直結してしまう場合は、クライアントの対応状況を確認したうえでTUNを有効にできます。デスクトップでは、サービスのインストール、管理者権限の付与、ネットワーク拡張機能の許可が必要な場合があります。クライアントとシステムの案内に従ってください。初回のトラブルシューティングで、ノードの切り替え、DNSの変更、TUNの有効化を同時に行うのは避けましょう。どの変更が結果に影響したのか判断できなくなります。

TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。すべてのリクエストが強制的にプロキシ経由になるわけではなく、最終的な出力先はルールで決まります。有効化後にLANへの接続やネットワークに問題が起きた場合は、まずTUNを無効にし、動作確認済みのシステムプロキシ接続に戻してください。そのうえで設定ガイドの該当プラットフォームの章を参照し、権限とルーティングを確認します。接続を維持したまま、動作確認に進んでください。

04 動作確認：リクエスト記録と実際のアクセス

ブラウザーで新しいページを開き、設定でプロキシ経由になるルールが適用される開発サイトなど、プロキシを使いたいサービスにアクセスします。長時間開いたままのタブを更新するだけでは、既存の接続やキャッシュが再利用される場合があります。ノードを切り替えた直後なら、古いタブを閉じて開き直し、新しい接続でテストしてください。

次にクライアントへ戻り、「接続」「リクエスト」などの名前の画面を開いて、直前にアクセスしたドメインを探します。リクエストがクライアントに届いたか、どのルールが適用されたか、最終的にどの出力先またはプロキシチェーンが使われたかを確認してください。複数のポリシー階層がまとめて表示されるクライアントもあります。画面上の項目名が完全に一致する必要はありませんが、そのリクエストが直結またはプロキシ経由になった理由を確認できることが大切です。

ページが正常に表示され、接続記録にも想定どおりのプロキシ出力先が表示されれば、初回のプロキシ接続はほぼ確認できています。続いて、現在の設定で直結する想定のサイトにアクセスし、記録にDIRECTと表示されるか確認しましょう。ルールモードでは、一部のリクエストが直結し、別のリクエストがプロキシ経由になるのが通常です。すべての記録をプロキシ経由にするために、全般モードへ切り替える必要はありません。

リクエスト記録がない場合：ノードを変える前に接続の入口を確認

まず、システムプロキシまたはモバイルのVPN接続が有効で、コアも起動したままになっていることを確認します。次に、ブラウザーがシステム設定に従っているか、専用のプロキシ拡張機能を使っていないかを確認してください。ブラウザーでは正常でも、特定のアプリだけ記録がない場合、そのアプリがシステムプロキシを使っていない可能性があります。必要に応じてアプリ固有のプロキシ設定を行うか、前のセクションを参考にTUNを検討してください。同じサブスクリプションを再インポートする必要はありません。

リクエストがあるのに失敗する場合：記録をもとに原因を絞る

リクエストがコアに届いているのに接続タイムアウトになる場合は、同じプロキシグループ内の別のノードに切り替えて、同じページで再テストします。認証エラーが出たら、サブスクリプションの有効性を優先して確認し、更新してください。ドメイン名の解決に失敗する場合は、現在のネットワークとDNS設定を確認します。ログには接続先、処理段階、エラーの原因が記録されることが多いため、問い合わせ時には該当項目を残し、アカウント情報、サブスクリプションURLなどの機密情報は隠してください。

一般のサイトにはアクセスできるのに特定のサービスだけ失敗する場合、プロキシ全体の障害と決めつけないでください。対象サービスが接続元の地域、アカウントの状態、アクセス頻度に制限を設けている場合や、専用のプロキシグループを使っている場合があります。まず、そのサービスへの実際の出力先を確認し、別のページにもアクセスして比較しましょう。ノードの遅延テストは参考情報にすぎません。実際のアクセス結果と接続記録をあわせて判断してください。

テストが完了したら、使用中の設定名、モード、プロキシグループ、システム接続方法を記録しておきましょう。これらが今後のトラブルシューティングの基準になります。問題が起きたときは、一度に変更する項目を1つに絞り、同じ操作で再テストしてください。すべての設定を一度にリセットするより、原因を特定しやすくなります。

日常の使い方：サブスクリプションの更新と安全な切断

次回クライアントを開いたら、正しい設定が選択されていることを確認して接続します。サービス提供元がノードを更新した場合は、サブスクリプション画面から「更新」を実行してください。更新後はプロキシグループを確認しましょう。手動で選んだノードが削除されたり、名前が変更されたりしている場合があります。自動更新に対応しているクライアントでは、必要に応じて更新間隔を設定できます。ただし、自動更新に成功しても、すべての対象サービスで接続が確認できたとは限りません。

終了するときは、クライアントでシステムプロキシを無効にするか、VPNを切断してからアプリを終了してください。デスクトップで異常終了後にブラウザーがインターネットへ接続できなくなった場合は、システムにローカルプロキシの設定が残っていないか確認します。残った設定を解除して通常のネットワークをテストしてください。サブスクリプションを削除する必要はありません。モバイルでは、システムのVPN接続が切断されていることを確認しましょう。

これで初回設定の基本手順は完了です。デバイスの変更、起動時の自動実行、権限の設定、カスタムルールの作成については、全プラットフォーム向けインストール・設定ガイドをご覧ください。インストーラーを選び直す場合は、Clashのダウンロードページに戻ってください。動作確認済みの基本設定を維持しながら、機能を一つずつ追加しましょう。