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

01 サブスクリプションを追加して設定を有効にする

URLをコピーしてリモート設定を追加

サービス提供元のサブスクリプション管理ページを開き、Clash または mihomo 用の項目を探して、ページ内のコピー機能を使います。ブラウザーのアドレスバーに表示されたアカウント管理ページの URL や、案内文まで一緒にコピーしないでください。複数の形式が用意されている場合は、利用中のクライアントに対応すると明記された形式を選びます。別のソフト向けの共有 URL は、そのままでは読み込めないことがあります。

クライアントに戻り、「設定」または「サブスクリプション」を開いて、「新規作成」「追加」「URLからインポート」などを選びます。リモート URL を選択し、コピーしたアドレスを URL 欄に貼り付けます。名前には「普段使い」など、用途がわかるものを付けられます。名前はローカルで識別するためのもので、接続方法には影響しません。URLの先頭や末尾に空白や改行がないことを確認し、「インポート」「ダウンロード」「保存」などをクリックします。

ダウンロードが終わるまで待ち、新しい設定カードや最終更新時刻、インポート完了の表示があるか確認します。URLを保存したあと、手動で更新操作が必要なクライアントもあります。リストに名前が表示されただけでは、設定内容のダウンロードが完了したとは限りません。初回のインポートではクライアントの既定の更新設定を使い、リクエストヘッダーや更新間隔などの詳細項目は変更しないでください。

設定を選択して内容の読み込みを確認

新しい設定の横にある「使用」「有効化」などをクリックするか、選択状態にして現在の設定として適用します。続いて「プロキシ」画面を開き、プロキシグループと各グループ内の選択肢が表示されることを確認してください。プロキシグループは、ルールが出口を選ぶための候補をまとめたものです。単一のノード、自動選択グループ、別のプロキシグループなどが含まれる場合があります。設定一覧にカードがあるのにプロキシ画面が空の場合は、同じ URL を何度も追加せず、設定画面に戻って実際に有効化されているか確認します。

YAML ファイルを受け取った場合は、「ファイルからインポート」を選び、そのファイルを指定して有効化します。YAML はインデントで階層を表すテキスト形式です。オフィスソフトで開いてリッチテキスト形式で保存しないでください。ファイルにはノードだけが含まれる場合も、ルールを含む完全な設定が入っている場合もあります。インポート後すぐ使えるかどうかは、不足部分をクライアントが補えるかによります。形式に互換性がない場合は、むやみにファイルを編集せず、利用中のクライアント向けの完全な設定を提供元に依頼するのが確実です。

ダウンロードに失敗した場合は、まず通常のWebページを開けるか確認し、URLをコピーし直して、アカウントの有効期限やサブスクリプション URL が変更されていないか確認します。エラーページやログインページがファイルとしてダウンロードされ、設定の解析エラーになることもあります。このような表示を単純に「ノードの不具合」と判断しないでください。まずはインポート段階で対処します。詳しくはよくある質問のインストール・設定に関する説明を確認し、解決しない場合はトラブルシューティングに進んでください。

完了の目安：現在の設定が選択され、プロキシ画面にサブスクリプションで提供されたプロキシグループが表示されています。次にグループの使い方を決めてから、通信の取り込みを有効にします。

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

まずはルールモードを使う

ホーム画面、ダッシュボード、またはプロキシ設定を開き、「モード」から「ルール / Rule」を選択します。ルールモードでは、設定に含まれるルールに従って、リクエストごとにプロキシ、直接接続などの処理方法が決まります。初回接続に適したモードです。設定に通信の振り分け方が用意されているため、Webページを開くためだけにすべてのリクエストを同じ出口へ送る必要はありません。

ほかの2つのモードとの違いを把握しておくと、誤操作を防げます。「全般 / Global」では通常、すべてのリクエストをグローバルプロキシグループで選んだ出口に送ります。ただし、クライアントが通信を取り込んでいないアプリまで自動的にプロキシ経由になるわけではありません。「直連 / Direct」では通常、プロキシノードを経由せずに接続します。モードが決めるのは、コアに届いたリクエストの処理方法であり、「システムプロキシが有効かどうか」とは別の設定です。そのため、全般モードに切り替えただけで通信の取り込みを有効にしていなければ、ブラウザーがクライアント経由になるとは限りません。

プロキシグループで利用可能なノードを選ぶ

「プロキシ」画面を開き、主要なプロキシグループを展開して、サービス提供元が用意した利用可能なノードを選びます。サブスクリプションによってグループ名は異なるため、必ず「PROXY」というボタンを探す必要はありません。グループ内の選択肢や設定の説明を参考に用途を判断してください。主要グループが別の手動選択グループを参照している場合は、さらに下の階層を展開し、最終的に誤って直連が選択されていないことを確認します。自動選択グループは通常、設定されたテスト条件に基づいてクライアントが候補の出口を選ぶため、各項目を手動で切り替える必要はありません。

