Clashのサブスクリプション読み込み
と接続設定ガイド

手順 01 · 設定

サブスクリプションを読み込んで設定を有効にする

クライアント左側の「設定」画面を開き、「新規作成」「インポート」またはプラス記号のボタンを探します。サービス提供元から案内されたClash / mihomo対応のサブスクリプションURLを用意し、URL欄に省略せず貼り付けて「ダウンロード」または「インポート」をクリックしてください。入力するのはサブスクリプションURLです。サービス提供元のトップページ、ログインページ、購入ページではありません。クライアントはURLから設定データを取得します。ブラウザーでサイトを開けても、そのURLが利用可能なサブスクリプションとは限りません。

クリップボードから読み込む場合は、URL全体をコピーしてからクライアントに戻り、「クリップボードからインポート」を選びます。入力欄に説明文や空白、改行が混ざっていないか確認してください。特に、チャットアプリで転送した際にURLの末尾が欠けていないか注意しましょう。サブスクリプションURLにはアカウントへのアクセス情報が含まれることがあります。認証情報として大切に扱い、問題を報告するときはURL全体やスクリーンショットに含まれる機密情報を隠してから共有してください。

URLからのダウンロード後、設定カードを選択する

ダウンロードが完了すると、通常は設定一覧に名前付きのカードが表示されます。カードまたは「有効化」ボタンをクリックし、選択済みのマーク、現在の設定を示す表示、または明確な有効状態が確認できるまで操作してください。インポートの完了と使用中の状態は別です。一覧にファイルがあるだけでは、設定が保存されたことしか分かりません。カーネルにポリシーグループやルールを読み込ませるには、その設定に切り替える必要があります。続いて「プロキシ」画面を開き、設定に定義されたポリシーグループが表示されるか確認します。以前の内容が表示されたままなら、設定画面で選択中の項目を確認してください。

初回の有効化時に、クライアントが構文チェックやカーネルの再読み込みを行うことがあります。処理が終わってから次に進んでください。解析エラーが出た場合は、YAML、インデント、フィールドの型、行番号に関する記載がないか確認します。エラー行を削除して無理に起動するのは避けてください。その行が別のポリシーから参照されている可能性があります。サービス提供元が案内するClash形式のサブスクリプションを取得し直し、使用中のクライアントのカーネルが設定に対応しているか確認するのが確実です。

ローカルファイルとサブスクリプションの更新

手元にあるファイルがconfig.yamlまたは.ymlの場合は、「ファイルからインポート」を使って選択します。ドラッグ＆ドロップに対応していることが明記されている場合に限り、ファイルを設定エリアにドロップしてください。ローカルファイルは移行や一時的なテストに便利ですが、サービス提供元がリモートのサブスクリプションを更新しても自動では反映されないのが一般的です。URL形式の設定が定期更新に対応している場合は、設定カードの編集メニューから更新を有効にし、サービスの案内に従って間隔を設定します。更新後は、意図した設定が有効になっていることも確認してください。

ダウンロードがタイムアウトした場合は、端末のインターネット接続とサブスクリプションの有効性を確認してから、再度ダウンロードしてください。DNS、TUN、ポートを立て続けに変更するのは避けましょう。取得結果がWebページの文章だったり、必要な設定が不足しているというエラーが表示されたりする場合は、サービス提供元のページでサブスクリプションの種類を確認します。形式変換やサブスクリプションの問題については、ヘルプセンターもご覧ください。設定が有効になり、プロキシ画面に選択可能なポリシーグループが表示されたら、動作モードを選択できます。

手順 02 · 振り分け

ルールモードとプロキシの接続先を選ぶ

「概要」または「プロキシ」画面を開き、「モード」から動作モードをルール / Ruleに設定します。この設定では、カーネルに届いたリクエストの振り分け方法を指定します。ルールモードでは、設定内のルールが上から順に評価され、リクエストは直結、ポリシーグループ経由、または拒否のいずれかになります。初めて使う場合は、サブスクリプションに含まれるルールをそのまま使い、まず接続を確認しましょう。その後で独自ルールを追加すれば、問題が起きたときに変更箇所を特定しやすくなります。

