Clashのサブスクリプション導入・接続ガイド

事前準備：クライアントとサブスクリプションを用意

まずmihomo対応クライアントをインストールし、サービス提供元から発行されたClash形式のサブスクリプションURLまたはYAML設定ファイルを用意します。クライアントは設定の読み込み、コアの実行、通信の取り込みを担い、サブスクリプションにはプロキシサーバー、プロキシグループ、ルールなどが含まれます。クライアントをインストールしただけでは接続先サーバーは用意されません。このガイドでは共有サブスクリプションも提供していません。導入前に、入手元、有効期限、利用可能なデバイス数を確認してください。

初回の設定では、プロキシクライアントを1つだけ起動してください。他のプロキシツールのシステムプロキシ、TUN、VPN接続は無効にし、現在正常に使えているネットワーク環境を維持します。組織管理下のデバイスでは、プロキシ設定の変更や仮想ネットワークインターフェースの作成が許可されているか確認してください。あとで元に戻せるよう、既存の手動プロキシ設定を控えておきましょう。接続トラブルの切り分けを目的に、OSのファイアウォールを安易に無効化しないでください。

ここからは複雑なルールを変更せず、まず最小限の接続経路を作ります。初期設定ではサブスクリプションのプロキシグループとルールをそのまま使い、接続を確認してからDNS、自動遅延測定、ルールセットなどを調整します。OSごとのインストール権限、サービスモード、設定ディレクトリの違いは全プラットフォーム向けインストール・設定ガイドをご覧ください。このページでは初回接続の手順に沿って進めます。

STEP 01 / PROFILE

サブスクリプションを導入して設定を有効化

クライアントの「設定」または「サブスクリプション」画面を開き、「新規作成」「追加」「URLからインポート」などを選びます。入力欄にサブスクリプションURL全体を貼り付け、見分けやすい名前を付けてください。URLはサービス提供元がClashまたはmihomo用として案内している設定取得先を使います。アカウントのログインページや決済ページ、ブラウザーのアドレス欄に表示された任意のURLではありません。貼り付け後に先頭・末尾の空白や改行がないか確認し、URL内のクエリパラメーターは削除しないでください。

「ダウンロード」または「インポート」を押し、クライアントに成功と表示されるまで待ちます。通常は設定一覧に項目が追加され、更新日時やリモート設定の表示が付く場合もあります。続いて、その項目の「使用」「有効化」などを選ぶか、該当する設定カードを選択します。インポートと同時に有効化するクライアントもあれば、ファイルを保存するだけのものもあります。一覧に名前が増えたかどうかだけで判断せず、現在の設定が選択されているか、プロキシ画面にサブスクリプション内のプロキシグループが表示されているかを確認してください。

ローカルの .yaml または .yml ファイルを受け取った場合は、「ファイルからインポート」を使ってファイルを選択してください。内容をサブスクリプションURL欄に貼り付ける必要はありません。ローカル設定は定期更新されない場合があります。また、リモートのプロキシリストやルールセットを参照している場合、実行時に外部リソースのダウンロードが必要です。ファイルを選択できたことはインポート画面が正しいことを示すだけで、コアが設定を解析して読み込めたかは別途確認が必要です。

有効化したら「プロキシ」画面を開き、プロキシグループまたはノードが表示されることを確認します。名称はサブスクリプションの作成者によって異なり、「ノード選択」「プロキシ」や PROXY などが一般的です。画面に何も表示されない場合は、設定画面に戻り、インポートした設定が選択されているか確認してから、ログでダウンロードや解析のエラーを調べてください。ダウンロード内容がWebページだった、設定形式に互換性がない、インデントが誤っているといった理由で、一覧に設定があってもコアで使えないことがあります。

初回ダウンロードに失敗したら、まずデバイスがインターネットに接続できるか確認し、次にサービス提供元へサブスクリプションの状態とURLが正しいか問い合わせてください。手当たり次第に別の設定形式を試したり、ダウンロードの問題を隠すためにグローバルプロキシを有効にしたりしないでください。問題を解消したら設定一覧から手動で更新し、更新成功と設定の有効化を確認してから次に進みます。後日サブスクリプションを更新してノード名が変わった場合も、プロキシグループで選択中の項目を確認してください。

STEP 02 / ROUTING

ルールモードと出力ノードを選ぶ

クライアントのホーム画面、プロキシ画面の上部、または設定から「モード」を探し、まず Rule を選択します。日本語の画面では通常「ルール」と表示されます。ルールモードでは、設定内のルールの順序に従って直結、プロキシ、その他の出力先が決まります。日常利用の開始時に適したモードです。選択後はサブスクリプションのルールをそのまま使い、初回接続のために rules を一から作成する必要はありません。

モードの選択と通信の取り込みは別々の設定です。ルールモードは「通信がコアに入った後の処理方法」を決め、システムプロキシやTUNは「どの通信をコアに取り込むか」を決めます。そのため、グローバルモードに切り替えても、システムプロキシを参照しないコマンドラインツールが自動的にクライアントを経由するわけではありません。同様に、TUNを有効にしてもすべての接続先がプロキシ経由になるわけではなく、最終的な経路は現在のモードとルールで決まります。