クライアントの接続テスト機能を使えば、明らかに失敗する候補を先に除外できます。ただし、1回のテスト結果だけで、すべてのWebサイトへの接続状況を判断しないでください。テスト対象と実際にアクセスするサイトは異なる場合があり、テストに成功しても、すべてのルールが正しく設定されているとは限りません。候補を一つ選び、後の確認手順で実際のリクエストを観察しましょう。初回からノードを何度も切り替えると、どの設定が影響したのか判断しにくくなります。

この段階では、カスタムルールの追加、DNSの変更、複数のサブスクリプションの併用を同時に行わないでください。DNSはドメイン名をネットワークアドレスに変換する仕組みです。関連設定は後続の通信振り分けに影響しますが、初回接続で手動変更する必要はありません。まずはサブスクリプションとクライアントの互換性のある既定設定を使い、具体的な症状が出た場合に対処しましょう。ノード、プロキシグループ、ルール、コアの関係を確認するには、まず用語集をご覧ください。この段階で設定リファレンス全体を読む必要はありません。

完了の目安：モードがルールに設定され、主要なプロキシグループで出口の候補が選択されています。設定と出口の準備ができたので、デバイス上のアプリから接続できる状態です。

03 システムプロキシまたはスマホの接続を有効にする

PC：コアを起動してからシステムプロキシを有効にする

クライアントのホーム画面に戻り、コアが起動していることを確認します。コアは設定を読み込み、ルールを適用してリクエストを転送するプログラムです。GUIのウィンドウは操作画面を提供するもので、ウィンドウが開いていてもコアが起動しているとは限りません。ホーム画面に起動ボタンがある場合は、先にクリックし、状態が実行中に変わるまで待ってから「システムプロキシ」を有効にします。クライアントによってはコアが自動起動するため、その場合は実行状態を確認するだけで構いません。

システムプロキシを有効にすると、ローカルプロキシのアドレスがOSの設定に登録され、その設定に従うアプリで使われます。ネットワーク設定の変更やサービス権限を求める画面が表示されたら、アプリ名を確認し、インストールしたクライアントからの要求であることを確かめて許可してください。初回テストでは、ほかのプロキシクライアントやブラウザーのプロキシ拡張機能をいったん無効にし、設定の競合を避けます。通信を取り込むツールは一度に一つだけにすると、リクエストの経路を確認しやすくなります。

TUNも同時に有効にするのは避けてください。TUNは仮想ネットワークインターフェースを使って通信を取り込む方式で、システムプロキシを参照しない一部のアプリに使えますが、権限、ルーティング、DNSにも関わります。まずはシステムプロキシでブラウザーをテストし、システムプロキシに従わないアプリがある場合に、クライアントの説明を確認してTUNを使うか検討してください。設定によっては両方を併用できますが、初回のトラブルシューティングで最初に試す方法ではありません。

GUIクライアントではなく Linux のコマンドライン版コアを使う場合、mihomo を実行しても通常はデスクトップ環境のシステムプロキシは設定されません。OSのネットワーク設定にローカルプロキシのアドレスと実際のポートを入力するか、アプリ側でプロキシを明示的に指定してください。以下は設定項目の例にすぎず、ノードやルールは含まれていません。サブスクリプションの代わりに使える完全な接続設定ではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port は HTTP と SOCKS の両方のプロキシリクエストを受け付けるローカルポートです。ここで示す 7890 は例にすぎないため、クライアントに表示されている待ち受けポートを確認してください。ローカルの接続先アドレスは通常 127.0.0.1 です。初回利用時は LAN からのアクセスを無効のままにしておけば十分です。PC上のブラウザーを接続するために「LANからの接続を許可」を有効にする必要はありません。

スマホ：接続をタップしてシステムの許可を確認

Android または iOS のクライアントで、ホーム画面の「接続」または起動ボタンをタップします。初回は VPN 設定の追加や VPN 接続の確立を許可するか、OSから確認されます。画面の案内に従って許可してください。許可後にクライアントへ戻り、接続ボタンが接続済みの状態に変わっていることと、OSにも接続状態が表示されていることを確認します。同じ種類の通信取り込み機能を使う別の VPN がデバイス上で動作している場合は、先に切断してから現在のクライアントに接続してください。

クライアントを起動したまま、ブラウザーを開いて次の手順のテストを行います。スマホの画面を消した後に接続が切れる場合は、バックグラウンド実行の制限が原因の可能性があります。初回接続で電池関連の設定をすべて変更する必要はありません。まず画面を点灯してアプリを前面に表示した状態でアクセスできることを確認し、必要に応じてバックグラウンド制限に対処してください。

完了の目安：PCではコアが実行中でシステムプロキシが有効、スマホでは接続済みと表示されています。この状態は接続の入口が有効になったことを示すだけです。実際のリクエストを使って経路全体を確認してください。