「全体 / Global」は通常、カーネルに届いた通信をグローバルポリシーで処理するモードで、短時間の比較テストに使えます。「直結 / Direct」は通常、カーネルに届いた通信を宛先へ直接接続します。どちらもクライアントを終了する設定ではなく、システムプロキシの設定を兼ねるものでもありません。特に、グローバルモードを選んでもすべてのアプリの通信が自動で取り込まれるわけではありません。アプリの通信がカーネルに届くかどうかは、システムプロキシ、明示的なプロキシ設定、TUNなどの取り込み方法によって決まります。

使用するポリシーグループを開き、接続先を選ぶ

プロキシ画面で、設定がプロキシ通信に使うポリシーグループを探し、開いて現在のサブスクリプションで利用可能な接続先を選びます。グループ名はサブスクリプションの設定によって異なり、日本語や英語の場合もあります。決まった名前を探す必要はありません。ポリシーグループが別のポリシーグループを参照することもあります。上位のグループを選んだ後も、実際の接続先が分かるまで下位グループの選択を確認してください。

設定に「自動選択」などのグループが用意されていれば、それを選ぶとグループのテスト条件に従ってカーネルが接続先を選びます。手動選択のグループは現在の選択を維持するため、接続先を固定したい場合に適しています。クライアントの接続テストまたは遅延テストを実行し、結果が表示されてからテストに成功した項目を選びます。タイムアウトは、そのテストが成功しなかったことを示すにすぎません。テスト先、ネットワーク、接続先が原因の可能性があります。テストに成功してもあくまで参考であり、後で実際にWebサイトへアクセスして確認する必要があります。

まずは既定のルールを使い、複数の条件を同時に変更しない

初回接続では、変更を2つに絞るのがおすすめです。動作モードをルールモードにし、プロキシ用のポリシーグループで利用可能な接続先を選びます。ルールの順序、DNSモード、接続ポートは同時に変更しないでください。Webサイトへの接続が想定と異なる場合は、まず接続ログで適用されたルールを確認し、必要に応じて上書きを検討します。ルールによる振り分けは、各リクエストの宛先と一致条件で決まります。サイトの所在地やブラウザーの表示言語だけでは、実際の接続先を正確に判断できません。

このガイドでは、ポリシーグループの種類やルールの作成方法は扱いません。自動選択、フォールバック、ルールセットのサブスクリプションについて知りたい場合は、mihomoの詳細設定ガイドをご覧ください。ここでは現在のモードとポリシーグループの選択を把握し、ほかの設定を変えずに通信の取り込みへ進みます。こうしておけば、問題が起きても複数のスイッチを何度も切り替えずに、手順を追って原因を確認できます。

手順 03 · 通信の取り込み

システムプロキシまたはVPN接続を有効にする

クライアントのメイン画面に戻り、カーネルが動作中であることを確認してから、端末のOSに合わせて通信の取り込みを有効にします。カーネルの起動、動作モード、システム側での通信の取り込みは、それぞれ別の手順です。カーネルはリクエストを処理し、モードは通信の振り分け方法を決め、システム側の設定はアプリのリクエストをクライアントに送ります。クライアントのウィンドウが開いているだけ、またはモードがルールに設定されているだけでは、ブラウザーがプロキシを使っているとは限りません。

macOSとWindows：まずシステムプロキシを有効にする

クライアントのホーム画面、設定画面、またはメニューバーのメニューから「システムプロキシ」を探して有効にします。macOSでは、メニューバーから切り替えられるクライアントもあります。システムから補助サービスの許可を求められた場合は、アプリ名と操作内容を確認してから案内に従ってください。有効化すると、通常はシステムのネットワーク設定にある該当するプロキシ項目にローカルプロキシのアドレスが表示されます。確認のためにシステム設定一式を手動で入力し直すのではなく、クライアントに有効化と復元を任せるのがおすすめです。

