Clashの使い方ガイド

開始前に確認：設定の入手元と現在のネットワーク

クライアントは設定を読み込み、ルールを適用してプロキシ接続を確立するソフトウェアであり、それ自体が利用可能なサブスクリプションを提供するわけではありません。開始前に、信頼できるサービス提供元または自分で構築したサービスから設定URLを入手し、Clashまたはmihomoで使える形式であることを確認してください。ログインページや決済ページのURL、単独のプロトコル共有リンクは、サブスクリプション欄にそのまま貼り付けて使えるとは限りません。サービス提供元が複数の形式を用意している場合は、使用中のクライアントコアに合った形式を選んでください。

まずプロキシに接続せず、普段アクセスできるサイトを開いて、端末のネットワークが正常であることを確認します。システム時刻も正確か確認してください。その後、ネットワークを制御している他のプロキシクライアントやVPNを終了し、手動で設定しているプロキシがあれば値を控えておきます。複数のアプリがシステムプロキシやルーティングを書き換えていると、画面に「有効」と表示されていても、通信が現在のクライアントに届いているとは限りません。初回はポート、DNS、受信設定を既定値のままにし、最短の接続経路を確認してから一つずつ変更してください。

サブスクリプションURLにはアクセス認証情報が含まれることが多いため、アカウント情報と同様に慎重に管理してください。問い合わせる際は、クライアント名、コア、OS、エラーの種類を伝えれば十分です。スクリーンショットを送る場合は、サブスクリプションURL全体、ノードの認証情報、個人アカウントを隠してください。個人用の設定を、信頼できるか分からないオンライン変換サイトにアップロードしないでください。プロトコル対応やサブスクリプション形式の違いについては、プロトコルとコアの技術リファレンスを参照してください。

手順1：サブスクリプション設定を追加して有効化する

URLを入力して設定のダウンロードを待つ

クライアントの「サブスクリプション」または「設定」画面を開き、「新規作成」「追加」「URLからインポート」などを選びます。リモートサブスクリプションを選択し、見分けやすい名前を付けてから、サブスクリプションURLを省略せずに貼り付けてください。貼り付け後はURLの先頭と末尾を確認し、誤って入った空白、改行、チャットアプリが付けた句読点を取り除きます。ただし、URL内のクエリパラメーターは変更しないでください。更新間隔を設定できる場合は、初回は既定値のままにし、手動更新で正常にダウンロードできることを確認してから自動更新を設定します。

「インポート」または「ダウンロード」をクリックし、処理が完了するまで待ちます。成功すると通常、設定名や更新日時、操作ボタンが表示されたカードが追加されます。カードが表示されただけでは、その設定が使われているとは限りません。「有効化」「使用」または選択ボタンをクリックし、現在の設定が切り替わったことを確認してください。次に「プロキシ」画面を開き、その設定で定義されたプロキシグループが表示されるか確認します。既定のDIRECT項目しか表示されない場合は、どの設定が有効になっているかを確認してください。

ローカルのYAMLファイルがある場合は、「ファイルからインポート」などを使って選択できます。編集で唯一の設定ファイルを上書きしないよう、インポート前に元のファイルをコピーして保管してください。ローカルファイルは通常、リモートサービスが変更されても自動更新されません。一方、リモートサブスクリプションは次回の更新時にダウンロード内容が置き換わることがあります。初めて使う際は、サブスクリプションの内容に大量のルールを直接追加しないでください。独自の設定を維持したい場合は、クライアントの設定オーバーライドやマージ機能を確認しましょう。

追加に失敗したら、ダウンロードエラーと解析エラーを切り分ける

タイムアウトや接続エラーが表示された場合は、まずURLが有効か、現在のネットワークからサブスクリプションサービスにアクセスできるかを確認します。更新リクエストが直接接続、システムプロキシ、クライアントコアのどれを経由するかは、実装や更新オプションによって異なります。ノードを切り替えれば更新リクエストの経路も必ず変わるとは限りません。サブスクリプションのダウンロードに利用可能なプロキシが必要なのに、現在使える設定がない場合は、サービス提供元に初回インポート用の方法を問い合わせてください。設定が済む前にシステムプロキシをむやみに有効にしないでください。

HTTP 401、403、404が表示された場合は、それぞれ認証、サーバー側の制限、URLの有効性を確認してください。詳しい意味はサービス提供元の案内を優先してください。YAMLの解析エラー、未対応のプロトコルやフィールドが表示された場合は、設定内容またはコアとの互換性に問題がある可能性があります。認証情報を含まないエラー部分を控え、選択した形式とコアの種類を確認してください。サブスクリプションが正常に有効化され、プロキシグループが表示されてから次へ進みます。インポートの問題をノードの障害と取り違えないようにしましょう。

手順2：ルールモードとプロキシノードを選ぶ

設定を有効化したら、「プロキシ」または「概要」画面を開き、動作モードを選びます。初回は「ルール」を選択してください。英語表示では通常、Ruleと表示されます。このモードでは、リクエストが設定内のルールに照合され、指定されたDIRECT、拒否、プロキシグループのいずれかに振り分けられます。すべてのサイトが同じノードを経由するわけではなく、アクセスのたびに手動でモードを切り替える必要もありません。日常利用の出発点として適しています。

