手順 01 / 設定の追加
サブスクリプションを追加して、設定を有効化
まず、信頼できるサービス提供元からサブスクリプションURLを入手します。Clashまたはmihomo向けの設定サブスクリプションであることを確認してください。ユーザーセンターのURL、決済ページ、個別ノードの共有テキストとは異なります。サブスクリプションURLにはアカウントを識別するパラメーターが含まれることがあるため、アカウント情報と同様に管理し、公開コメントやスクリーンショット、オンライン変換サイトに貼り付けないでください。クライアントは設定を読み込んで接続するためのもので、インストールしただけで利用可能なリモートサーバーが用意されるわけではありません。
クライアントを開き、「設定」「サブスクリプション」または「Profiles」画面に進みます。「新規作成」「サブスクリプションを追加」「URLからインポート」などの項目を探してください。入力欄にURLをすべて貼り付け、見分けやすい名前（例：「普段使い」）を付けます。貼り付け後、先頭や末尾に余分な空白、改行、メッセージアプリが付けた句読点がないか確認してください。URLを短く見せるために、疑問符以降のパラメーターを削除してはいけません。「インポート」「ダウンロード」「保存」などを選び、クライアントが初回取得を終えるまで待ちます。
ダウンロード後、この設定を選択
設定一覧に新しいカードが表示されても、すぐに使用されているとは限りません。カードの「使用」「有効化」または選択ボタンを押し、現在の設定として表示されたことを確認します。コアの再読み込みを求められた場合は、案内に従ってください。続いてプロキシ画面を開き、サブスクリプションで定義されたプロキシグループが表示されることを確認します。ルール画面にもルール一覧や読み込み状態が表示されるはずです。設定によってはルールセットやデータファイルの追加ダウンロードが必要です。初回読み込みには時間がかかることがあるため、処理中に更新を何度も押さないでください。
提供元からローカルのYAMLファイルを受け取った場合は、「ファイルからインポート」で選択してください。ファイルの内容全体をサブスクリプションURL欄に貼り付けてはいけません。ローカルファイルは通常、リモートサブスクリプションのように自動更新されません。リモートサブスクリプションは設定画面から手動で更新できます。初回は手動で一度更新し、設定を正しく読み込めることを確認してから、自動更新の間隔を設定するのがおすすめです。サブスクリプションを更新すると、ファイルに直接加えた変更が上書きされることがあります。個別の変更には、クライアントのオーバーライドまたはマージ機能を使いますが、初回設定ではまだ必要ありません。
追加に失敗したら、まずどの段階で止まったか確認
ダウンロードのタイムアウトが表示される場合は、設定を正常に取得できていません。まず基本のネットワーク接続、URLの有効期限、提供元が指定する取得方法の有無を確認してください。YAMLの解析エラー、必須項目の不足、未対応プロトコルなどが表示される場合は、データ自体は取得できていますが、形式またはコアとの互換性に問題がある可能性があります。ブラウザーでURLを開けても、設定が返されているとは限りません。ログインページやエラーメッセージが返される場合もあります。Base64形式のノード一覧とClashのYAMLは別の設定形式です。どのサブスクリプションでもそのまま使えるとは限りません。
形式に問題がある場合は、まず提供元に現在のクライアントに対応したサブスクリプションを問い合わせてください。URL全体を見知らぬ変換サービスに送るのは避けましょう。形式の違いについては、サブスクリプションURLの追加方法と形式の解説をご覧ください。この手順の完了条件は、現在の設定が選択され、プロキシグループが表示され、解析エラーが繰り返し発生していないことです。条件を満たしたら、次に動作モードを選択します。
手順 02 / 出口の選択
ルールモードとプロキシグループを選択
設定の読み込みが終わったら、クライアントのホーム画面、ダッシュボード、またはプロキシ設定に戻り、動作モードを探します。初めて使う場合は通常、「ルール」または「Rule」を選択します。ルールモードでは、現在の設定にあるドメインやアドレスなどの条件に応じて接続先が決まります。直接接続される通信、プロキシグループを経由する通信、拒否される通信があります。そのため、クライアントを起動しても、すべてのサイトが同じリモートノードを経由するわけではありません。これがルールによる振り分けの役割です。
同じ画面には通常、「グローバル」と「ダイレクト」もあります。グローバルモードは、コアに入ったリクエストをすべてグローバル出口に渡すため、切り分け時の一時的な比較には使えますが、設定を確認せずに常用するのはおすすめできません。ダイレクトモードでは通常、コアに入ったリクエストを接続先に直接送ります。動作モードが決めるのは、すでに受け取ったリクエストをコアがどう処理するかです。すべてのアプリの通信を自動的にコアへ送る機能ではありません。「ルールモードを選択済み」と「システムプロキシを有効化済み」は別の状態です。
モードを選んだら、ルールで実際に使われるグループを確認
「プロキシ」または「Proxies」画面を開き、現在の設定で普段の通信に使う選択グループを探します。サブスクリプションによって「ノード選択」「プロキシ」など名称は異なるため、ここでは特定の名前を前提にしません。グループを開き、手動選択グループなら利用可能なノードを選びます。自動選択グループがあれば、それを選ぶと設定に従ってヘルスチェックが行われます。選択後、チェックマークや枠線、現在値が変わったことを確認してください。画面をいったん閉じて再度開き、選択が保持されているかも確認します。
サブスクリプションには、サービスごとの専用グループが含まれることがあります。グループごとに個別選択できる場合もあれば、メインの選択グループを参照する場合もあります。目立つ名前のグループを一つ変更しただけで、すべてのルールに反映されるとは限りません。次の動作確認では、実際のリクエストがどの出口を通ったかを確認します。初回設定ではすべてのグループを一度に調整せず、サブスクリプションの初期設定を維持してください。メインの出口が誤ってダイレクトや拒否に設定されていないことだけを確認し、実際のリクエストで経路を確かめます。
クライアントに「接続テスト」「ヘルスチェック」「速度テスト」などがあれば、一度実行してテスト対象への到達性を確認できます。結果が出ても、その時点でノードからテスト対象までの経路が使えたことを示すだけです。すべてのサイトにアクセスできることや、実際のダウンロード速度を保証するものではありません。逆に、一度タイムアウトしてもテスト先が原因の可能性があります。まず想定に合うノードを一つ試せば十分です。一覧全体を何度も連続してテストする必要はありません。
初回設定ではデフォルトルールを維持し、変更点を絞る
この段階では、インターネットで見つけた長いルールをサブスクリプションにそのまま上書きするのはおすすめできません。ルールが参照するグループ名は設定と一致している必要があり、ルールの優先順位によって出口も変わります。YAMLの形式が正しくても、名前が一致しなければ読み込みに失敗したり、意図しない経路を通ったりすることがあります。「プロキシグループ」「ルールモード」「ノード」の違いは用語早見表で、プロトコル対応、コアの種類、設定の互換性は技術リファレンスで確認できます。このページでは、手順どおりに進められる基本の流れを優先します。
次に進む前に、モードが「ルール」と表示され、メインの出口グループが選択済みで、設定切り替え後にコアのエラーが出ていないことを確認します。選択中のグループ名とノード名を控えておきましょう。次の手順でシステム通信を接続した後、接続一覧に表示される実際の出口と照合できます。
手順 03 / 通信を接続
コアを起動して、接続を開始
設定と出口を決めたら、まずクライアントのホーム画面でコアの状態を確認します。PCクライアントには、起動時にコアが自動で動くものと、「起動」や「接続」を押す必要があるものがあります。動作中になったことを確認してから、「システムプロキシ」を有効にしてください。システムプロキシを使うと、OSのプロキシ設定に従うアプリがリクエストをローカルの待ち受けポートに送ります。端末上のすべての通信を取り込む機能ではありません。ゲームやコマンドラインのプログラム、独自のネットワーク設定を持つアプリなどは、この経路を使わない場合があります。
クライアントに「システムプロキシ」と「TUN」の両方がある場合、初回の動作確認では、比較的確認しやすいシステムプロキシから試すのがおすすめです。最初から両方を有効にしたり、DNSやルートも同時に変更したりしないでください。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、サービスコンポーネントや高い権限が必要になることがあります。まずブラウザーのリクエストが正しく振り分けられることを確認してから、必要なアプリに応じて有効化を検討してください。TUNの対応状況や設定要件はプラットフォームによって異なります。
PC：コアを起動してからシステムプロキシを有効化
Windows、macOS、Linuxのデスクトップクライアントでは、「設定」「ネットワーク」またはトレイメニューを開き、システムプロキシを有効にします。その後、ホーム画面に戻ってスイッチがオンのままか確認してください。Linuxのデスクトップ環境によっては、アプリ側がデスクトップのプロキシ設定に従う必要があります。スイッチがオンになっただけでは、実際に通信できるかは確認できません。初回はほかのプロキシツールを終了し、システム設定の競合を避けましょう。ブラウザーに独自のプロキシ拡張機能が入っている場合は、一時的にシステム設定を使う状態に戻してください。そうしないと、拡張機能側の出口をテストしてしまう可能性があります。
権限の確認が表示されたら、どの操作に対するものかを確認してください。システムプロキシの有効化、サービスコンポーネントのインストール、仮想インターフェースの有効化では、必要な権限が異なります。該当する設定を自分で実行しており、現在使っているクライアントからの確認であるとわかった場合にのみ続行してください。通常のウェブページが開かないからといって、すべてのプログラムを管理者として実行する必要はありません。画面にサービス未インストールと明示された場合は、クライアントの案内に従って必要なコンポーネントをインストールし、元の手順に戻ります。
ログに待ち受けアドレスの競合が表示された場合は、同じポートを使っている可能性があるほかのプロキシプログラムを終了してから、起動し直してください。一般的な mixed-port はHTTPとSOCKSで共用する待ち受けポートですが、実際のポート番号は現在の設定とクライアントに従います。ポートを変更する場合は、クライアントに表示される待ち受けポートと、アプリに手動入力したプロキシポートを一致させてください。チュートリアルに載っているポート番号を、端末で必ず使う固定値と考えないでください。
スマホ：システムVPNの許可と接続状態を確認
AndroidまたはiOSのクライアントでホーム画面に戻り、「接続」または起動ボタンをタップします。初回は通常、システムからVPN設定または接続の許可を求められるので、アプリ名を確認して許可してください。接続後は、クライアントの状態表示が変わり、システム側にもVPN接続中の表示が出ます。ここでいうVPNは、システムのネットワークインターフェースに通信を取り込む仕組みです。すべてのリクエストが必ずリモートプロキシを経由するという意味ではありません。接続先は引き続きルールによって決まり、直接接続するものと選択した出口を使うものがあります。
システムに別のVPN接続があると表示された場合は、既存の接続を切断してから現在のクライアントを試してください。接続後は次の手順で動作を確認するまで、クライアントを前面に表示したままにします。その後、バックグラウンドに切り替えて安定するか確認してください。Androidでは省電力制限がバックグラウンド動作に影響することがありますが、基本の接続を確認する前にバッテリー設定をむやみに変更する必要はありません。バックグラウンドでの切断、権限確認の繰り返し、ポート競合の対処方法はよくある質問をご覧ください。まず目の前の表示から原因を絞り、関係のない設定は変更しないでください。
手順 04 / 実際のリクエスト
ルールと出口を確認して、動作を検証
接続ボタンがオンになったことだけでは、何らかのコンポーネントが起動したとしかわかりません。通信がコアに届いたか、最終的にどの出口が選ばれたかを確認して、はじめて動作を検証できます。まずブラウザーで新しいタブを開き、通常アクセスできるとわかっているサイトに接続して、基本のネットワークが使えることを確認します。次に、現在の設定でプロキシグループを経由するはずのサイトにアクセスしてください。古いタブを何度も確認するだけでは不十分です。ページがキャッシュから表示されていたり、既存の長時間接続が変更後の出口にすぐ切り替わらなかったりすることがあります。
クライアントの「接続」「Connections」またはリクエストログ画面に戻り、先ほどアクセスしたドメインを探します。表示項目はクライアントによって異なりますが、確認するのは対象、適用ルール、出力経路です。対象が今回のリクエストと一致すること、適用ルールから経路を選んだ理由がわかること、出力経路に想定したプロキシグループまたはノードが含まれることを確認します。ルールによって直接接続され、DIRECTと表示されるのは正常です。あるリクエストがノードを経由しないからといって、クライアントが動作していないとは限りません。
ダイレクト接続とプロキシ接続を分けて確認
想定する出口が異なるサイトを二つ選び、それぞれ新しいリクエストを送信して接続一覧と照合します。どちらも設定どおりなら、システムへの通信接続とルールによる振り分けの基本経路が動作しています。出口IPの確認サイトは補足情報として使えますが、そのサイトへのアクセスに使われた出口を示すだけです。ほかのアプリやすべてのドメインが同じ経路を通ることの証明にはなりません。ルールが動作しているかは、IPアドレスが変わったかどうかだけでなく、その接続のマッチ結果を基準に判断してください。
接続一覧にブラウザーのリクエストがまったく表示されない場合は、まずシステムプロキシが実際に有効になっているか、ブラウザーが独自の拡張機能や手動のプロキシ設定を使っていないか確認します。リクエストが現在のコアに届いていないため、ノードを変更しても入口の問題は解決しません。特定のアプリだけ記録されない場合は、そのアプリがシステムプロキシに対応しているか確認してください。さらに多くの通信を取り込む必要がある場合は、ルールモードをグローバルに変更して試すのではなく、TUNの利用を検討します。
リクエストが一覧に表示されるものの出口が想定と違う場合は、手順2に戻り、現在のモード、適用ルール、プロキシグループの選択を確認します。出口が正しいのに接続できない場合は、そのノードの利用可否、サービスの状態、ログに記録された具体的なエラーを確認してください。名前解決エラーは通常、DNSの経路を示します。接続タイムアウトは対象やノードと合わせて判断してください。「タイムアウト」という表示だけでDNSの問題と決めつけることはできません。一度に変更する項目は一つに絞り、リクエストを再送信して結果を確認すれば、どの変更が有効だったかを判断できます。
一度再接続して、初回設定を完了
基本の通信ができたら、一度切断して再接続し、新しいウェブリクエストを送信して、設定とプロキシグループの選択が保持されていることを確認します。PCではクライアントを通常終了した後、システムプロキシが元に戻ることも確認できます。終了後にウェブの表示がおかしくなった場合は、残っているシステムプロキシ設定を先に無効にしてから、クライアントを再起動してください。設定をすぐ削除すると、正常だった出口の選択やサブスクリプション情報も失われ、復旧に手間がかかります。
最後に設定画面に戻り、サブスクリプションを手動で一度更新します。更新後も想定した設定が使われ、主要なプロキシグループに有効な選択があることを確認してください。スタートアップ、バックグラウンド動作、自動更新は、基本の通信経路を確認してから設定できます。初回の追加時にすべて済ませる必要はありません。これで4つの手順の結果がそろいます。設定を読み込めること、ルールモードを選んでいること、システム通信が接続されていること、実際のリクエストでルールと出口が想定どおりであることを確認してください。
たまにページを開けない場合は、まず症状別のトラブルシューティングで該当する内容を確認してください。プロトコルの違い、モバイル版での機能の選び方、mihomo設定との互換性については、プロトコルとコアの技術リファレンスをご覧ください。正常に動く基本設定を残し、機能を一つずつ追加するほうが、設定画面全体を一度に変更するより管理しやすくなります。