続いてブラウザーで新しいタブを開き、確認したいWebサイトにアクセスします。通常、システムプロキシ設定に従うブラウザーは新しいリクエストをクライアントに送ります。既存の長時間接続は以前の経路を使い続ける場合があるため、設定を切り替えた後は新たにリクエストを送信してください。別のVPNやプロキシツールも動作中なら、システムプロキシの設定が交互に書き換えられないよう、片方を一時停止します。ポートが使用中と表示された場合は、クライアントが重複して起動していないか確認し、ポートの競合についてはヘルプセンターをご覧ください。

AndroidとiOS：接続をタップしてシステムの許可を確認する

モバイル版クライアントのホーム画面で「接続」または起動ボタンをタップします。初回接続時は、通常、システムからVPN接続の確立またはVPN設定の追加を求められます。許可してクライアントに戻り、接続済みになるまで待ちます。システムにVPNの表示が出ていれば端末に通信を取り込む経路が確立していますが、すべてのリクエストがリモートプロキシを使うという意味ではありません。設定にある直結ルールに一致したリクエストは、引き続き宛先へ直接接続できます。

端末で別のVPNに接続中の場合は、トンネルが切り替わってしまうのを避けるため、先に切断してから試してください。Androidの一部クライアントには、アプリごとのプロキシ設定や対象外アプリの設定があります。テスト時はブラウザーが対象外になっていないか確認しましょう。iOSでアプリを切り替えた後に接続が不安定になった場合は、ステータスバーのアイコンだけで判断せず、クライアントで実際の接続状態を確認してください。OSのバージョンによって許可画面の文言は異なることがあります。端末に表示された選択肢に従って操作してください。

TUNモード：通信の取り込みが必要な場合に有効にする

ブラウザーは正常に使えるのに、システムプロキシに従わないアプリの通信がクライアントに届かない場合は、TUNを検討します。このモードは仮想ネットワークインターフェースとルーティング設定を使って通信を取り込みます。デスクトップでは、サービスのインストール、管理者権限、ネットワーク拡張の許可が必要な場合があります。使用中のクライアントの案内に従って許可し、有効化後に起動エラーが表示されていないか確認してください。システムプロキシとTUNを常に同時に有効にする必要はありません。併用するかどうかは、クライアントの仕様と推奨設定に従ってください。

Linuxのデスクトップ環境でアプリが一律にシステムプロキシを使うかどうかは、デスクトップの設定やアプリによって異なります。コマンドラインツールでは、プロキシを個別に指定する必要がある場合もあります。ここではブラウザーを使った基本的な動作確認にとどめ、ターミナルの環境変数設定は扱いません。TUN、DNS、Fake-IPの連携は、後で詳細設定ガイドを参照して調整してください。この手順が終わったら、システムプロキシが有効、またはVPNが接続済みになっており、クライアントが起動失敗を繰り返し報告していないことを確認します。

手順 04 · 確認

接続とルールの動作を確認する

クライアントの「接続」画面を開いて表示したままにし、ブラウザーで正常にアクセスできるWebサイトを開きます。接続一覧に新しいドメインや宛先が表示されるか確認してください。短時間で切断される通信は一覧からすぐに消えることがあるため、ページを再読み込みしてすぐに確認するか、一覧でドメインを絞り込みます。接続一覧がない場合は、「ログ」を開いてリクエストやエラーを確認してください。画面に表示される通信量の合計ではなく、実行したアクセスを個別のログに結び付けられるかが確認のポイントです。