「グローバル」モードでは、通常、リクエストがグローバルプロキシグループに送られますが、そのグループ内で送信先を選ぶ必要があります。すべてのアプリを自動的にクライアントへ接続するスイッチではありません。「DIRECT」モードでは通常、リクエストが直接送信されますが、システムプロキシが無効になったり、コアが停止したりするわけではありません。モードはコアが送信先を選ぶ方法を変え、システムプロキシやTUNは通信をコアに取り込む方法を変えます。この2つを分けて理解すると、問題発生時に確認する設定を絞り込めます。

続いてプロキシグループの一覧を確認します。手動選択式のグループではノードを選べますが、自動遅延テスト、フェイルオーバー、負荷分散のグループは設定されたルールに従って動作するため、同じように手動固定できるとは限りません。ルールから実際に参照されている選択式グループを見つけ、展開して利用可能なノードを選び、選択中の表示が移ったことを確認してください。グループ名は「プロキシ選択」「PROXY」、サービス提供元独自の名称などさまざまです。ガイドに合わせて名前を変更する必要はありません。グループ内の選択肢が別のプロキシグループを指している場合は、さらに下の階層で実際の送信先を選びます。

クライアントに接続テストや遅延テストの機能があれば、明らかに接続できない候補を除外するために一度実行してもよいでしょう。テスト結果が示すのは、クライアントから指定されたテスト先までの一回の測定値です。ダウンロード速度、継続的な通信速度、すべてのサイトでの接続品質を表すものではありません。タイムアウトはテスト先や経路が原因の場合もあります。まずテストに成功したノードを選び、接続後に実際のリクエストで確認してください。ミリ秒の数値だけを比べて何度も切り替える必要はありません。

選択後は「ルール」モードのままにし、ルールの順序、DNS、プロキシグループの構成を同時に変更しないでください。サイトへの接続が最終的にDIRECTになっても、接続失敗とは限らず、設定どおりの動作かもしれません。次の手順ではアプリの通信をクライアントに取り込み、最後に接続ログで適用されたルールを確認します。プロトコルの特徴、ルールの照合方法、コアの互換性については、技術リファレンスを参照してください。初回接続の前に設定全体を書き換える必要はありません。

手順3：コアを起動してアプリの通信を取り込む

デスクトップ：まずシステムプロキシを使う

クライアントの「概要」または「設定」画面に戻り、コアが起動していて、設定の読み込みエラーがないことを確認します。「起動」ボタンがあれば先にクリックしてください。設定を有効にすると自動起動するクライアントもあります。次に「システムプロキシ」を有効にします。このスイッチは通常、OSのHTTPプロキシをローカルの待受ポートに向け、システムプロキシ設定を参照するアプリからクライアントへリクエストを送ります。有効にした後、ブラウザーからリクエストを再送してください。以前の接続が古い経路を使い続けている場合は、ブラウザーを再起動します。

「ネットワーク」「ポートと受信設定」などの画面で、実際の待受アドレスと混合ポートを確認します。例として127.0.0.1:7890がよく使われますが、実際の値はクライアントの表示に従ってください。mixed-portは、同じポートでHTTPプロキシとSOCKSプロキシの両方を受け付ける設定です。起動ログにポート使用中のエラーが出る場合は、以前のクライアントや他の待受プログラムを確認してください。ポートを変更する場合は、クライアントの受信設定とアプリ側の手動プロキシ設定の両方を更新します。片方だけ変更しないでください。

初回の接続では「LAN内接続を許可」を有効にする必要はありません。この設定は他の端末から本機のプロキシを利用するためのもので、本機のブラウザーがシステムプロキシを使えるかどうかには直接関係しません。無効のままにしておけば、待受アドレス、ファイアウォール、アクセス制御に関する確認を減らせます。外部コントローラーのアドレスはコアの管理用で、ブラウザーのプロキシポートではありません。127.0.0.1:9090などの管理用アドレスをブラウザーのプロキシ設定に入力しないでください。

モバイル：OSのVPN接続を許可する

モバイルで設定を有効にしてノードを選んだら、ホーム画面に戻り、「接続」または接続スイッチをタップします。初回接続時は、VPN設定の追加やVPN接続の許可を求める画面がOSに表示されることがあります。使用中のクライアントからの要求であることを確認して許可してください。接続が成功すると、通常はクライアントに接続中と表示され、OSのネットワーク設定やステータス領域にもVPNの表示が出ます。VPNインターフェースはアプリの通信を取り込むためのOSの仕組みであり、実際の送信先は設定のルールやプロキシグループによって決まります。

許可した直後に切断される場合は、設定、権限、ネットワークインターフェースに関するエラーがログにないか確認してください。すでに別のVPN接続がある場合は、いったん切断してから再試行します。OSによっては、複数のVPNで同時に通信を制御できません。アプリごとのプロキシ設定、対象外アプリ、バックグラウンド実行の制限にも注意してください。対象外にしたアプリはクライアントに通信が届かないことがあります。また、OSがバックグラウンドプロセスを終了すると、接続が切れる場合があります。まずブラウザーを前面に表示して動作を確認し、必要に応じてこれらの設定を調整してください。

