Clashの使い方ガイド

ステップ1：サブスクリプションを追加して設定を有効にする

クライアントを開き、「サブスクリプション」「設定」などの設定管理画面に移動します。「追加」「インポート」またはプラスボタンを探してください。サブスクリプションURLを使う場合は、リンクからのインポートを選び、URL入力欄にアドレス全体を貼り付けます。設定を見分けやすい名前を付けてもかまいません。名前を変更してもサブスクリプションの内容は変わりません。URLの前後に余分な空白や改行、チャットアプリが付けた句読点がないことを確認し、「保存」または「ダウンロード」をタップします。

サブスクリプションURLは、サービス提供元のウェブサイトやアカウントのログインページとは別のものです。有効なURLにアクセスすると、設定データまたはクライアントが読み込めるサブスクリプションデータが返されます。ウェブページのURLを貼り付けると、HTMLが返されたり、形式エラーになったりする場合があります。コピーする際は、サービス提供元が案内するClashまたはmihomo対応のサブスクリプションURLを使ってください。URLにアカウントの認証情報が含まれる場合があるため、公開の掲示板には貼り付けず、URLが写った画面全体をトラブル対応のためにアップロードしないでください。

保存後、サブスクリプションのダウンロードが終わるまで待ちます。新しい設定が自動で有効になるクライアントもあれば、設定項目をタップしたり、チェックマークや「使用」ボタンを選んだりする必要があるものもあります。現在の設定を示す表示があるか確認してから、「プロキシ」画面に切り替えます。設定に含まれるプロキシグループと選択肢が表示されていれば、読み込みと設定の適用が次の段階まで進んでいます。サブスクリプション名が表示されただけでは、その設定が現在の実行設定になったとは限りません。

ローカルのYAMLファイルを使う

設定ファイルを受け取った場合は、インポートメニューから「ファイルからインポート」を選び、ローカルの.yamlまたは.ymlファイルを開いて、現在の設定として指定します。YAML全体をサブスクリプションURLの入力欄に貼り付けないでください。ローカルファイルのインポートでは、通常その時点の内容だけが保存されます。別途更新元を設定しない限り、サービス提供元のサブスクリプションに合わせて自動更新されるとは限りません。

初回のインポート時は、ノードのパスワード、プロトコル項目、ルールをすぐに編集しないことをおすすめします。まず元の設定のまま接続すると、原因を切り分けやすくなります。未対応の項目があるとクライアントに表示された場合は、エラー行を削除するのではなく、サブスクリプションの形式とコアの要件が合っているか確認してください。一部のノードプロトコルや項目にはmihomoが必要で、古いクライアントでは読み込めないことがあります。クライアントの選び方ガイドを確認してから、クライアントを変更するか判断してください。

ダウンロードできない場合は配布元を確認

タイムアウト、認証エラー、解析エラーが発生した場合は、まず端末がインターネットに接続できることを確認し、サブスクリプションURLをコピーし直します。認証エラーの場合は、サービス提供元のアカウントページでURLの有効期限を確認してください。解析エラーの場合は、サブスクリプション形式の選択が正しいか確認します。自動更新の間隔はひとまず初期設定のままにし、短時間に何度も更新しないでください。エラーの詳しい対処方法はサブスクリプションの更新に失敗した場合の対処法をご覧ください。

このステップを終えたら、現在有効な設定を特定でき、プロキシ画面でプロキシグループを確認できる状態になります。次に、リクエストの振り分け方法を決めてから、システムの通信経路を有効にします。初回接続の経路を確認しやすくなります。

ステップ2：ルールモードとプロキシグループを選ぶ

ホーム画面、プロキシ画面、またはモード設定で「ルール」「グローバル」「DIRECT」を探します。初めて使う場合はルールモードがおすすめです。設定ファイルのmode: ruleに相当し、コアに届いたリクエストがrulesの順に照合され、ルールで指定されたノード、プロキシグループ、またはDIRECTに送られます。ルールモードは、すべてのウェブサイトの用途を自動判定する機能ではありません。実際の動作は、現在の設定に含まれるルールによって決まります。

「グローバル」モードでは、コアに届いたリクエストがグローバルプロキシグループに送られます。通常は、そのグループで出力先も選択する必要があります。「DIRECT」モードでは、コアに届いたリクエストが宛先へ直接接続されます。モードが決めるのは、コアが受け取ったリクエストの処理方法です。すべてのアプリの通信をコアに送る機能ではありません。そのため、グローバルを選択していても、ゲームやコマンドラインツールなどの通信がプロキシを経由しているとは限りません。

プロキシグループを開いて出力先を選ぶ

