Clashの基本設定

01 サブスクリプション設定を読み込む

クライアントを起動したら、まず「設定」または「サブスクリプション」の画面を開きます。システムプロキシの設定はまだ行いません。「新規作成」「追加」「URLから読み込む」などの項目を探し、サブスクリプションURLを省略せずに入力します。名前には用途など、見分けやすい説明を付けてもかまいません。URLの前後に余分な空白や改行がないことを確認してから、ダウンロードまたは読み込みを実行します。サブスクリプションURLにはアクセス情報が含まれる場合があります。公開スクリーンショットや質問サイト、オンライン変換サービスにURL全体を貼り付けないでください。

ダウンロードが完了すると、通常は設定一覧に新しいカードが追加され、名前、更新日時、有効状態などが表示されます。続けて「使用」「有効化」またはカード上の選択ボタンを押し、現在の設定として適用してください。一覧に表示されただけでは、コアに読み込まれたとは限りません。正常に読み込まれると、設定の解析エラーが表示されなくなり、「プロキシ」画面に設定で定義されたプロキシグループと選択可能な出口が表示されます。

ローカルファイルを使う場合は「ファイルから読み込む」を選び、config.yamlなどのYAMLファイルを指定します。拡張子はファイルを見分ける目安にすぎず、内容が使用するコアの設定形式に合っている必要があります。ウェブページをYAMLとして保存したり、ノードのリンクだけを含むテキストを完全なClash設定として読み込んだりしないでください。読み込み後は同様に設定を有効化し、プロキシグループが表示されることを確認します。

サービスによっては複数のサブスクリプション形式が提供されています。Clash、Clash Meta、mihomo互換と明記されたものを選んでください。ブラウザーでリンクを開けても、サーバーから内容が返されたことしか分からず、設定として解析できるとは限りません。クライアントで構文エラーや形式エラーが表示されたら、まず形式の選択を確認し、ログインページのURLをコピーしていないか調べてください。エラーを消すために、意味の分からないプロトコル項目をむやみに削除しないでください。

「ダウンロードに失敗しました」と表示されたら、ファイルの取得に失敗したのか、取得したファイルの読み込みに失敗したのかを切り分けます。取得できない場合は、URLが完全か、サブスクリプションの利用権限が有効か、現在のネットワークからURLにアクセスできるかを確認してください。読み込みに失敗した場合は、クライアントのログで具体的な項目エラーを確認します。サブスクリプション更新時に直結とプロキシを選べるクライアントもあります。プロキシ接続をまだ確立していない場合は、現在利用できない出口に更新処理を依存させないでください。

サブスクリプションを正常に読み込めたら、設定全体を手動エディターにコピーして何度も編集するのは避けてください。リモート更新で直接編集した内容が上書きされる場合があり、クライアントの上書き、マージ、スクリプト機能もそれぞれ異なります。初回は設定をそのまま使い、独自ルールが必要になってから、変更を維持する方法を確認しましょう。現在の設定が有効で、プロキシグループが表示されていれば、次の手順に進めます。

02 ルールモードを選ぶ

ホーム画面または設定画面に戻り、「モード」「動作モード」またはModeを探して、まずRule（ルールモード）を選択します。このモードでは、コアに届いたリクエストがrulesの一覧を上から順に照合され、最初に一致したルールで出口が決まります。すべてのアプリの通信が自動で取り込まれるわけではありません。システムプロキシやTUNによる通信の取り込みは次の手順で設定します。先に振り分けのルールを決めてから通信の入口を設定すると、問題の切り分けが簡単になります。

よく使われるほかのモードはGlobalとDirectです。Globalモードでは、コアに届いたリクエストがグローバル設定に従って処理され、Directモードでは直結で通信します。Globalにしてもパソコン上のすべてのアプリがプロキシを使うわけではなく、Directにしてもクライアントが終了するわけではありません。特別なテストが必要な場合を除き、初回設定ではルールモードを使いましょう。モードと通信の取り込み方法を同時に変更すると、どの設定が結果に影響したのか分かりにくくなります。

次に「プロキシ」または「プロキシグループ」の画面を開きます。グループ名は設定の作成者によって異なり、手動選択用のメイングループや、用途別のグループなどが表示されることがあります。ルールから参照されている選択用のメイングループを開き、利用権限があり、現在使用できる出口を選びます。選択後は、チェックマークや枠線、選択中の項目名などが変わるのが一般的です。そのグループが別のグループを参照している場合は、最終的な出口が分かるまで開いて確認してください。

