Clashの使い方ガイド

操作を始める前に、2つ用意します。現在のシステムに合ったClash GUIクライアントと、サービス提供元から案内されたサブスクリプションURLまたはローカルのYAML設定ファイルです。サブスクリプションURLは通常、https://で始まるリンクで、サーバーノード、プロキシグループ、ルールをクライアントに取得させるために使います。ローカル設定は拡張子が.yamlまたは.ymlのファイルです。どちらか一方を選べばよく、重複して導入する必要はありません。

まずクライアントを起動し、メイン画面が完全に読み込まれるか確認します。デスクトップ版では通常、サイドバーにホーム、プロキシ、設定、接続ログ、設定などが並びます。モバイル版では下部ナビゲーションやサイドドロワーにまとめられていることがあります。この時点でシステムプロキシを急いで有効にしないでください。利用可能な設定を読み込んでいない場合、クライアントが起動中でも、通信をどのプロキシグループに渡すか判断する情報が不足しているためです。

初回起動時にコアの選択や実行コンポーネントのダウンロードを求められた場合は、利用可能になるまで待ってから設定画面を開きます。mihomoコアを採用したクライアントは一般的なClash設定を読み込めることが多い一方、上書き、スクリプト、外部ルールセット、TUNパラメータへの対応はクライアントごとに異なります。初回設定の目的は検証可能な接続を1本確立することです。まずはクライアントの初期設定を使い、DNS、ポート、ルーティングを同時に変更しないほうが、問題発生時に原因を特定しやすくなります。

最後に、システム時刻とタイムゾーンが大きくずれていないことを確認します。証明書接続、サブスクリプションリクエスト、一部の認証処理はシステム時刻に依存します。時刻のずれが大きいと、サブスクリプション更新の失敗やノード接続の切断に見えることがあります。準備ができたら、クライアントの設定画面を開いて最初のステップへ進みます。

クライアントのサイドバーまたは下部ナビゲーションから、「設定」「サブスクリプション」またはProfilesを探します。画面には通常、URL入力欄と「導入」「ダウンロード」「更新」などのボタンがあります。サブスクリプションURL全体をコピーして入力欄に貼り付け、先頭や末尾に余分な空白がないことを確認してから導入します。デスクトップ版では設定名の入力を求められる場合があります。設定名は端末上で識別するためだけのものなので、「日常用ルール」や「モバイル回線」など用途に合わせて付けられます。サブスクリプションの内容は変わりません。

導入を実行すると、クライアントがサブスクリプションを取得してYAMLを解析します。正常なら設定一覧に項目が追加され、設定名、更新日時、更新間隔などが表示されます。「ダウンロード完了」と表示されただけで判断せず、新しい設定をクリックして現在の設定になっていることを確認してください。自動的に新しい項目を選択するクライアントもあれば、保存だけを行い、「使用」「有効化」または選択マークを手動で指定するクライアントもあります。現在の設定に切り替わって初めて、プロキシ画面にその設定のプロキシグループが表示されます。

ローカルのYAMLファイルを受け取った場合は、「ファイルから導入」「設定を開く」またはフォルダーのボタンを選び、システムのファイル選択画面から対象ファイルを指定します。導入後は同じように現在の設定へ切り替えてください。テキストエディターでインデントを不用意に変更しないでください。YAMLは空白で階層を表すため、リスト記号、コロン後の空白、項目の階層がずれると解析に失敗することがあります。設定構造を確認したい場合は、YAMLマニュアルの構造概要で項目の関係を確認できます。

導入後も設定が追加されない場合は、まずサブスクリプションURL全体を確認します。チャットツールによる改行、コピー範囲の不足、URLの途中での切れがあると、リクエストに失敗します。もう一度コピーし、プレーンテキストの入力欄に貼り付けて確認してください。クライアントにタイムアウトと表示されたら、現在のネットワークで通常のWebページを開けるか確認してから更新を再試行します。形式エラーが返る場合は、WebページのURL、ログインページ、または現在のクライアントが対応していない形式を取得している可能性があります。設定の提供元に戻り、正しい導入先を確認してください。

サブスクリプションの更新に成功したら、しばらくは提供元の元設定をそのまま残し、すぐに多重の上書きを作らないことをおすすめします。初回接続では変数をできるだけ減らします。現在の設定1つ、明確なモード1つ、選択済みのポリシー1つがあれば、基本経路を確認できます。次にプロキシ画面へ移動し、プロキシグループを確認して実行モードを選びます。

「プロキシ」「Proxies」または「モード」画面を開きます。Clashの代表的な実行モードには、ルールモード、グローバルモード、ダイレクトモードがあります。初回はルールモードがおすすめです。ルールモードでは、設定内で上から順に並ぶルールに従ってリクエストの行き先を判定します。ドメインによってプロキシポリシーへ渡したり、直接接続したりし、どのルールにも先に一致しないリクエストは最後のフォールバックルールで処理します。日常利用に近く、接続ログで各リクエストがどのルールに一致したか確認しやすい方式です。