次に「プロキシ」画面を開き、主要なプロキシグループを展開します。手動選択の一覧がある場合は、サブスクリプションに含まれるノードを選択してください。「自動選択」などのサブグループがある場合は、その選択結果も確認します。ノード名が選択状態になったかだけでなく、対象サイトへのアクセスに使うルールがそのプロキシグループを参照しているかも確認してください。DIRECT は直結を表し、選択してもリモートのプロキシサーバーは経由しません。

「遅延テスト」「速度測定」などのボタンからテストを1回実行します。結果が表示されれば、そのテスト条件でノードの応答を確認できたという意味です。すべてのWebサイト、UDP通信、長時間のダウンロードが成功する保証ではありません。タイムアウトはテスト先や現在のネットワークに起因する場合もあります。初回はテストが完了するノードを選び、数値の小ささだけを追い求めないでください。実際のアクセスと接続ログは4番目の手順で確認します。

この手順を終えた時点で、「ルールモードが選択されている」「主要なプロキシグループでノードまたは自動選択グループが選択されている」の2点を確認できている状態が目安です。対象サイトの通信を処理するグループが分からない場合は、サブスクリプションの既定の選択を維持し、接続後に適用ルールのログを確認してください。ルールの優先順位、プロキシグループの階層、自動選択のパラメーターについては設定ガイドで詳しく解説しています。初回接続の段階ですべてを確認する必要はありません。

STEP 03 / TRAFFIC CAPTURE

コアを起動して通信を取り込む

クライアントのホーム画面に戻り、コアが動作中であることを確認します。起動時にコアも自動起動するクライアントもあれば、「起動」や接続ボタンを押す必要があるものもあります。設定の読み込みに失敗した場合は、接続方式を切り替えずに最初の手順へ戻ってエラーを解消してください。「実行中」と表示されたら、使用中のプラットフォームに合わせて通信の取り込み方法を1つ有効にします。初回のテストではシステムプロキシ、TUN、DNSを同時に変更しないでください。失敗の原因を特定しにくくなります。

デスクトップ：まずシステムプロキシを試す

設定またはホーム画面で「システムプロキシ」を探して有効にします。通常、クライアントがOSのHTTP・HTTPSプロキシをローカルの待ち受けポートに向けます。他のガイドに記載されたポート番号をそのまま使わず、現在のクライアントの設定を確認してください。有効にしたらクライアントを起動したまま、通常はシステムプロキシを利用するブラウザーから新しいリクエストを送信します。ブラウザー拡張機能、個別のプロキシ設定、管理ポリシーがOSの設定より優先される場合があるため、問題があれば個別に確認してください。

コマンドラインツールがシステムプロキシを参照するとは限りません。ブラウザーでアクセスできても、ターミナルで失敗したからといってノードが使えないとは判断できません。プロキシ指定に対応したツールでローカルポートを明示するか、後からTUNを使う方法があります。環境変数の設定方法はターミナルやツールによって異なります。詳しくはブラウザーとターミナルの個別トラブル対処ガイドをご覧ください。まずブラウザーでの動作を確認し、その後ほかのアプリに範囲を広げると、問題を切り分けやすくなります。

モバイル：OSのVPN許可を確認

モバイルクライアントで接続または起動ボタンを押すと、初回は通常、VPN構成の追加を求めるOSの確認画面が表示されます。要求元のアプリを確認して許可し、クライアントに戻って接続状態を確認してください。OSにVPNアイコンが表示されても、通信を取り込む経路が確立したことを示すだけで、サブスクリプション内のリモートサーバーに接続できているとは限りません。以前使っていた別のVPNがある場合は、先に切断してください。OSが同時に1つの接続しか維持できず、誤った判断につながることがあります。

より多くの通信を取り込む場合：TUNを試す

ブラウザーでの接続を確認できたのに、ゲームや一部のコマンドラインツールなどがクライアントを経由しない場合は、TUNを検討します。まずシステムプロキシの状態を控え、システムプロキシを無効にして単独で比較できる状態にします。その後、クライアントの案内に従ってサービスをインストールするかネットワーク権限を許可し、TUNを有効にしてください。仮想ネットワークインターフェース、ルーティング、DNSの取り込み方法はOSによって異なります。権限エラーが発生した場合は、スイッチを何度も切り替えるのではなく、クライアントの案内に従って対処してください。

有効にした後、クライアントのログで仮想ネットワークインターフェースとルートが正常に設定されたことを確認します。ネットワークがすぐに切断された場合は、まずTUNを無効にして復旧するか確認し、動作確認済みのシステムプロキシ経由に戻してください。ほかのVPN、パケットキャプチャーツール、ルーティング設定を次々に追加しないでください。システムプロキシとTUNの動作レイヤーや用途の違いは通信の取り込み方式の比較で解説しています。このページでは、正常に動作する方式を1つだけ使います。

STEP 04 / VERIFICATION