モードをルールに設定したら、「プロキシ」画面を開き、設定に含まれる主な選択グループを展開します。グループ名はサブスクリプションの作成者が決めるため、日本語名や英語名の場合があり、必ず「PROXY」とは限りません。手動で選択できるグループを見つけ、利用可能なノードを選んでください。設定ファイルでは通常type: selectに該当します。グループ内に別のプロキシグループが含まれている場合は、さらにその下の階層を開き、最終的な出力先が想定どおりか確認します。

対象グループでDIRECTが選択されていると、そのグループを参照するリクエストは直接接続されます。拒否する出力先が選ばれていると、リクエストが失敗する可能性があります。ノードの横に選択マークがあるかだけでなく、ルールが実際にどのグループを参照しているかも確認してください。url-testなどの自動選択グループは、通常、設定されたテスト方法に従ってクライアントがノードを選びます。手動選択のリストとして無理に操作する必要はありません。

クライアントに遅延テストのボタンがある場合は、一度実行して、指定されたテストリクエストが完了するか確認できます。結果が示すのは、そのテスト先と実行時のネットワーク状況だけです。すべてのウェブサイトにアクセスできることや、実際のダウンロード速度を保証するものではありません。複数のノードを次々に切り替えて、どれが有効だったか推測するのは避けてください。選択を一つに決めて次のステップで接続し、実際のウェブページへのリクエストと接続ログで確認します。

クライアントによっては、前回選択したプロキシグループが保存されます。サブスクリプションを切り替えた後は、名前が同じでもノードの内容が同じとは限らないため、現在の選択を確認してください。グループ間の参照関係を確認したい場合は、プロキシグループの項目リファレンスをご覧ください。初回設定では、対象グループに明確で利用可能な出力先が選ばれていることを確認すれば十分です。

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

設定が読み込まれ、モードとプロキシグループも決まりました。次は、アプリのリクエストをクライアントに送る必要があります。クライアントに「実行中」と表示されていても、コアが起動しているだけで、ブラウザーが実際に使っているとは限りません。デスクトップのシステムプロキシ、スマートフォンのVPN、TUNはそれぞれ異なる通信の入口です。ルールモードと混同したり、初回接続で一度にすべての機能を有効にしたりしないでください。

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

WindowsまたはmacOSのクライアントで、ホーム画面、設定画面、またはトレイメニューから「システムプロキシ」を見つけて有効にします。通常、システムのHTTP／HTTPSプロキシがローカルの待ち受けアドレスとポートに設定されます。初回確認ではシステムプロキシ設定に従うブラウザーを使い、クライアントを起動したままにしてください。macOSではネットワーク設定の変更許可を求められる場合があります。システムのメッセージを読み、インストールしたクライアントからの要求であることを確認してから許可します。

Linuxのデスクトップ環境では、システムプロキシへの対応が環境によって異なります。クライアントでシステムプロキシを有効にしてもブラウザーの接続ログが表示されない場合は、デスクトップのネットワーク設定やブラウザー独自のプロキシ設定を確認してください。手動設定では、ローカルアドレスは通常127.0.0.1です。ポートはクライアントに現在表示されている待ち受けポートを使います。例示されたポートがすべての環境で共通とは限りません。mixed-portを使う場合、同じポートでHTTPとSOCKSのリクエストを受け付けられますが、アプリ側で正しいプロキシタイプを選ぶ必要があります。

初回の利用で「LAN内からの接続を許可」を有効にする必要はありません。ローカルブラウザーからローカルプロキシを使うことと、ほかの端末からPCのプロキシに接続できるようにすることは別です。ブラウザーの動作確認だけなら、TUNを同時に有効にする必要もありません。TUNは仮想ネットワークアダプター、ルーティング、DNSに関わるため、基本の接続を確認してから個別に設定してください。項目や権限の詳細は、設定リファレンスの通信入口に関する説明をご覧ください。

スマートフォン：システムVPNの設定を許可する

AndroidまたはiOSのクライアントで「起動」「接続」またはメインスイッチをタップします。初回接続時には、VPN設定の追加や接続を求めるシステムメッセージが表示されることがあります。アプリ名を確認して許可し、システムの指示に従って端末の認証を完了してから、クライアントに戻り接続状態を確認します。システムにVPNアイコンが表示されれば、該当する通信の入口が確立されています。プロキシノード経由で通信するかどうかは、ステップ2で選んだモード、ルール、プロキシグループによって決まります。

テスト中は、ルーティングの競合を避けるため、ほかのVPNやプロキシツールをいったん切断してください。Androidでアプリごとのプロキシ設定や除外リストを使っている場合は、テストするブラウザーが除外されていないか確認します。スマートフォンが画面ロック後に切断される場合は、クライアントのバックグラウンド動作やシステムのバッテリー制限を確認してください。初回接続の前に、バックグラウンド関連の設定を一括で変更する必要はありません。