グローバルモードは大半の通信を1つのグローバルポリシーに渡すため、ルールの一致問題を一時的に切り分けるのに向いていますが、長期的なルール設定の代わりには適しません。ダイレクトモードではリクエストを直接接続し、プロキシを一時停止したり接続の違いを比較したりする際に使います。モードの選択場所は、ホーム画面上部、プロキシ画面右上、設定画面などクライアントによって異なります。Mode、モード、実行モードの項目を見つけたら、まず「ルール」を選択してください。

モードを決めたら、プロキシグループを確認します。プロキシグループはノードそのものではなく、設定が複数のノードや子ポリシーをまとめて選択できるようにした入口です。手動選択、自動速度測定、フェイルオーバー、負荷分散などが代表的です。画面には「ノード選択」「プロキシ」「国外通信」「自動選択」などと表示されることがありますが、名称は設定の提供元が決めるため、サブスクリプションごとに統一されていません。主要なプロキシグループを開き、明確に利用できるノードを1つ選ぶか、設定内で用意されている自動ポリシーを選択します。

初回テストでは、手動で1つのノードを選ぶほうが原因を追いやすくなります。接続結果を1つの対象に結び付けられるためです。自動ポリシーを使うと、テスト結果に応じてクライアントがノードを切り替えることがあります。ネットワーク状態が変化した場合、自動テストと実際の接続の両方を確認しなければなりません。基本接続が正常だと確認できたら、日常の用途に合わせて自動選択へ戻します。

ノードを選択したら、プロキシグループ名の横に現在の選択が表示されているか確認します。クライアントによってはノード一覧から遅延テストを実行できますが、テスト結果はその探測を完了できるかを示すだけで、すべてのWebサイトやアプリが利用できることを保証するものではありません。1つの数値だけで最終状態を判断しないでください。実際の確認は4つ目のステップで、ブラウザーのリクエストと接続ログを合わせて行います。

プロキシグループがすべて空、DIRECTしか表示されない、またはプロキシ画面が導入前と変わらない場合は、新しい設定がまだ現在の設定になっていない可能性があります。設定画面に戻って先ほど導入した項目を選び直し、プロキシ画面を再確認してください。クライアントが特定の項目を解析できないと明示した場合は、プロキシグループ項目の章で設定構造を確認できます。ただし、初回から設定全体を手作業で書き直す必要はありません。

現在の設定、ルールモード、主要なプロキシグループを確認したら、クライアントのホーム画面に戻ります。デスクトップ版では「システムプロキシ」「System Proxy」「システムプロキシとして設定」などのスイッチを探して有効にします。これにより、OSのHTTPまたはSOCKSプロキシが、Clashのローカル待受ポートを指すようになります。有効化すると、ブラウザーやシステムプロキシに従うアプリのリクエストがクライアントへ渡され、ルールとプロキシグループによって行き先が決まります。

Windows版は通常、システムプロキシ設定を直接変更します。macOSではネットワークサービスの権限確認が必要になる場合があります。Linuxのデスクトップ環境でシステムプロキシを自動的に切り替えられるかは、ディストリビューション、デスクトップ環境、クライアントの実装によって異なります。Linuxクライアントが自動設定に対応していない場合は、システムのネットワーク設定でクライアントに表示された待受アドレスとポートを手動入力します。待受アドレスは127.0.0.1が一般的ですが、ポートはクライアントの設定画面にあるmixed-port、HTTP、SOCKSポートを使用してください。他のガイドにある数字をそのまま入力しないでください。

AndroidとiOSのクライアントは通常、OSが提供するネットワーク接続インターフェースを通じて通信を取り込みます。初回起動時には、システムから接続権限の確認が表示されます。許可すると、ステータスバーにネットワーク接続の表示が出ることがあります。権限を拒否した場合、クライアント内のボタンを押せているように見えても、システム側では接続が確立されません。システム設定で再度許可するか、クライアントから接続要求をやり直してください。モバイル端末で許可が完了したら、まずは標準のルートとDNS設定を維持して基本確認を進めます。

スイッチを有効にしたら、クライアントの状態が接続済みまたは実行中になっているか、接続ログにリクエストが現れ始めたかを確認します。クライアントのプロセス、システムプロキシ、設定の有効性は別々の層です。ウィンドウが開いているのはプログラムが起動したことを示すだけで、システムプロキシが有効ならOSがローカル待受ポートを指し、リクエストが転送されるかどうかは設定、ポリシー、ノードの状態にも左右されます。切り分けでは層ごとに確認し、すべてをノードの問題として扱わないようにします。

