事前準備：クライアントと利用可能な設定
このガイドは、クライアントをインストール済みで、初回接続を完了したい方向けです。基本の手順は通常10分ほどで終わりますが、サブスクリプションのダウンロード、ネットワーク環境、システムの許可によって時間がかかる場合があります。まずClashまたはmihomo対応の設定を用意します。サブスクリプションURL、または設定プロバイダーから提供されたYAMLファイルを使用できます。クライアントは設定を読み込み、通信を振り分けて接続を確立するためのソフトウェアです。インストールしただけで利用可能なプロキシノードが自動的に用意されるわけではありません。
クライアントを開いたら、設定画面と設定項目を見つけ、ウィンドウが正常に操作できることを確認します。システムのネットワーク設定が競合しないよう、実行中の別のプロキシクライアントやVPNはいったん終了してください。現在のネットワーク接続は維持し、プロキシを有効にする前でも通常のWebサイトにアクセスできることを確認します。基本のネットワークに問題がある場合は、先にWi-Fi、モバイルデータ通信、ルーターを確認してください。そうしないと、後で設定が原因かどうか判断しにくくなります。
サブスクリプションURLにはアカウント情報やアクセス認証情報が含まれる場合があるため、ログイン情報と同じように管理してください。URL全体を公開の掲示板に貼ったり、出所不明のオンラインツールに形式変換のため送信したりしないでください。エラーが起きた場合は、エラーの種類だけを記録します。スクリーンショットを共有する前に、サブスクリプションURL、ノードの認証情報、個人情報を隠してください。準備ができたら、最初の手順で設定を追加します。ポート、DNS、高度なネットワーク項目を先に変更する必要はありません。
ステップ1：サブスクリプションを追加して設定を有効化
設定プロバイダーのアカウントページや案内から、Clash、Clash Meta、またはmihomo対応と明記されたサブスクリプションを探します。コピーするのはサブスクリプションURL全体です。アカウント管理ページのURL、Webページのタイトル、個別ノードの共有テキストではありません。貼り付ける前に、前後の空白や改行、説明文が含まれていないか確認します。複数の形式が提供されている場合は、現在のクライアントが対応するClash互換形式を選んでください。利用できるプロトコルは、クライアントが実際に使用するコアにも左右されます。
クライアントに戻り、「設定」または「サブスクリプション」画面を開いて、新規追加、インポート、またはプラスボタンをクリックします。「URLからインポート」などの項目を選び、URL欄にリンクを貼り付けます。設定名は「日常利用」など、用途がわかるものにできます。更新間隔も指定できる場合は、初回は既定値のままにします。確定したら、クライアントが設定をダウンロードして解析するまで待ちます。似た名前の設定が複数作成されないよう、インポートボタンを続けて何度もクリックしないでください。
インポートに成功すると、通常は設定一覧に項目が追加されます。クライアントによっては、更新日時、有効状態、操作メニューも表示されます。その項目をクリックし、「使用」「有効化」「この設定に切り替え」などを選んでください。ダウンロードが完了しただけでは、現在の設定として有効になっているとは限りません。新しい項目に有効マークが付いていることを確認します。次にプロキシ画面を開き、プロキシグループとノード一覧が表示されれば、クライアントが設定を読み込めています。ステップ2に進んでください。
ローカルのYAMLファイルを受け取った場合は、「ファイルからインポート」を選び、システムのファイル選択画面でファイルを指定して確定します。その後、同じ方法で有効化してください。テキストエディターの内容をサブスクリプションURL欄にそのまま貼り付けないでください。URLとファイルでは、読み込み方法が異なります。ローカルファイルは、リモートサブスクリプションのように更新できるとは限りません。更新可能かどうかは、ファイルの拡張子ではなく、ファイル内のプロバイダー設定とクライアントの機能で決まります。
エラーが出たら、まず失敗した段階を切り分けます。「リクエストがタイムアウトしました」「ダウンロードできません」は、クライアントが設定内容を取得できていない可能性があります。「解析に失敗しました」「未対応のフィールド」は、内容を取得できたものの、形式、構文、コアとの互換性に問題がある状態です。まずURLの有効期限とアカウントの状態を確認し、設定プロバイダーがそのクライアント向けの形式を提供しているか調べます。どのエラーでもDNSを変更したり、構文を理解しないままエラー箇所付近の項目を削除したりしないでください。
この手順の完了条件は「サブスクリプションが一つ表示された」ことではなく、「設定が有効になり、プロキシ画面に想定したプロキシグループが表示されている」ことです。この段階ではまだ接続せず、次に通信モードと、プロキシ通信を処理するグループを選びます。
ステップ2：ルールモードとプロキシグループを選択
クライアントのホーム、プロキシ画面、または設定画面でモードを探します。一般的な名称は「ルール」「全般」「DIRECT」で、英語ではRule、Global、Directと表示される場合があります。初めて使う場合は「ルールモード」を選択してください。設定内のルールに従ってリクエストごとの処理を決めます。直接接続するもの、プロキシグループに送るもの、拒否するものがあります。ルールモードでも、すべてのWebサイトがプロキシ経由になるわけではありません。また、各サイトに適した経路をクライアントが自動で判断するわけでもありません。
全般モードでは通常、コアに届いたリクエストをグローバルポリシーで処理するため、一時的な比較テストに適しています。DIRECTモードでは通常、コアに届いたリクエストを宛先へ直接接続します。ここで重要なのは「コアに届いたリクエスト」という点です。プロキシモードはリクエストがコアに届いた後の経路を決め、システムプロキシやVPNはアプリのリクエストをコアに届けるための仕組みです。モードを全般に切り替えても、システムプロキシを使わないアプリが自動的にプロキシ接続されるわけではありません。
ルールモードを選んだら「プロキシ」画面を開き、設定で主に使われているプロキシグループを探します。設定によって「プロキシ選択」「ノード選択」など名称は異なり、共通のグループ名はありません。グループを開き、現在選択されている項目を確認します。手動選択のグループなら、アカウントで利用できるノードを選びます。自動テストグループやフェイルオーバーグループが既定で選ばれている場合は、まずその設定を維持し、グループに使用可能なノードが含まれているか確認してください。
プロキシグループによっては、ノードが直接表示されず、別のグループが入れ子になっています。たとえば、メイングループで「自動選択」を選び、その自動選択グループがノードから出口を選ぶ構成です。これは通常の設定なので、階層を減らすためにYAMLを変更する必要はありません。確認するのは、メイングループで誤ってDIRECTやREJECTを選んでいないことです。DIRECTは直接接続、REJECTは接続拒否を意味し、通常のプロキシノードではありません。
クライアントに接続テスト機能があれば、候補ノードを一度テストできます。結果が示すのは、指定されたテスト先への接続状況が中心です。ダウンロード速度と同じ意味ではなく、すべてのWebサイトにアクセスできる保証にもなりません。ノードがタイムアウトした場合は、まず同じ設定内の別の使用可能なノードと比較してください。数値を追い求めて設定を何度も切り替えるのではなく、正常に接続できる基準を一つ見つけることが大切です。
メイングループを確認したら、ほかのグループはひとまず設定どおりにしておきます。動画、ダウンロード、特定アプリ向けのグループを個別に選ぶ必要があるかは、実際のルールがそのグループを参照しているかによります。対応するルールに一致しないグループは、選択を変えても効果が見えない場合があります。ルールは上から順に照合され、通常は一致したルールのポリシーが適用されます。構文の詳細は ルールと通信振り分けの用語をご覧ください。ここでは「ルールモードが選択されている」「メイングループに利用可能な出口がある」の2点を確認すれば十分です。
設定とポリシーの準備ができても、アプリのリクエストがクライアントを通るとは限りません。ステップ3ではシステムプロキシまたはスマホのVPNを有効にし、アプリの通信を先ほど選んだルール処理に接続します。
ステップ3：接続とシステムの許可を有効化
PC：コアを起動してからシステムプロキシを有効化
PC向けクライアントでは、まず動作状態を確認します。「起動」「実行」ボタンやコアのスイッチがあれば、動作中になっていることを確認してください。起動時にコアも実行されるクライアントでは、操作を繰り返す必要はありません。次に「システムプロキシ」を探して有効にします。WindowsとmacOSのクライアントでは、通常、現在のシステムのプロキシ設定を変更し、その設定に従うブラウザーやアプリをローカルのプロキシ入口に接続します。
初回はシステムプロキシを使い、TUNを同時に有効にする必要はありません。有効化したら、テスト用ブラウザーで開いていたページを閉じ、新しいタブからリクエストを送ります。ブラウザーにプロキシ拡張機能をインストールしている場合は、拡張機能が別のプロキシ設定を固定していないか確認してください。拡張機能がシステム設定を上書きすると、ページの動作とクライアントのスイッチが一致しないことがあります。ブラウザーはシステムプロキシを利用できますが、一部のゲーム、コマンドラインツール、独立したネットワークアプリは従わない場合があります。これは接続対象の違いによるものです。
クライアントの待ち受けポートとシステムプロキシの接続先ポートは一致させる必要があります。一般的な設定では混合ポートが使われますが、現在のクライアントに表示されている値を確認してください。ガイドで見かけた数字をそのまま使わないでください。クライアントがシステムプロキシを自動設定する場合、通常はアドレスを手入力する必要はありません。手動設定が必要な場合、ローカルアドレスには通常 127.0.0.1 を使い、ポートには現在の設定値を指定します。プロキシノードのリモートサーバーアドレスを、PCのシステムプロキシ欄に入力しないでください。
Linuxでは、デスクトップ環境やクライアントによってシステムプロキシの対応方法が異なります。まずクライアントにシステムプロキシのスイッチがあるか確認し、次にデスクトップ環境に設定が反映されているかを確認してください。コマンドライン版のコアだけでは、すべてのプログラムが自動的にプロキシを使うようにはなりません。アプリやセッションごとに接続方法を設定する必要があります。Linuxのコマンドライン導入は、この簡易手順の対象外です。デスクトップ向けの操作をサーバーにそのまま当てはめず、トラブル対処とネットワーク接続ガイドをご覧ください。
スマホ：VPNを許可してから接続
AndroidやiOSのクライアントは通常、システムのVPNインターフェースを使って通信を接続します。ホーム画面で「接続」または「起動」をタップすると、VPN接続の確立、VPN設定の追加、関連権限の許可を求めるメッセージが表示される場合があります。直前に開いたクライアントからの通知であることを確認し、システムの案内に従って許可してください。許可しない場合、設定やノードを追加済みでも、この接続方法でアプリのリクエストを処理できません。
許可したらクライアントに戻り、状態が接続済みまたは実行中になっているか確認します。システムのステータスバーにVPNアイコンが表示される場合がありますが、システムによってはアイコンが非表示または折りたたまれるため、クライアントの状態も合わせて確認してください。別のVPNが同時に起動すると、現在の接続が一時停止したり、別の設定に切り替わったりすることがあります。テスト中は接続中のクライアントを一つに絞り、競合を先に除外してください。
スマホで初回接続に成功したら、次の動作確認が終わるまでクライアントを前面で起動しておき、バッテリー最適化やバックグラウンド制限はまだ変更しないでください。画面ロックやアプリ切り替えの後だけ切断される場合は、システムのバックグラウンド実行許可を確認します。PCでシステムプロキシに従わないアプリが見つかった場合は、後からTUNモードを検討できます。ただし、ルーティング、権限、DNSに関係するため、初回の動作確認前にほかの設定とまとめて変更することはおすすめしません。詳しくはヘルプセンターをご覧ください。
この手順の完了時には、「PCのシステムプロキシ」または「スマホのVPN接続」のどちらを使っているか明確に把握でき、クライアントが動作中であることを確認できているはずです。接続中の表示でわかるのは入口が有効になったことだけです。ルールとノードの動作は実際のリクエストで確認する必要があるため、ステップ4に進みます。
ステップ4：リクエストとルールの動作を確認
まずクライアントで「接続」「アクティブな接続」または「ログ」画面を開き、ブラウザーで新しいページを開きます。通常どおり直接アクセスできるWebサイトと、現在の設定でプロキシグループを使うはずのWebサイトをそれぞれ選びます。テスト先は実際の利用場面に基づいて選んでください。サイトの所在地だけでルールの結果を推測せず、適用されるポリシーは設定内容と実際のルール照合で確認します。
リクエストを送った後、クライアントに対象ドメインまたは宛先アドレスの接続記録が表示されるか確認します。Webページは複数のドメインにリクエストする場合があるため、リソースのリクエストをメインページのものと混同しないようにしてください。まずメインドメインの記録を探し、ルール、ポリシーチェーン、出口ノードを確認します。クライアントによって表示項目は異なります。プロセス識別を有効にしている場合はアプリ名が表示されることもありますが、プロセス情報がなくてもプロキシに失敗したとは限りません。
プロキシ経由になるはずのリクエストでは、ポリシーチェーンがステップ2で選んだプロキシグループを通り、使用可能なノードに到達しているか確認します。直接接続するはずのリクエストでは、DIRECTと表示されるか確認します。Webページが開けることは最初の確認にすぎません。接続記録のポリシーが想定どおりなら、通信の振り分けも機能しています。ページは表示できてもポリシーが想定と異なる場合は、ノードをすべて切り替えるのではなく、ルールの順序と現在の設定を先に調べます。
接続画面に新しい記録がない場合は、まずブラウザーのキャッシュではなく新しいリクエストを送ったか確認します。次に、システムプロキシまたはVPNが有効か、ほかのクライアントが動いていないか、ブラウザー独自のプロキシ設定を使っていないかを確認します。ログも手掛かりになりますが、ログレベルが低いと詳細が表示されない場合があります。「ログが一行もない」ことだけを根拠に、コアがリクエストを受け取っていないと判断しないでください。
記録はあるのにWebページを開けない場合は、どの段階で止まっているか確認します。REJECTに一致している場合は、設定で意図されたブロックか確認します。DIRECTに一致している場合は、その宛先が直接接続されるべきか確認します。プロキシグループに進んだ後でタイムアウトする場合は、まずノードを変更し、同じURLで再試行してください。名前解決エラー、接続タイムアウト、TLSエラーはそれぞれ異なる症状です。すべてを速度の問題として扱わないでください。一度に変更する条件は一つにし、同じテストURLを使って比較します。
一部のWebページだけが異常で、ほかは正常に開ける場合、すぐにクライアントを再インストールする必要はありません。接続先サービス、ノードの出口制限、ルールグループ、ブラウザーの状態などが局所的な失敗の原因になり得ます。ノードを切り替えて直った場合は、その選択を維持できます。複数のノードで失敗する場合は、トラブル対処ガイドで症状別に原因を調べてください。DNSやFake-IPが関係する場合は、設定を変える前にDNSとネットワークスタックの用語を確認し、現在の設定の役割を理解してください。
動作を確認した後で、PCの起動時にクライアントを自動起動するか、起動時に自動接続するか、サブスクリプションを定期更新するか決めます。各スイッチがプログラムの起動、コアの実行、システム通信の制御のどれに当たるか確認してください。同じ動作とは限りません。PC向けクライアントを終了する前に、システムプロキシも無効になるか確認します。クライアントを終了した後もシステムの接続先がローカルプロキシポートのままだと、通常のWebページにもアクセスできなくなる場合があります。スマホでは接続を停止した後、システムVPNも終了しているか確認してください。
日常の確認は、この短い手順で十分です。設定が有効か、モードとプロキシグループは適切か、接続スイッチが有効か、最後に実際の接続記録があるかを順に見ます。別の端末を使う場合は、ダウンロードセンターで対応するプラットフォームのクライアントを選び、4ステップを繰り返してください。メニュー名や基本用語がわからない場合はヘルプセンターを、接続障害が続く場合は体系的なトラブルシューティングガイドを参照できます。初回から高度な設定をすべて整える必要はありません。