スイッチを入れてもすぐにオフへ戻る場合は、「ログ」を開き、起動時付近のエラーを確認します。ポートの競合、設定の解析失敗、システムの許可未完了では対処方法が異なります。エラーの内容と発生した画面を記録するだけにし、設定全体を公開しないでください。クライアントが動作し続け、通信入口のスイッチがオンになったら最後のステップに進みます。状態アイコンを見るだけでは確認は完了しません。

ステップ4：リクエストが想定した出力先を通るか確認する

ブラウザーでHTTPSに対応した既知のウェブページを開き、新しいリクエストを送信します。開いたままのページはキャッシュが使われたり、既存の接続が以前の経路を使い続けたりすることがあるため、表示を眺めるだけでは不十分です。新しいタブを開いて対象のURLを再読み込みし、すぐにクライアントの「接続」画面へ切り替えて、ドメイン名またはプロセス名から先ほどのリクエストを探します。

まず接続ログを確認し、次に出口IPアドレスを確認

クライアントでルールと出力経路を確認できる場合は、対象のドメイン名がアクセスしたサイトと一致するか、どのルールに一致したか、最終的にどのノードまたはDIRECTが使われたかを確認します。ルールモードでは、サイトによってDIRECTになるのは正常です。DIRECTの記録をすべて失敗と判断しないでください。プロキシ経由になる想定のサイトを選び、指定したプロキシグループに入っているか、そのグループの経路をたどって最終的な出力先を確認します。

出口IPアドレスを比較する場合は、同じネットワーク条件で、信頼できるIPアドレス確認ページに表示されるパブリックIPアドレスを接続前後で比較します。ブラウザーを終了して再起動し、以前の接続が再利用されないようにしてください。アドレスの違いは判断材料の一つにすぎません。確認ページへの通信がルールでDIRECTに設定されている場合、アドレスが変わらなくても、すべてのプロキシ通信が失敗しているとは限りません。ページに表示された地域名だけで判断せず、出口の結果とクライアントの接続ログを合わせて確認してください。

ログや接続画面には、アクセスしたドメインなどの情報が含まれることがあります。トラブル対応ではテストリクエストに関係する部分だけを残してください。共有する前にサブスクリプションURL、アカウント情報、無関係なアクセス履歴を削除します。確認が終わったら、トラブル対応に必要な範囲を超えて記録が続かないよう、一時的に有効にした詳細ログをオフにできます。

動作しない場合は通信の入口から順に確認

1. プロキシ画面にプロキシグループが表示されない：サブスクリプションの追加手順に戻り、ダウンロードが完了し、設定が有効になっていることを確認します。まずシステムのネットワーク設定を変更するのは避けてください。
2. ブラウザーでアクセスしても該当する接続がない：システムプロキシまたはスマートフォンのVPNが有効か、ブラウザーがシステムプロキシを使わない設定になっていないか、アプリごとのルールで除外されていないか確認します。接続ログがすぐに消えることもあるため、リクエストを再送信して確認してください。
3. 接続ログはあるがDIRECTになっている：現在のモード、一致したルール、プロキシグループの選択を確認します。比較のために一時的にグローバルモードを使う場合は、グローバルグループを選び、テスト後にルールモードへ戻してください。
4. プロキシ経由の記録はあるがリクエストに失敗する：同じ接続先のまま、利用可能とわかっている別のノードで再試行し、関連するログを確認します。ノードのテストに成功しても、対象のウェブサイトにアクセスできるとは限りません。

設定を一度に一つだけ変更し、そのたびに新しいリクエストを送ると原因を特定しやすくなります。ブラウザーは使えるのにほかのアプリが使えない場合、初回接続の基本手順は完了しています。以降は、そのアプリがシステムプロキシに対応しているか、独自のプロキシ設定を使っていないか、別の通信入口が必要かを確認してください。DNS、Fake-IP、TUN、ルールの上書きは初回接続の手順では扱いません。関連する構文はconfig.yamlの設定リファレンスをご覧ください。

終了時と次回起動時の操作

デスクトップではクライアントを終了する前にシステムプロキシを無効にしてください。有効なまま終了すると、システムから停止済みのローカルポートへリクエストが送られ、ブラウザーが突然インターネットに接続できなくなることがあります。スマートフォンではクライアントの停止または切断ボタンで接続を終了します。システムの「VPNを常時接続」や「VPN未接続時の通信をブロック」を有効にしている場合は、現在の使い方に合っているか確認してください。

次回起動したら、現在の設定とプロキシグループの選択が保持されているか確認してから、通信の入口を有効にします。サブスクリプションの更新でノードやルールが変わることがあります。更新後に問題が起きた場合は、設定ファイル全体を上書きするのではなく、該当するプロキシグループを再確認してください。接続画面で実際のリクエストに適用されたルールと最終的な出力先を確認できれば、初期設定の手順は完了です。