手順4：ブラウザーとターミナルを個別に確認する

接続ログでリクエストの経路を確認する

クライアントを起動したまま、ブラウザーで普段利用しているHTTPSサイトを開き、クライアントの「接続」画面を確認します。新しいリクエストが表示されるか、対象ドメイン、適用されたルール、送信先を確認してください。ルールモードでは、同じページのリソースでもDIRECTとプロキシに分かれることがあります。ページが表示できるだけで、すべてのリクエストがノードを経由していると判断しないでください。DIRECTのログも、ただちに異常とは限りません。

ページが表示されても接続一覧に新しい記録がない場合は、接続画面にフィルターが設定されていないか、現在接続中の項目だけを表示していないかを確認します。同じ時間帯のログも判断材料になります。次に、システムプロキシが有効か、ブラウザーが拡張機能や独自のプロキシ設定に通信を横取りされていないかを確認してください。キャッシュや既存の接続は判断を誤らせることがあるため、新しいタブを開いてリクエストを送ります。出口IPアドレスだけを確認しても十分ではありません。ルールモードではIP確認サイトへの通信自体がDIRECTになる場合があるため、ルールと送信先のログを合わせて判断してください。

ターミナルがシステムプロキシを使うとは限らない

ブラウザーでは接続できるのにコマンドラインで失敗する場合は、ターミナルを個別にテストします。多くのコマンドラインツールは、デスクトップのシステムプロキシ設定を自動で読み取りません。以下のようにプロキシを明示してHTTPSリクエストを実行してください。例ではローカルの混合ポート7890を使用しています。実行前に、設定画面に表示された実際のポート番号に置き換えてください。Windows PowerShellではcurl.exeを使うと、環境によって同名のコマンドに別名が割り当てられている問題を避けられます。

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

有効なHTTPレスポンスが返り、クライアントにも該当リクエストが表示されれば、そのコマンドは指定したプロキシを経由して接続できています。レスポンスのステータスは接続先サイトによって異なるため、すべてのサイトで同じステータスが返る必要はありません。ローカルポートに接続できない場合は、まずコアの起動状態とポート番号が一致しているか確認してください。クライアントにリクエストが届いているのに送信に失敗する場合は、ノード、接続先、ログを確認します。ターミナル全体でプロキシを使うには、ツールごとの設定が必要です。一度のコマンドテストが成功しても、すべてのターミナルアプリがプロキシを使っているとは限りません。

WindowsのUWPアプリ：ループバックアクセスを個別に確認する

通常のブラウザーは正常なのに、特定のUWPアプリやアプリコンテナーの制限を受けるプログラムだけがローカルプロキシを使えない場合は、ループバックアクセスの制限を確認します。まず、そのアプリが現在のプロキシ設定を参照していることと、問題がそのアプリだけで起きていることを確認してください。クライアントに「UWPループバック」「ループバック除外」などのツールがあれば、必要な権限で開き、対象のアプリを選んで必要なものだけ除外を有効にします。その後、アプリを完全に終了してから再起動し、動作を確認してください。

ループバック除外で解決できるのは、特定のアプリがローカルの待受アドレスにアクセスする際の権限問題です。サブスクリプションの解析失敗、ノードの接続不可、すべてのプログラムの通信障害は解決できません。すべてのアプリをまとめて選択する方法を一般的な解決策として使わないでください。通常のブラウザーを使うだけなら、この設定は必要ありません。クライアントにツールがない場合は、まずアプリのパッケージIDを確認し、Windowsのアプリコンテナーにおけるループバックの説明を参照してください。使用中のアプリに合わないコマンドをそのまま実行しないでください。

最後に切断してネットワークを元に戻す

テストが終わったら、デスクトップではまず「システムプロキシ」を無効にしてからクライアントを終了します。モバイルでは「切断」をタップして接続を停止してください。普段は直接アクセスできるサイトをもう一度開き、ネットワークが復旧していることを確認します。クライアントの異常終了後もブラウザーが無効なローカルポートへの接続を試みる場合は、システムプロキシ設定を開き、今回追加された手動プロキシを削除してください。職場や学校が提供するプロキシを元から使っている場合は、控えておいた設定に戻します。組織で必要な設定をそのまま消さないでください。

これで、どの設定が動作中か、リクエストにどのルールが適用されたか、最後にどの送信先が処理したかを確認できるはずです。問題が起きたら、「サブスクリプションは有効か → コアは起動しているか → アプリの通信は取り込まれているか → 送信先への接続に成功したか」の順に確認し、一度に変更する項目は一つにして、その都度動作を検証してください。プロトコル、DNS、TUN、設定オーバーライドを調整する場合は、プロトコルとコアの技術リファレンスを参照してください。クライアントを変更する場合は、クライアントのダウンロードページでOSとアーキテクチャに合ったインストーラーを選んでください。