ログを選択し、クライアントに表示される宛先、適用ルール、ポリシーの経路、接続先を確認します。表示項目の名称はクライアントによって異なり、一部の情報しか表示されない場合もあります。ログにDIRECTと表示されていれば、そのリクエストは直結ポリシーで処理されています。設定内のプロキシ用ポリシーグループを通る場合は、最終的な選択先まで確認してください。MATCHは通常、それ以前のルールに一致せず、最後のルールが適用されたことを示します。それだけで設定に問題があるとは限りません。

直結する想定のリクエストとプロキシ経由の想定のリクエストをそれぞれ試す

まず、現在のサブスクリプションのルールで直結するはずのWebサイトにアクセスし、次にプロキシを使うはずのWebサイトを開きます。接続ログと照らし合わせ、実際の経路を確認してください。サイト名だけで推測せず、設定とログを基準に判断しましょう。Webページでは、画像、スクリプト、APIなど複数のドメインに同時にリクエストを送ることがあり、それぞれ別のルールに一致する場合があります。メインページが開いたからといって、すべての通信が正しく振り分けられたと判断せず、具体的に失敗したドメインを確認してください。

接続先の確認には、プロキシ経由になる想定のリクエストを使って、信頼できる接続元IPの確認サービスにアクセスし、直結時の結果と比較する方法もあります。結果は確認に使ったドメインに適用されるルールの影響を受けるため、あくまで補足情報です。クライアントに表示されるポリシーの経路を置き換えるものではありません。同じ接続元IPが表示されても、プロキシが動作していないとは限りません。たとえば確認用リクエスト自体が直結ルールに一致している場合があります。最終的には、リクエストがカーネルに届いているか、どのルールに一致したか、目的のサイトにアクセスできるかを合わせて判断してください。

設定、通信の取り込み、接続先の順に確認する

接続一覧に送信したばかりのリクエストがまったく表示されない場合は、まず対象の設定が有効か確認します。次に、システムプロキシまたはVPNが実際に有効になっているか、テスト対象のアプリが除外されていないかを確認してください。キャッシュ済みのページを表示しただけでは、新しい通信が発生しないことがあります。もう一度読み込んでから確認しましょう。Linuxや、プロキシを個別に設定したアプリは、デスクトップのシステムプロキシを使わない場合があるため、アプリ側の接続方法も確認してください。

ログにリクエストが表示されているのにタイムアウトする場合は、選択されている接続先が手順2で選んだものと一致するか確認し、同じグループ内の別の利用可能な接続先も試してください。名前解決の失敗、接続拒否、認証エラーがログに明記されている場合は、それぞれDNS、接続先、サブスクリプションの認証情報を確認します。すべてのエラーをルールの問題と決めつけないでください。ログを共有する前に、サブスクリプションURL、アクセス情報、個人的な宛先ドメインを隠してください。詳しいトラブルシューティングはヘルプセンターをご覧ください。初期設定の段階で多くの項目を一度に変更するのは避けましょう。

終了前に通信の取り込みを解除し、更新後に再確認する

直結とプロキシのリクエストがどちらも想定どおりなら、現在のルールモードとポリシーの選択をそのまま使えます。サブスクリプションの更新、ネットワークの変更、接続先の切り替え後は、新しいリクエストを送信して適用ルールとアクセス結果を確認してください。毎回設定を読み込み直す必要はありません。サブスクリプションURLや設定の入手元が変わった場合に限り、最初の手順に戻って入手元を切り替えます。

プロキシを一時的に使わない場合は、クライアントでシステムプロキシを無効にするかVPNを切断してから、アプリを終了してください。デスクトップでは、プロセスを強制終了した結果、停止したローカルポートを指すシステムプロキシ設定だけが残らないよう注意が必要です。終了後にネットワークへ接続できなくなった場合は、システムのネットワーク設定でプロキシの状態を確認するか、クライアントを再起動して通信の取り込みを解除してください。これでサブスクリプション、モード、通信の取り込み、動作確認までの初期設定は完了です。ルール、DNS、ローカル設定をカスタマイズする場合は、詳細設定に進んでください。

詳細設定ガイドを読む · 症状からよくある問題を探す