初期設定 / 約10分の手順
Clashの使い方ガイド
サブスクリプションの追加と接続確認
4つの手順を順に進めます。サブスクリプションを追加し、プロキシモードを選択して接続を有効にし、出口を確認します。まずブラウザーの通信を確認してから、TUNによる制御が必要なアプリに対応しましょう。一度に複数の設定を変えないでください。
事前準備:クライアントと設定を用意する
クライアントをインストールしたら、一度起動し、メイン画面が開くことと、コアでエラーが繰り返し発生していないことを確認します。このガイドでは、信頼できる提供元のサブスクリプションURL、または現在のコアに対応したYAML設定ファイルがあることを前提とします。クライアントは設定を読み込み、ルールを適用して接続を確立するソフトウェアです。インストールしただけでは、利用可能なプロキシサービスは使えません。サービスのログインURLしか手元にない場合は、ログインページのURLを直接追加せず、サービスのサブスクリプション画面から設定URLを取得してください。
初期設定では、システムプロキシやVPNを制御しているほかのプログラムを終了し、クライアントのDNS、待ち受けポート、ネットワークスタックの設定はひとまず変更せずにおきます。こうすると、問題が起きた際に確認する設定を絞れます。サブスクリプションURLには認証情報が含まれている場合があります。公開のフォーラムに投稿したり、スクリーンショットにURL全体を表示したりしないでください。不具合を説明するときは、エラーの種類と発生手順を記録します。ログを共有する前に、URL内の機密情報を削除してください。
以降では、画面の名称を一字一句合わせるのではなく、機能を基準に説明します。似た名称の項目があれば、「設定管理」「プロキシの選択」「ネットワーク設定」のどれにあたるか確認してください。用語がわからない場合は用語解説をご覧ください。このページでは初回接続に必要な操作に絞って説明するため、コアのパラメーターをすべて理解しておく必要はありません。
ステップ1:サブスクリプションを追加して設定を有効化する
左側のナビゲーションまたは画面下部のメニューから「設定」を開き、「新規作成」「インポート」、またはサブスクリプションURLの入力欄を探します。URL全体をコピーして貼り付け、先頭や末尾に空白、改行、チャットアプリが付加した句読点がないことを確認してから、ダウンロードまたはインポートを実行します。名前の入力を求められた場合は、見分けやすいローカル名を付けてください。通常、名前はクライアント内で表示するラベルであり、ルール判定には影響しません。処理が終わり、新しい設定が一覧に表示されるまで待ちます。
設定が一覧に表示されたら、現在使用する設定として選択します。カードをクリックする、「使用」を選ぶ、または項目のメニューから「有効化」を実行するのが一般的です。選択状態の表示を確認し、「ダウンロード済み」と「読み込み済み」を混同しないでください。次に「プロキシ」画面を開き、設定で定義されたプロキシグループと、グループ内の選択可能なノードが表示されることを確認します。サブスクリプションによってグループ名は異なるため、「Proxy」という名前の項目を探す必要はありません。
ローカルのYAMLファイルを使う場合は、「ファイルをインポート」またはファイル選択画面から読み込みます。ファイルパスをサブスクリプションURL欄に貼り付けたり、拡張子を変更して形式を変換したりしないでください。ローカル設定は通常、サブスクリプションサービスの更新に合わせて自動変更されません。リモートサブスクリプションは、設定項目のメニューから更新できます。初回はまず手動更新が成功することを確認してから、自動更新の間隔を設定すると、インポートの問題と定期実行の問題を切り分けやすくなります。
インポート後に形式エラーが表示された場合は、まずクライアントのメッセージを確認します。取得した内容がウェブサイトのログインページやエラーページ、ノード一覧だけの場合、ClashのYAMLとして使えるとは限りません。ブラウザーでURLを開けても、形式に互換性があるとは限りません。提供元に、選択したURLが現在のクライアントまたはmihomoコアに対応しているか確認してください。個人用のサブスクリプションを、出所の不明な変換サイトに送信しないでください。ダウンロードがタイムアウトする場合は、通常のネットワーク接続を確認してから、提供元に代替URLがないか確認します。
このステップの完了条件:設定が選択され、プロキシ画面にプロキシグループが表示され、ログに設定の解析失敗が繰り返し記録されていないこと。エラーが続く場合は、まずヘルプセンターのインストール・設定カテゴリを確認してください。ネットワーク関連のスイッチを次々に有効にするのは避けましょう。設定が正常に読み込まれてから、次のステップのモード選択が有効になります。
ステップ2:ルールモードと出口を選択する
設定を読み込んだら、概要画面、プロキシ画面の上部、またはトレイメニューからモードを選び、初回は「ルール」を選択します。このモードでは、設定内のルールに基づいて、接続を直接接続、プロキシグループ、または拒否のいずれにするか決定します。「すべての通信をプロキシ経由にする」スイッチではないため、一部の接続にDIRECTと表示されても、ルールどおりの動作である場合があります。まずはサブスクリプション既定の振り分け設定を使い、テストのためにDIRECTのルールを削除したり、フォールバックルールを移動したりしないでください。
「プロキシ」画面を開き、プロキシの出口となるグループを展開します。手動選択タイプのグループでは、ノードまたはサブグループをクリックします。自動選択タイプでは、ヘルスチェックとグループのアルゴリズムによって出口が決まります。サブスクリプションによっては、サイト分類用のグループがさらに総合選択グループを参照しています。選択中の項目をたどり、最終的に特定のノードとDIRECTのどちらが使われるか確認してください。グループ名は設定作成者が付けたものであり、名前だけから実際の出口を判断できません。
クライアントに接続テスト機能がある場合は、現在のプロキシグループをテストし、接続可能な候補を選びます。テスト結果は、テスト先、タイムアウト時間、その時点のネットワーク状況に左右されます。確認できるのはそのときの疎通状況であり、すべてのサイトにアクセスできることや、ダウンロード速度を保証するものではありません。ノードがタイムアウトした場合は、まず同じグループ内の別のノードを試してください。すべてのノードで失敗する場合は、システムプロキシを何度も切り替えるのではなく、サブスクリプションの有効性とネットワーク接続を確認します。
3つの概念を分けて考える:ルールモードはプロキシの選び方を決め、プロキシグループは選択可能な出口を決めます。システムプロキシまたはTUNは、どのアプリの通信をコアに渡すかを決めます。ノードを選択しただけでは、ブラウザーのリクエストがクライアントに送られるわけではありません。
「グローバル」モードは通常、コアに入ったリクエストをグローバルポリシーに送ります。短時間の比較テストには使えますが、すべてのアプリの通信を自動的に取り込む機能ではありません。「ダイレクト」モードでは、コアに入ったリクエストが宛先へ直接接続されます。初回はルールモードのまま使いましょう。トラブルの切り分けで一時的にグローバルに切り替える場合は、グローバルグループの選択項目も確認し、テスト後にルールモードへ戻してください。グローバルモードとTUNモードは別の問題に対応する機能であり、混同しないでください。
このステップの完了条件:モードがルールになっていて、関連するプロキシグループの出口が明確に選択され、意図せずDIRECTが選ばれていないこと。次に、アプリの通信をクライアントに送ります。ルールの順序、プロトコルの違い、自動選択グループの設計についてはプロトコルとコアのリファレンスをご覧ください。初回接続では、これらを変更する必要はありません。
ステップ3:システムプロキシを有効にして接続する
まず概要画面またはコアの状態を確認し、コアが起動していることを確かめます。コアの起動に失敗している場合は、ログを開いて最初に関連するエラーを確認し、モードの切り替えはひとまず控えてください。コアが正常に動作していたら、「設定」またはトレイメニューから「システムプロキシ」を有効にします。クライアントによっては、概要画面にクイックスイッチがあります。初回の動作確認ではTUNを無効にし、システムプロキシを使うブラウザーからリクエストを送信してください。権限、仮想ネットワークアダプター、ルーティング設定による影響を減らせます。
Windowsでは、有効化後にシステム設定のプロキシ画面でローカルプロキシのアドレスが設定されているか確認できます。macOSでは、現在のネットワークサービスのプロキシ設定を確認してください。実際の設定はクライアントの表示を基準にし、会社や学校のネットワーク設定を直接上書きしないでください。クライアントでスイッチが有効なのにブラウザーの接続記録がない場合は、ブラウザー拡張機能が個別にプロキシを制御していないか、アプリが独自のネットワーク設定を使っていないかも確認します。Linuxではアプリごとに対応状況が異なり、システムプロキシの設定がコマンドラインツールに適用されるとは限りません。
アプリにプロキシを手動で設定する場合は、まずクライアントの設定で待ち受けアドレスとポートを確認します。下表は一般的な設定例であり、すべてのクライアントで初期値が同じとは限りません。画面に異なるポートが表示されている場合は、実際の値を入力してください。待ち受けアドレスがループバックアドレスの場合、主に同じ端末からの接続に使います。端末内のブラウザーで使うために、LANからのアクセスを有効にする必要はありません。
| 設定項目 | 設定例 | 説明 |
|---|---|---|
| ローカルプロキシのアドレス | 127.0.0.1 |
アプリとクライアントが同じ端末で動作する場合に使用 |
| 混合ポート | mixed-port: 7890 |
同じ待ち受けポートでHTTPとSOCKSのプロキシリクエストを受け付けます |
| ルールモード | mode: rule |
コアに入った後、現在の設定ルールに従ってポリシーを選択します |
ログに待ち受けポートが使用中と表示された場合は、クライアントを重複して起動していないか、別のプロキシプログラムがバックグラウンドで動作していないか確認します。使用中のプログラムを終了してコアを再起動してください。別のプログラムを使い続ける必要がある場合は、待ち受けポートを変更します。ポートを変更すると、クライアント管理のシステムプロキシは自動更新される場合がありますが、ポートを手動入力したブラウザー、ターミナル、その他のアプリは個別に変更が必要です。変更しないと、古いポートに接続し続けます。
AndroidとiOSでは通常、接続ボタンをタップして、システムによるVPN構成の作成を許可します。システムの許可ダイアログが、使用中のクライアントから表示されていることを確認してください。デスクトップでは、ブラウザーから正常に接続できた後、対象アプリがシステムプロキシに対応していないことが明らかな場合にTUNを検討します。有効にする前に、クライアントのサービス起動や権限に関する案内を読み、必要な許可を与えてからリクエストを再送してください。最初からほかのVPNを同時に使わないでください。TUNの互換性に問題がある場合は、ヘルプセンターをご覧ください。
このステップの完了条件:コアが正常に動作し、システムプロキシが有効になっていること、またはモバイル端末で必要なシステム許可が完了していること。次にブラウザーから新しいリクエストを送信してください。すでに読み込まれたページを見るだけでは不十分です。既存の長時間接続は、設定を切り替えても出口が変わらない場合があります。
ステップ4:ルールと実際の出口を確認する
まずクライアントの「接続」画面を開き、ブラウザーで新しいタブを開いて信頼できるHTTPSページにアクセスします。接続一覧に対応するドメイン名または宛先アドレスが表示されるか確認し、必要に応じてドメイン名で絞り込んでください。ページが開くことだけでは、プロキシを経由したとは判断できません。キャッシュ、DIRECTルール、ブラウザーの既存接続が結果に影響する場合があります。接続記録は、リクエストがコアに入ったことを確認する最初の手がかりです。
新しい接続の詳細を開き、宛先、適用ルール、プロキシチェーンの順に確認します。適用ルールがプロキシグループを指している場合は、チェーンの末端で想定したノードが使われているか確認してください。DIRECTと表示された場合は、すぐに設定失敗と判断せず、宛先がもともと直接接続の対象ではないか確認します。現在のサブスクリプションのルールでプロキシ経由になるはずの宛先を選び、ルールの説明と照らし合わせて再テストしてください。クライアントによってはプロキシチェーンが階層表示されるため、最終出口を見るには詳細を展開する必要があります。
接続一覧に該当する記録がまったくない場合は、リクエストがまだ処理中か、画面にアクティブな接続だけが表示されているか確認します。短時間の接続はすぐに終了する場合があります。次にページを再読み込みし、接続の絞り込み条件を解除して、システムプロキシのスイッチとブラウザー拡張機能を確認してください。独自のプロキシ設定を使うアプリでは、アドレス、ポート、プロトコルの種類を確認します。通信がクライアントに入っていると確認できるまでは、DNSを変更したりルール全体を入れ替えたりしないでください。どの変更が効果をもたらしたのか判断しにくくなります。
接続記録があるのにリクエストが失敗する場合は、ルールの出口、ノードへの到達性、名前解決の結果に絞って調べます。まず実際に選択されているノードを確認し、同じ時刻のログを確認してください。DNSの名前解決エラーと接続タイムアウトは別の問題です。エラーの種類を記録し、それぞれに対応してください。問題の切り分けでログレベルを一時的に上げる場合は、必要な範囲だけを収集し、調査後は通常のレベルに戻します。アクセス先を含む詳細ログが蓄積し続けないようにしてください。
出口IPアドレスの確認は補助的な検証に使えますが、確認サイトへの通信もルールの対象です。同じブラウザーでも、アクセスする宛先によって出口が異なる場合があります。そのため、確認結果は該当ページの接続記録と合わせて確認してください。ウェブページ上の出口だけから、DNSが想定どおりに解決されたかは判断できません。また、すべてのアプリが同じ経路を使うとも限りません。DNSの名前解決経路、TUNのルーティング、プロトコルの互換性を詳しく調べる場合はプロトコルリファレンスをご覧ください。初回接続ですべての高度な課題を解決する必要はありません。
このステップの完了条件:新しいリクエストが接続記録に表示され、適用されたポリシーが想定どおりで、対象ページが正常に応答すること。これで初期設定は完了です。サブスクリプションの更新後にグループ名やノードが変わった場合は、選択項目を再確認してください。利用を終了するときは、クライアントを終了する前にシステムプロキシを無効にするかVPNを切断し、閉じたローカルポートにアプリがリクエストを送り続けないようにします。
日常の使い方:確認手順を決めておく
普段の接続では、毎回すべての手順をやり直す必要はありません。まず現在の設定が有効か確認し、次にプロキシグループの出口を確認してから、通信をクライアントに取り込む方法を有効にします。問題が起きた場合も、「設定が読み込まれているか」「モードが正しいか」「リクエストが入っているか」「出口が使えるか」の順に確認してください。一度に変更する項目を1つにし、リクエストを再送して記録を確認すると、ノード、DNS、TUNの設定を同時に変更するより原因を特定しやすくなります。
サブスクリプションを更新すると、リモート設定のルールやノードが置き換わる場合があります。個別の変更には、クライアントのオーバーライド機能やマージ機能を優先して使い、更新後に実際の設定を確認してください。さらに学ぶ場合は、用語解説でプロキシグループやルールの種類を確認し、ヘルプセンターで具体的なエラーを調べ、プロトコルとコアのリファレンスでプロトコルの互換性や用途を比較できます。基本的な使い方のために、すべての高度な設定を事前に変更する必要はありません。