QUICKSTART / PROFILE → RULE → PROXY
Clashのサブスクリプション追加とプロキシ設定
初回設定の所要時間は約10分です。まず設定を正常に動作させ、ブラウザーの通信が想定した出口を経由することを確認します。実際の所要時間はサブスクリプションのダウンロード、システムの許可、ネットワーク環境によって異なります。
事前準備
開始前に、クライアントがインストール済みで、メイン画面を開けることを確認します。利用権限のあるサブスクリプションURL、または完全なClash YAML設定ファイルを用意してください。クライアントは設定の読み込み、コアの実行、通信経路の管理を行うもので、それ自体が利用可能なプロキシサービスではありません。インストーラーだけで設定がなければ、通常は接続できません。
他のプロキシクライアントを一時的に終了し、ブラウザーのプロキシ拡張機能、システムVPN、手動プロキシが有効か記録しておきます。初回設定では通信を取り込む方法を一つに絞ってください。そうしないと、ブラウザーが別の設定を経由し、クライアントのスイッチと実際の接続結果が一致しないことがあります。会社、学校、管理対象のデバイスでは、デバイスやネットワークの利用規則に従い、組織管理のプロキシ設定を変更しないでください。
サブスクリプションURLにはアカウントを識別できる情報が含まれる場合があるため、認証情報と同様に扱ってください。URL全体を公開フォーラムに貼り付けたり、スクリーンショットに写したり、オンラインの変換サイトに入力したりしないでください。このガイドではクライアントの操作のみを説明し、サブスクリプション内容の提出は求めません。形式に問題がある場合は、提供元の管理画面でClashまたはmihomoと明記されたエクスポート方法を確認してください。
01 / サブスクリプションを追加して設定を有効化
左側の「設定」画面を開き、新規追加、インポート、またはリモート設定の項目を探します。サブスクリプションURLをURL入力欄に貼り付けてください。名前を入力できる場合は、「日常用」など用途が分かる名前を付けます。名前はローカルで管理するためのもので、サブスクリプションURLの代わりにはならず、プロキシ出口も決まりません。URLの前後に空白や改行、チャットツールからコピーした句読点がないことを確認してからインポートします。
送信後はダウンロードが完了するまで待ち、連続してボタンを押さないでください。通常は設定一覧に項目が追加され、名前、取得元、更新日時などを確認できます。バージョンによっては、リモート設定の登録後に内容を別途ダウンロードします。更新ボタンが表示されている場合は一度実行し、エラーがないことを確認してください。一覧に追加されただけでは、コアがその設定を使用しているとは限りません。次に有効化が必要です。
追加した項目を選択し、「適用」「有効化」「現在の設定にする」などの操作を行います。現在の設定を示すマークがその項目に移ったことを確認してから、「プロキシ」画面を開き、設定で定義されたプロキシグループが表示されるか確認します。プロキシ画面が空の場合は、設定画面に戻って項目を選び間違えていないか確認し、ログで解析エラーや設定読み込みエラーを調べてください。設定の解析エラーをシステムプロキシの切り替えで解決しようとしないでください。これらは別の段階の問題です。
ローカルのYAMLファイルを使う
完全な設定ファイルがある場合は、ローカルファイルのインポートから拡張子が.yamlまたは.ymlのファイルを選び、同様に有効化してください。拡張子をYAMLに変えただけで形式が変換されるわけではありません。Webページの本文、QRコードの画像、一般的なノード一覧は完全な設定ではありません。初回はファイルを手動で編集する必要はありません。まず提供元の互換性が確認された設定で、正常に動作する状態を作りましょう。
ローカルファイルをインポートすると、クライアントがコピーを保存することがあります。元のファイルを後から編集しても、インポート済みの設定に自動で反映されるとは限りません。現在のクライアントでの編集や再インポートの動作を確認してください。リモートサブスクリプションは更新操作で内容を再取得するため、管理方法が異なります。設定項目と実際に実行されるファイルの違いを確認するには、用語集のProfileと設定の説明をご覧ください。
追加に失敗した場合は、この段階で確認
ダウンロードに失敗した場合は、URLの期限が切れていないか、現在のネットワークからサブスクリプションサービスにアクセスできるか確認します。解析に失敗する場合は、取得した内容がClash YAML形式であることを確認してください。アカウントのログインページ、サービスのエラーページ、Base64形式のノード一覧は、URLだけで完全な設定として使えるものではありません。未確認の内容を無作為なオンライン変換サービスに入力しないでください。変換が必要な場合は、提供元に対応する方法を確認します。
初回のインポートに成功したら、まずは手動更新のままにすることをおすすめします。定期更新が必要になったら、リモート設定に適切な更新間隔を設定し、更新後に現在の設定とプロキシグループの選択が想定どおりか確認してください。ここまでで、有効化でき、プロキシグループが表示される設定が用意できたはずです。次に通信の振り分け方を決めます。
02 / プロキシモードとプロキシグループを選択
「ダッシュボード」または「プロキシ」画面で動作モードを探し、初回は「ルール」に設定します。ルールモードでは、読み込み済み設定のrulesを上から順に照合し、該当した通信を直結、プロキシ、またはプロキシグループに渡します。すべての通信が同じ出口を通るわけではなく、有効にするだけで不足しているルールが補われるわけでもありません。実際の動作は、読み込まれている設定によって決まります。
画面に「グローバル」と「直結」の選択肢がある場合は、それぞれの用途を区別してください。グローバルモードでは通常、通信をまとめてグローバル用のプロキシ選択に渡します。ルールによる振り分けが結果に影響しているか一時的に判断する際に使えますが、有効な出口の選択は必要です。直結モードは、直接接続に戻す場合や比較テストに使います。初回接続が確認できてから他のモードを試してください。モード、設定、出口を同時に変えると、問題を切り分ける比較対象が分からなくなります。
プロキシ画面で出口を確認
「プロキシ」画面を開き、現在の設定にある選択式のプロキシグループを展開します。グループ名は設定の作成者が決めるため、PROXYとは限らず、ガイドのスクリーンショットと同じとも限りません。日常の通信に使うメインの選択グループを見つけ、サブスクリプションで利用できるプロキシ出口を選びます。設定に自動選択グループがある場合は、メインの選択グループからその自動選択グループを指定してもかまいません。自動切り替えの有無はグループの種類とパラメーターで決まり、名前に「自動」が含まれているかどうかでは決まりません。
ここでは2つの関係を区別してください。動作モードはルールを使うかどうかを決め、プロキシグループはルールに一致した通信をどの出口に渡すかを決めます。プロキシ出口を選んでも、メインのプロキシグループがDIRECTを指していれば、通信は直結する場合があります。逆に、グループを正しく選んでいても、テスト対象のドメインが先にあるルールでDIRECTに振り分けられれば、そのプロキシは経由しません。すぐにYAMLを変更せず、グループ内の選択状態を確認し、設定本来の振り分けルールを維持してください。
プロキシグループに選択肢がない場合は、接続を続けず設定の段階に戻ってください。サブスクリプションの内容が不完全、プロキシプロバイダーの更新に失敗、ルールが参照するグループと実際のグループが一致していない、といった原因が考えられます。フィールドの階層やグループ間の参照については、YAMLガイドをご覧ください。この段階が完了したら、ルールモードと明確な出口の選択を維持して、システムに通信を取り込む設定に進みます。
03 / コアを起動してシステムプロキシを有効化
ダッシュボードまたは設定画面に戻り、コアが実行中であることを確認します。設定を適用するとコアが自動起動するバージョンもあれば、独立した起動操作が必要なバージョンもあります。ログに設定エラーが続いている場合は、まず設定を修正してください。ポートが使用中と表示された場合は、別のインスタンスや他のプロキシプログラムが動作していないか確認します。アプリのウィンドウが開くことと、コアがローカルポートで正常に待ち受けていることは別です。
初回設定ではクライアント既定の待ち受けポートをそのまま使い、ガイドに合わせるためだけに変更しないでください。ログには、以下のような待ち受けメッセージが表示されることがあります。例に示すポートはよく使われる設定の一例であり、すべての環境で同じ値にする必要はありません。実際に使われているポートは、現在の設定とローカルのログで確認してください。
level=info msg="Mixed(http+socks) proxy listening at: 127.0.0.1:7890"
コアの起動を確認したら、「システムプロキシ」を有効にします。このスイッチは通常、OSのプロキシアドレスをクライアントのローカル待ち受け先に設定し、システムプロキシに従うアプリで使えるようにします。システムから許可を求められた場合は、現在のクライアントからの要求であることを確認し、画面の案内に従ってください。有効化後はクライアントを起動したままにし、すぐにウィンドウやバックグラウンドプロセスを終了しないでください。
まずブラウザーで初回接続を確認
システムプロキシに従うブラウザーを開き、新しいタブでアクセスします。システム設定を上書きしないよう、ブラウザーで別途設定したプロキシ拡張機能は一時的に無効にしてください。ブラウザーによっては独自のネットワークプロキシ設定があり、ターミナルツールでは個別にプロキシパラメーターの設定が必要な場合もあります。こうしたアプリがシステムのスイッチに従わなくても、クライアントが動作していないとは限りません。初回の確認には、設定が最も簡単なブラウザーを使ってください。
Windowsでは「設定」のネットワークとプロキシの画面で手動プロキシの状態を確認できます。macOSでは、現在のネットワークサービスの詳細設定でプロキシを確認してください。Linuxではデスクトップ環境のネットワークプロキシ設定も確認します。ディストリビューションやデスクトップセッションによって、システムプロキシの対応状況は異なる場合があります。クライアントで設定の書き込みに失敗したと表示された場合は、スイッチの見た目だけで判断せず、システム設定で実際のアドレスとポートを確認してください。
TUNはまだ有効にしない
このガイドでは、まずシステムプロキシを使ってブラウザーの通信を確認します。初回からTUNを有効にする必要はありません。TUNは仮想ネットワークインターフェースを通じて、より多くの通信を処理する仕組みです。権限、ルーティング、DNSなど追加の条件が関わります。システムプロキシと同じものではなく、あらゆる問題を解決するスイッチでもありません。システムプロキシに従わないアプリの通信も取り込みたい場合は、TUNとシステムプロキシの用語解説を確認し、クライアントの要件に従ってサービスや権限を設定してください。
スマートフォンではこの段階で、通常「接続」をタップしてシステムによるVPN接続を許可します。画面にVPNの状態を示すアイコンが表示されることがあります。この表示から分かるのは通信の取り込みが始まったことだけで、サブスクリプションの出口が利用できることまでは確認できません。どのプラットフォームでも、次の段階で実際の通信とクライアントの記録を使って確認してください。
04 / ルールと接続の動作を確認
クライアントを起動したまま、ブラウザーで普段から安定して開けるHTTPSページに再度アクセスします。同時にクライアントの「接続」画面を開き、ページを再読み込みしたときに対応するドメインや宛先の記録が表示されるか確認してください。ルールや経路の詳細が表示される場合は記録を展開し、適用されたルールと最終的に使われたプロキシグループを確認します。ページが開くことは最初の確認結果にすぎません。想定どおりに振り分けられたかどうかは、記録された経路で判断します。
用途が明確な対象を2つ選んで比較します。1つは現在の設定で直結する想定の対象、もう1つはプロキシ経由になる想定の対象です。結果を判断する前に、ルール定義または接続の詳細を確認してください。ページの内容や地理的な印象だけで通信経路を推測することはできません。どちらのアクセスもDIRECTと表示される場合は、動作モードと適用ルールを確認します。選択したプロキシグループを経由しているのにページが開かない場合は、その出口と接続先サービスの稼働状況を確認してください。
接続記録がない場合は通信の取り込み経路を確認
まずブラウザーが以前の長時間接続を使い続けていないか確認し、テスト用タブを閉じてから開き直します。それでも該当する記録がない場合は、システム設定にプロキシが実際に反映されているか、ブラウザーに独自のプロキシ設定が有効になっていないか確認してください。画面によっては現在アクティブな接続だけが表示されるため、短時間のリクエストはすぐ消えることがあります。必要に応じてログも確認してください。記録を残すためだけに、すぐルールやDNSを変更しないでください。
ページが開かない場合は、「設定が有効 → コアが起動 → ローカルポートが待ち受け中 → システムプロキシが反映済み → プロキシグループの出口を選択済み」の順に確認します。一度に変更する条件は1つにして、同じページへ再度アクセスしてください。これにより、ローカルで通信を取り込めない問題と出口への接続問題を区別でき、複数の設定を一度に変更して原因が分からなくなるのを防げます。
ログは失敗している段階の特定に使う
「ログ」画面を開き、直前のテスト時刻付近にあるエラーや警告を優先して確認します。設定の解析エラーはインポート段階に戻って確認し、待ち受けエラーはポートの使用状況を調べます。接続タイムアウトは宛先と選択中の出口を照らし合わせ、名前解決エラーはDNSの経路を確認してください。ログを共有する前に、サブスクリプションURL、アカウント情報などの機密情報を削除します。DNSの詳細なフィールドやルールの書き方はYAML設定リファレンスをご覧ください。初回の動作確認で項目を一つずつ書き換える必要はありません。
外部サイトで出口IPアドレスを確認する場合、そのサイトへの1回の通信結果しか分からず、すべてのアプリが同じ経路を使う証明にはならない点に注意してください。ルールモードでは、宛先ごとに異なる出口を使うのが通常です。設定の読み込みに成功し、テスト通信がクライアントに届き、想定したルールが適用され、対象ページに正常にアクセスできることを完了の目安にしてください。
接続を停止して次回起動に備える
テスト後に使用を停止する場合は、まずシステムプロキシを無効にしてからクライアントを終了してください。TUNを使った場合は、対応する通信取り込みスイッチもオフにし、クライアントの手順に従ってサービスを停止します。プロセスを強制終了すると、システムにローカルポートを指すプロキシ設定が残る場合があります。その状態でブラウザーがインターネットに接続できない場合は、すぐにソフトを再インストールせず、まずシステムプロキシ設定を元に戻してください。
次回起動時は、想定した設定が現在の設定になっていること、リモートサブスクリプションを正常に更新できることを確認し、モード、プロキシグループ、システムプロキシの状態もチェックしてください。まずは今回動作確認できた設定を維持し、スタートアップ起動、自動での通信取り込み、複雑な上書き設定を同時に追加しないでください。カスタムルールや複数設定の切り替え、上書き設定が必要になったら、YAMLガイドで一つずつ調整し、変更のたびにこのガイドの手順で再確認してください。