名前だけでプロキシグループの意味を判断しないでください。DIRECTは直結、REJECTは接続拒否を意味し、通常のリモートノードではありません。メインのプロキシグループでDIRECTが選ばれていると、システムプロキシを有効にしていても、該当するリクエストはローカルネットワークから直接送信されることがあります。自動選択グループでは、設定内のテスト先やポリシーに基づいて出口が選ばれるため、ノードを1つに固定できるとは限りません。手動で固定する場合は、設定に用意された選択グループを使ってください。

クライアントの「接続テスト」「疎通テスト」は参考情報として利用できます。ただしテストに成功しても、設定されたテストリクエストに応答があったことを示すだけで、対象サイトやアカウントへのログイン、すべてのアプリの動作が保証されるわけではありません。テスト先自体が原因で失敗することもあります。まず応答のある出口を選び、実際のアクセスと接続ログを合わせて確認してください。テスト結果の数値だけで判断しないようにしましょう。

想定していたグループが設定にない場合は、新しい空のグループを追加する前に、前の手順に戻って現在有効な設定を確認します。グループ名が統一されていないのは珍しくありません。重要なのは、ルールが参照する名前と実際のプロキシ設定が対応していることです。独自ルール、自動選択、プロトコルの詳しい説明はプロトコルのリファレンスを、画面や選択に関するよくある質問はよくある質問を参照してください。モードと出口を確認したら、次にアプリの通信を取り込みます。

03 コアとシステムプロキシを起動

まずホーム画面でコアが動作中か確認します。起動時にコアも自動で動くクライアントもあれば、起動ボタンや接続ボタンを押す必要があるものもあります。設定エラー、サービス未起動、ポートの競合が表示されている場合は、先に解決してからシステムプロキシを有効にしてください。システムプロキシはアプリのリクエストをローカルの待ち受けアドレスに向ける設定です。コアが待ち受けていない状態で有効にすると、ブラウザーなどが接続先のないポートにアクセスしてしまいます。

WindowsとmacOSのデスクトップクライアントには、通常「システムプロキシ」の切り替えがあります。有効にすると、対応するシステム設定が変更されます。UbuntuのGUIクライアントにも同じ項目がある場合がありますが、デスクトップ環境やインストール方法によって反映のされ方が異なります。操作後はクライアントを起動したままにし、設定が有効な状態を保っているか確認してください。別のプロキシクライアントやVPNを併用している場合は、システム設定の競合を避けるため、まずどちらか一方を一時停止してください。

Ubuntu GNOMEではシステムの「設定」を開き、「ネットワーク」内の「ネットワークプロキシ」で現在の値を確認できます。項目の場所はバージョンによって多少異なります。クライアントが自動設定しない場合は手動に切り替え、アドレスに127.0.0.1、ポートにクライアントに表示されたHTTPポートまたは混合ポートを入力します。設定でmixed-port: 7890を使用している場合、通常はHTTPとHTTPSのプロキシ欄の両方に同じアドレスとポートを入力します。

HTTPSプロキシ欄は、ブラウザーがHTTPSサイトにアクセスするときに使うプロキシの入口です。ローカルの入口自体をHTTPSにする必要はありません。欄の名前が違うからといって、ポートをむやみに変更しないでください。混合ポートはHTTPとSOCKS5の両方のリクエストを受け付けます。クライアントが別々のポートを使う場合は、画面の表示に従って入力します。7890はよく使われる例にすぎません。設定で変更している場合は、システムやアプリの値も合わせて更新してください。

デスクトップのシステムプロキシは、すべてのプログラムに強制適用されるルーティング設定ではありません。ブラウザーは通常システム設定を参照しますが、ターミナルツール、ゲーム、一部のアプリは独自のネットワーク設定を使うことがあります。まずブラウザーで正常に動作することを確認し、その後ほかのアプリを設定してください。特定のアプリだけでプロキシを使う場合は、そのアプリにローカルアドレスと対応するポートを個別に入力できます。同じ端末から使うだけなら、接続のためにallow-lanを有効にする必要はありません。コントロール用のインターフェースも安易に公開しないでください。

AndroidとiOSでは通常、クライアントの接続ボタンを押し、システムの確認画面でVPN接続の作成を許可します。これはクライアントが通信を取り込むためのシステム機能で、別のVPNアプリを追加インストールする必要があるという意味ではありません。端末上ですでに別のアプリがこの機能を使用している場合は、どちらを使うか決めてください。アプリごとの通信振り分けに対応しているか、設定項目がどこにあるかは、クライアントとOSのバージョンによって異なります。デスクトップのシステムプロキシ設定をそのまま適用することはできません。