システムプロキシを有効にしてもすぐ自動でオフになる場合、クライアントにシステム設定を変更する権限がない、またはローカル待受ポートを起動できていないことがよくあります。設定画面でポートの状態とログを確認します。ポートが別のプログラムに使われている場合は、そのプログラムを終了するか、Clashの待受ポートを変更します。変更後は、システムプロキシが同じ新しいポートを指していることを必ず確認してください。プロセスの特定や項目の変更については、Clashのポート競合を解決する手順を参照してください。

接続が完了しても、ノード、DNS、ルールをすぐにまとめて変更しないでください。現在の状態を維持し、新しいブラウザータブを開いて次のステップへ進みます。確認では、Webページの表示、接続ログ、ルールの一致を同時に調べ、リクエストが先ほど選択したポリシーを実際に通っているか確認します。

まずブラウザーで、普段から正常に開ける一般的なWebサイトを表示し、プロキシ有効化後も基本ネットワークが途切れていないことを確認します。続いて、プロキシポリシーを使ってアクセスする対象ページを開きます。ページが読み込めるだけでは十分ではありません。クライアントの「接続」「Connections」またはログ画面に戻り、直前に発生したドメインリクエストを確認します。通常は、対象ドメイン、一致したルール、使用したプロキシグループ、最終的に選択されたノードまたはDIRECTが記録されます。

ルールの一致情報では、2点を重点的に確認します。対象リクエストが想定したプロキシグループに入り、そのグループが先ほど選んだノードを使用しているかです。ログがDIRECTなら、直接接続のルールに一致しています。プロキシポリシーと表示されるのにページを開けない場合は、ノード接続、DNS解決、対象サービスの状態を続けて確認します。「ルールが行き先を決めること」と「ノードが接続を確立できること」を分けて判断すると、設定を何度も切り替えても本当の原因に届かない事態を避けられます。

ブラウザーのネットワーク出口確認ページも補助的に利用できます。テスト前に、プロキシを有効にしていない状態の出口情報を記録し、接続を有効にしてページを更新して、想定どおり変化したか比較します。ただし、ルールモードでは一部の確認サイトが直接接続になることがあるため、出口が変わらなくてもクライアントが機能していないとは限りません。この場合は接続ログを基準にします。確認サイトのドメインがDIRECTになっていれば、一時的にグローバルモードへ切り替えて比較テストを行い、終了後にルールモードへ戻します。

基本確認に通過したら、短い再起動テストを行います。まずシステムプロキシをオフにするかモバイル端末の接続を切り、クライアントを終了します。再起動後、現在の設定、ルールモード、プロキシの選択が保持されているか確認してから再接続します。クライアントによっては「OS起動時に開始」「起動時にシステムプロキシを復元」といった項目があります。使い方に合わせて設定してください。自動復元を選ぶ場合、ネットワークに問題が起きたときは、クライアントが動作中かを先に確認します。待受していないローカルポートをシステムが指し続ける事態を防げます。

これで初回接続の手順は完了です。日常利用では、サブスクリプション更新後にプロキシグループが変わっていないか確認します。ネットワーク環境を変えた後、モバイル回線とWi-Fiで動作が異なる場合は、クライアントを再インストールする前に再接続してログを確認してください。DNS、ルールセット、上書き・マージ、ノード項目をさらに設定する場合は、Clash YAML設定ファイルマニュアルへ進みます。これらは基本経路を確認してから1項目ずつ調整するのが適切です。

確認に失敗した場合は、現在の設定を変えず、決めた順番で確認します。1つ目は設定の状態です。設定画面に戻り、サブスクリプション更新にエラーがなく、導入した項目が現在の設定になっていることを確認します。2つ目はポリシーの状態です。プロキシ画面でルールモードが選択され、主要なプロキシグループが空ではなく、現在のノードが明確に指定されていることを確認します。3つ目は取り込みの状態です。デスクトップ版ではシステムプロキシが有効か、モバイル版ではシステム接続の権限が許可されているか確認します。

最初の3項目が正常なら、ローカル待受を確認します。設定画面を開き、mixed-port、HTTPポート、SOCKSポートを記録します。OSのプロキシ設定のアドレスは通常ローカルホストを指し、ポートはクライアントの実際の待受値と一致していなければなりません。ポートを変更したのにシステムプロキシが古い値のままだと、ブラウザーはサービスのないポートへリクエストを送り、プロキシ有効化後にすべてのWebページが開けない状態になります。2か所のポートをそろえ、システムプロキシをいったんオフにしてから再度有効にします。

接続ログにブラウザーのリクエストがまったくない場合、問題は通常、システムプロキシ、アプリ側のプロキシ設定、TUNによる取り込みの層にあります。リクエストは見えるものの、すべて不適切なポリシーに一致する場合はルールの順序を確認します。想定したプロキシグループに入っているのに接続に失敗する場合は、同じグループの別ノードを試します。この順番なら入口から出口まで段階的に確認でき、毎回1つの条件だけを変えることで比較結果も明確に保てます。