04 リクエストが想定した出口を通るか確認

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

ブラウザーを開き、普段から直接接続できるサイトと、サブスクリプションのルール上プロキシ経由になるサイトにアクセスします。新しいタブを使い、ページを再読み込みして新しいリクエストを送ると、キャッシュの表示だけを見るのを避けられます。前者で通常のネットワーク接続が保たれていること、後者でプロキシの出口が機能していることを確認します。1つのサイトを開くだけでは、直接接続とプロキシへの振り分けの両方が想定どおりか確認できません。

続いてクライアントの「接続」または「ログ」画面を開き、先ほどアクセスしたドメインを探して、適用されたルールと最終的な処理を確認します。表示項目はクライアントによって異なります。リクエストが記録されていること、ルールが想定どおりであること、出口が誤って直連や拒否に設定されていないことを確認してください。TUNや特殊なDNS設定を使っている場合は、画面に表示される情報が異なることがあります。初回テストでは、システムプロキシ経由のブラウザーリクエストを基準に判断し、すべての項目が完全に一致することにこだわる必要はありません。

グローバルIPアドレスの確認は、あくまで補助的な方法です。ルールモードでは、確認サイトへの接続が直連に振り分けられることがあります。そのため、表示されるIPアドレスが変わらなくても、それだけでプロキシが機能していないとはいえません。反対に、IPアドレスが変わっても、すべてのアプリの通信が取り込まれている証明にはなりません。サイトへのアクセス結果とクライアントのリクエスト記録を照らし合わせると、問題が接続の入口、ルール、プロキシの出口のどこにあるか判断しやすくなります。

コマンドでローカルポートとターミナル設定を切り分ける

ローカルプロキシの入口をさらに確認する場合は、curl がインストールされていることを確認し、以下のコマンドを実行します。Windowsのターミナルでは、対象のプログラムを明示するため curl.exe と入力してください。コマンド内のポート番号は、クライアントで確認した HTTP ポートまたは混合ポートに置き換えます。テストするサイトの URL も、確認したいアドレスに変更できます。

curl --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://example.com

このコマンドはプロキシを明示的に指定するため、ターミナルがシステムプロキシを参照するかどうかに左右されません。HTTPレスポンスヘッダーが返れば、そのローカルの入口を通じて少なくとも1回リクエストできたことがわかります。ただし、サイトがリダイレクトや拒否のステータスを返す場合があり、必ずしもページの表示に成功したとは限りません。また、ルールによって直連が選ばれる可能性もあるため、この結果だけでリモートのプロキシノード経由だとは判断できません。最終的な出口はクライアントの接続記録と合わせて確認してください。

127.0.0.1 に接続できないというエラーが出た場合は、まずコアが動作しているか、ポート番号が正しいかを確認してください。サブスクリプションをすぐにリセットする必要はありません。ポートには接続できるのにタイムアウトが続く場合は、選択中のノードとログを確認します。ブラウザーでは使えるのに、ターミナルから通常のリクエストを実行すると失敗する場合、ターミナルがシステムプロキシを参照していないことがよくあります。そのためにクライアントを何度も再インストールしないでください。環境変数の設定や詳しい切り分け方法はトラブルシューティングを参照してください。このガイドでは、ターミナル全体の設定を変えないよう、プロキシを明示するテストを使います。

接続を終了して、元に戻せる状態を保つ

動作確認ができたら、現在の設定名、選択したプロキシ、通信を取り込む方式を控えておきます。後から調整するときは一度に一項目だけ変更し、その都度新しいリクエストを送って確認してください。不具合を共有する際は、クライアント名、OSのバージョン、エラー表示を伝えると役立ちます。ただし、サブスクリプション URL、アカウント情報、設定に含まれる認証情報は隠し、設定ファイル全体をそのままアップロードしないでください。

PCで使用を終えるときは、先にシステムプロキシを無効にしてからクライアントを終了します。スマホでは先に接続を切断してください。クライアントによっては、ウィンドウを閉じても終了せず、タスクトレイに最小化されるだけの場合があります。ウィンドウを閉じても、通信の取り込みが停止したとは限りません。終了後に通常のWebページを開けなくなった場合は、システムプロキシが、すでに待ち受けを停止したローカルポートを参照していないか確認して、残っている設定を無効にしてから基本のネットワーク接続をテストします。すぐにOSを再インストールしたり、すべての設定を削除したりする必要はありません。

完了の目安：ブラウザーでWebサイトにアクセスでき、クライアントの記録からリクエストの経路を確認でき、終了後には通常のネットワーク接続も復旧します。これで初期設定は完了です。日常の更新方法やよく使う操作については、よくある質問をご覧ください。明確な不具合がある場合は、トラブルシューティングで該当する症状を順番に確認してください。