対象アプリがシステムプロキシに従わない場合や、より広範囲の通信を取り込む必要がある場合に限り、TUNを検討してください。デスクトップでは、サービスのインストール、管理者権限の付与、仮想ネットワークアダプターの作成が必要な場合があります。用途の分からない設定を一度に複数有効にしないでください。まず現在の動作する設定を記録し、TUNだけを個別にテストします。有効化後にネットワークの問題が起きたら、TUNを無効にして確認済みの手順に戻してください。DNSや権限に関する問題はトラブル対処で確認できます。

04 リクエストと出口を確認

接続ボタンが有効になっているだけでは、対象アプリが想定した出口を使っているとは限りません。クライアントを起動したまま「接続」またはConnectionsの画面を開き、ブラウザーで新しいタブを作って、アクセス可能で正常に表示されることが分かっているサイトを開きます。該当するドメインの新しい接続が表示されるか、ブラウザーに正常な応答が返るかを確認してください。以前から開いている接続には、前の通信経路が残っていることがあります。新しいリクエストで試してください。

接続の詳細を開き、対象ドメイン、適用ルール、使用中のプロキシグループまたはプロキシチェーンを確認します。クライアントによって表示項目は多少異なりますが、直結、グループ経由の転送、ルールによる拒否のいずれかを判断できるはずです。ルールモードでは、一部のサイトが直結になるのは正常です。リモート出口を確認する場合は、ルール上プロキシグループを通るリクエストを使ってください。すべての接続に同じノードが表示されることを求める必要はありません。

必要に応じて、信頼できる出口IP確認サービスも判断材料として使えます。ただし接続ログと合わせて確認してください。確認サイト自体も振り分けルールの影響を受けるため、ローカルの出口が表示されても、プロキシが動作していないとは限りません。ブラウザーのキャッシュや既存の接続、アカウント情報や位置情報の権限に基づくサイトの地域表示も、通信経路の確認にはなりません。確認すべきなのは「このアプリのこのリクエストが、想定どおりコアに入り、出口が選ばれているか」です。

ターミナルに慣れたデスクトップユーザーは、次のコマンドでHTTPプロキシを明示して、標準のテストサイトにアクセスできます。ポートは、クライアントが実際に待ち受けている混合ポートまたはHTTPポートに置き換えてください。このテストで確認できるのは「コアの入口が使えるか」であり、「アプリがシステム設定を参照しているか」ではありません。また、すべてのターミナルツールが自動でプロキシを使うことを保証するものでもありません。

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

プロキシを明示したコマンドは成功するのに、通常のブラウザーの接続ログに表示されない場合は、ブラウザーがシステムプロキシを使っているか、拡張機能で設定が上書きされていないか、システム設定のポートが正しいかを確認してください。接続ログが表示されているのにリクエストが失敗する場合は、適用されたポリシーや関連ログを確認します。この段階でシステムプロキシを何度も切り替えても、通常は解決しません。HTTPSの警告を回避するために証明書検証を無効にせず、システム時刻、接続先サイト、出口の状態を確認してください。

すべてのリクエストが失敗する場合は、次の順に確認してください。現在の設定が本当に有効か、コアが動作しているか、ローカルポートが待ち受けているか、アプリのリクエストがコアに届いているか。選択した出口の利用可否を調べるのは最後です。一度に変更する項目は1つにし、その都度リクエストを再送信してください。設定、DNS、TUN、モードをまとめて変更しないでください。ポートの競合についてはポート使用中の対処とmixed-portの変更を参照してください。用途が分からないままシステムプロセスを終了しないでください。

動作を確認できたら、有効なモードとプロキシグループの選択を維持し、必要に応じてサブスクリプションの更新や自動起動を設定します。次回の更新後にグループ内の項目が変わることがあるため、問題が発生したら、まず現在の選択が引き続き有効か確認してください。Ubuntuでのサービス運用やプロトコルの選択は、後から学ぶ応用設定です。プロトコルとコアのリファレンスを参照してください。初回接続のために、事前に一通りのサービスを設定する必要はありません。

完了の目安：設定が正常に読み込まれ、コアが動作し、アプリからの新しいリクエストが接続ログに表示され、適用ルールと出口が想定どおりであること。クライアントを終了する前に、システムプロキシを無効にするか、以前のネットワークプロキシ設定に戻してください。TUNを有効にした場合は、クライアントがネットワークの入口を正常に解放したことも確認します。