プロキシとルールの動作を確認

クライアントを起動したまま、設定、ルールモード、通信の取り込みが想定どおりか確認し、プロキシ経由でのアクセスが必要なサイトを開きます。既に表示済みのページやキャッシュを接続成功と誤認しないよう、新しいタブでリクエストを送り直してください。ページが表示されることは1つの根拠ですが、通信がどの出力先を通ったかまでは証明できません。対象サイトが直結にも対応している場合があるためです。

クライアントの「接続」または「リクエストログ」画面を開き、ブラウザーから対象サイトに再アクセスして、該当ドメインの記録を探します。確認するのは、宛先、適用されたルール、最終的に使われたプロキシグループまたはノードの3点です。直結ルールが適用されていれば、ページが表示されてもプロキシ経由とは限りません。プロキシグループを経由している場合は、最上位のグループ名だけでなく、最終的なノードも確認してください。接続終了後にログが消えるクライアントでは、ログの保存機能を有効にするか、リクエスト送信と同時に記録を確認します。

信頼できる出口IP確認サービスでも調べ、直結時の結果と比較します。IPの登録地域は参考情報にすぎず、データベースの更新が遅れていたり、IPv4とIPv6で経路が異なったりする場合があります。地域表示だけで判断しないでください。より確実な目安は、新しいリクエストがクライアントに入り、想定したプロキシルールが適用され、対象サイトに実際にアクセスでき、出口情報も選択した出力先と一致することです。

最後に、設定上は直結するはずのサイトへアクセスし、想定したルールが適用されるか確認します。ルールモードでは対象ごとに出口が異なるのが正常です。すべての確認結果を一致させるために、グローバルモードを常用する必要はありません。一時的に比較する場合は現在の状態を控え、グローバルモードに切り替えてノードを明示的に選び、新しいリクエストを送信した後にルールモードへ戻します。既存の長時間接続には切り替え前の経路が引き続き使われる場合があります。

確認が終わったら通常の手順でクライアントを終了し、システムプロキシが元に戻っているか確認します。その後、クライアントを再起動して簡単なアクセス確認をもう一度行い、終了・再起動後も想定どおりの状態であることを確かめます。デスクトップクライアントを終了したのにOSのプロキシ設定がローカルポートを指したままだと、ブラウザーが接続できない場合があります。その場合はノードを次々に変更せず、まずシステムプロキシの設定を元に戻してください。初回接続が確認できてから、OS起動時の自動起動やサブスクリプションの自動更新を設定しましょう。

失敗時は通信経路に沿って確認

4番目の手順で確認できなかった場合は、「設定の取得 → コアの読み込み → ノードからの出力 → 通信の取り込み → ルールとDNS」の順に調べます。設定は一度に1つだけ変更し、同じ接続先で再試行してください。これにより、スイッチを手当たり次第に切り替えて一時的に動かすのではなく、失敗箇所を特定できます。

1. 設定のダウンロードに失敗：インターネット接続、サブスクリプションの有効期限、URLが設定取得用のものかを確認します。HTTPステータスや解析エラーを確認してください。ダウンロード内容がログインページだった場合は、サービス提供元から正しいURLを取得し直します。
2. 設定の読み込みに失敗：ログにYAMLの解析エラー、プロキシグループの参照エラー、外部リソースのダウンロードエラーがないか確認します。まず元のサブスクリプションを再ダウンロードし、原因を特定する前に設定を大幅に書き換えないでください。
3. ノードのテストがタイムアウト：同じプロキシグループ内で別のノードを選び、同じ接続先で再試行します。すべて失敗する場合は、サブスクリプションの状態と現在のネットワーク制限を確認してください。テストに成功しても、実際のアクセス確認は必要です。
4. ブラウザーのリクエストが記録されない：コアが動作しているか、システムプロキシまたはVPNによる通信の取り込みが有効かを確認し、ブラウザー拡張機能によるプロキシ設定も確認します。まずリクエストがクライアントに届くことを確かめてから、ルールの設定を調べてください。
5. 記録はあるが接続に失敗：最終的な出力先と具体的なエラーを確認します。ドメイン名を解決できない場合は、まずDNSを確認してください。接続拒否やタイムアウトの場合は選択中のノードと接続先を調べ、ログが1件出ただけでDNS設定全体を変更しないでください。

追加のサポートを求める場合は、OS、クライアント名、システムプロキシとTUNのどちらを使っているか、接続先、関連するエラーメッセージを記録してください。サブスクリプションURLやアカウント情報を伏せたうえで、必要なログの範囲だけを共有します。「インターネットにつながらない」といった大まかな説明やページ全体のスクリーンショットより、再現できる操作手順のほうが原因を特定しやすくなります。

基本的な接続を確認できたら、全プラットフォーム向けインストール・設定ガイドを参考に、ルールセット、DNSとfake-ip、サービス権限、OS固有の問題に進みましょう。サブスクリプションの更新や通信の取り込み方式の変更後も、4番目の手順で実際のリクエストを確認し、変更が想定どおりか確かめてください。