OSに合ったクライアントを選び、サブスクリプションの読み込みから始めましょう。ルール分岐とmihomoコアの設定方法も解説します。
まず設定が読み込めることを確認し、次に通信をどのようにコアへ取り込み、どのルールで出口を選ぶかを決めます。以下は一般的な設定画面の例で、実際のサービスには接続しません。メニュー名はクライアントによって多少異なります。
リモート設定
表示中のURLはサンプルです。サブスクリプションには使えません。実際の設定はクライアントで行ってください。
クライアントの「設定」または「サブスクリプション」画面に、プロバイダーから案内されたURLを貼り付けてダウンロードし、該当する設定を選択します。Clashの完全なYAML設定には、ノード、グループ、ルールをまとめて記述できます。一方、単一ノードのリンクに含まれるのは通常接続情報だけで、ルール分岐全体の代わりにはなりません。読み込みに失敗したら、URLの有効期限と応答内容がYAMLかどうかを確認し、次にコアが対象プロトコルに対応しているか調べましょう。リモート設定を更新すると手動変更が上書きされることがあります。長期的に使うルールは、クライアントの上書き設定やマージ機能に記述してください。サブスクリプションURLにはアクセス権限に関する情報が含まれるため、公開しないでください。
モードの例 · ルール
mixed-portモードが決めるのはコアに入った後のルーティングであり、アプリがプロキシを使うかどうかではありません。
「ルール」は設定に従って通信先を判定するモードで、直結とプロキシを使い分けたい場合に適しています。「グローバル」はコアに入った通信をグローバルポリシーに振り分け、「直結」は接続先へそのまま通信します。通常はプロキシ画面またはメニューバーのメニューでモードを選び、グループ設定で出口を指定します。グローバルモードにしても、端末上のすべてのアプリが自動的に対象になるわけではありません。システムプロキシに従わないアプリはコアを経由しないことがあります。問題の切り分けでは、一時的にグローバルモードへ切り替えて結果を比較し、確認後にルールモードへ戻すと、ルールの問題とノード接続の問題を分けて調べられます。
上から順に照合 · 設定構文の例
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,PROXYPROXYは設定内で定義済みのポリシーグループに対応させてください。
ルール画面では、読み込み後の照合順を確認できます。編集場所は設定ファイル、ルールの上書き、サブスクリプションのマージ画面など、クライアントによって異なります。DOMAIN-SUFFIXはドメインの末尾で照合し、GEOIPはIPアドレスの地域情報をもとに判定します。MATCHは通常、最後のフォールバックとして置きます。ルールは上から順に評価され、先に一致すると後続のより具体的なルールには進みません。そのため、順序と適用先のどちらも重要です。グローバルモードと違い、ルール分岐ならローカルサービスへの直結を維持できますが、DNS、ルールデータ、グループ名の整合性が必要です。変更後は接続画面で適用されたルールを確認しましょう。
mixedauto-route利用できるstackやルーティング設定は、コアとOSによって異なります。
対応するデスクトップクライアントの設定でTUNを有効にし、案内に従ってサービスをインストールするか必要な権限を許可すると、仮想ネットワークインターフェース経由でルーティング対象の通信を受け取れるようになります。システムプロキシ設定を参照しないアプリにも使える点が、ブラウザーやシステムプロキシの入口だけを変更する方法との違いです。有効にする前に通常のプロキシ接続を確認し、自動ルート設定、DNSの取り込み、ほかのVPNとの競合も確認してください。system、gvisor、mixedなどのstack対応状況はプラットフォームによって異なるため、画面例をそのまま設定に使わないでください。TUNで通信を取り込める範囲は広がりますが、期限切れのサブスクリプション、誤った認証情報、利用できないノードは解決しません。
ここでは実際の接続履歴を表示・収集しません。
ログ画面では、まずinfoレベルで設定の読み込み、DNSクエリ、接続エラーを確認します。さらに詳しく調べる必要がある場合のみ、一時的にdebugへ上げてください。接続画面では、接続先のドメイン、適用ルール、実際の出口を確認できます。両方を見比べるほうが、ノードを何度も切り替えるより効率的です。接続記録がない場合は、まずシステムプロキシやTUNの入口を確認します。認証エラーが出る場合はノード情報とサブスクリプションの状態を、特定のドメインだけ失敗する場合はDNSとルール順を確認してください。調査情報を共有する際は、サブスクリプションURL、サーバーアドレス、認証情報を隠し、調査後は通常のログレベルに戻しましょう。
設定ファイル、通信の入口、ルーティングポリシーはそれぞれ別の階層です。サブスクリプションは「利用できるノードとルール」を用意し、システムプロキシやTUNは「どのアプリの通信をコアに取り込むか」を決めます。プロキシモードとグループ設定は「取り込んだ通信をどの出口へ送るか」を決めます。この順に設定すれば、問題が起きても段階ごとに切り分けられ、複数の設定を一度に変える必要がありません。
手順に沿って初期設定を完了する →GUIクライアントはサブスクリプション管理、メニュー、システム連携を担い、コアはプロトコル接続と通信の振り分けを担います。まず端末に合ったインストーラーを選び、必要なプロトコルと機能を確認しましょう。画面が似ていても、コアの機能が同じとは限りません。
まずClash Plusを確認し、画面の使い勝手に応じてClash Verge Rev、FlClash、Clash Nyanpasuも検討できます。ダウンロード前にOSとCPUアーキテクチャを確認してください。GUIが起動しても、TUNに必要なサービスが正しくインストールされているとは限りません。
普段のブラウジングでは、まずシステムプロキシを有効にし、サブスクリプションとルールを確認してからTUNを設定するとよいでしょう。クライアントを終了した後にブラウザーがインターネットへ接続できない場合は、システムプロキシ設定が残っていないか確認してください。基本の通信経路を復旧する前にノードを次々と変更するのは避けましょう。開発が終了したClash for Windowsはダウンロードページのアーカイブに掲載しています。移行前にローカル設定をバックアップし、新しいプロトコル項目の解析を古いコアに依存しないようにしてください。
ダウンロードへMacBookなどのMacでは、Apple SiliconとIntelを確認してから対応するインストーラーを選びます。Clash Plus、Clash Verge Rev、FlClashが選択肢です。対応するOSの範囲は、ダウンロードページとアプリの説明を確認してください。
初回起動時は、システム権限やネットワーク機能拡張の確認に注意してください。通常、システムプロキシとTUNを同時に変更する必要はありません。ターミナルのツールでプロキシを使う場合、そのツールがシステムプロキシを参照するか確認し、必要ならコマンドごとにプロキシアドレスを指定します。開発が終了したClashX Metaはアーカイブ情報としてのみ参照してください。名前にMetaが含まれていても、現在のmihomoの機能すべてに対応しているとは限りません。
ダウンロードへClash Plus、Clash Meta for Android、FlClash、Surfboardを比較できます。最近のスマートフォンの多くはARM64ですが、実際の端末のアーキテクチャに合ったものを選んでください。対応するサブスクリプション形式はアプリによって異なるため、ファイルの拡張子だけで互換性を判断することはできません。
モバイル端末では通常、システムのVPN機能を使って通信を取り込みます。初回起動時に許可を確認してください。同じ端末で動作するほかのVPNと併用できない場合があります。画面ロック後に接続が切れる場合は、バッテリー管理とバックグラウンド実行の権限を確認してから、ノードを調べましょう。アプリ別の振り分け、LAN内通信の除外、DNSの設定場所はクライアントによって異なります。デスクトップの設定を読み込んだ場合も、モバイル端末で実際に取り込まれる通信の範囲を確認してください。
ダウンロードへiPhoneやiPadでは、ダウンロードページからClash PlusのApp Storeページを開けます。プロジェクトの公式サイトはclashplus.ioです。インストール前にストアに記載されたシステム要件を確認し、利用時はアプリの案内に従ってVPN構成を追加してください。
デスクトップのシステムプロキシ切り替えと、モバイル端末のVPN許可は別の設定方法です。サブスクリプションを読み込んだ後、グループ、ルール、アプリが対応する設定項目を確認し、接続状態と出口が想定どおりか確かめましょう。Clash形式に対応しているからといって、デスクトップ版の全機能が使えるとは限りません。バックグラウンド動作、ネットワーク切り替え、システム拡張の挙動は、iOSの仕組みとアプリの実装に左右されます。
ダウンロードへデスクトップ環境ではClash Verge RevとFlClashを比較し、ディストリビューションに合ったパッケージ形式を選ぶとよいでしょう。サーバー、ルーター、自前のサービス環境では、ダウンロードページのMihomoコア欄を確認し、CPUアーキテクチャと導入方法に合ったファイルを選んでください。コア単体には、GUIでサブスクリプションを管理する機能はありません。
デスクトップのシステムプロキシがアプリに適用されるかは、デスクトップ環境とアプリの実装によって異なります。コマンドラインのプログラムでも個別設定が必要な場合があります。コアを導入する前に、実行ユーザー、設定ディレクトリ、ログの保存先を決めてください。TUNを有効にしたりルートを変更したりする場合は、必要な権限を設定します。リモートサーバーのルートを変更する際は復旧手段を確保し、外部コントローラーの接続先はlocalhostまたは保護されたネットワークに限定してください。インターネットへ直接公開してはいけません。
ダウンロードへインストーラー、システム要件、アーカイブ状況はダウンロードセンターにまとめています。クライアントの更新とコアの更新を混同しないよう、トップページには個別のバージョンを掲載していません。
すべてのクライアントを見る →Clashは、歴史的なつながりを持つコアやクライアントのエコシステム名です。同じ名称を持つアプリがすべて同一プロジェクトから公開されているわけではありません。このサイトではダウンロード情報と日本語の解説を提供します。各ソフトの機能、ライセンス、メンテナンス状況は、それぞれのプロジェクトの公開情報をご確認ください。
オリジナルClashは、ノード、ポリシーグループ、ルーティングルールをYAMLで記述する方式を広め、多くのGUIクライアントがこの設定構造を引き継いでいます。オリジナルプロジェクトの公開メンテナンス終了後も、エコシステム内のフォークは開発を続けました。Clash.Metaは後にmihomoという名称で開発を継続しています。そのため、チュートリアルで使われるMetaとmihomoには歴史的なつながりがありますが、Clashの名を冠するすべてのアプリと同一視することはできません。古い解説を読むときは、コア、GUIクライアント、サブスクリプション形式のどれを指しているか確認しましょう。
クライアントは通常、コアを内蔵または呼び出し、設定のダウンロード、システムプロキシ、サービス管理、接続状況の表示などを提供します。画面を変えてもプロトコル対応が変わるとは限らず、コアを入れ替えても対応する項目が画面に自動で追加されるとは限りません。一般ユーザーは、まずメンテナンス状況が明確なクライアントを選び、使用コアと機能の設定場所を確認するとよいでしょう。見慣れない項目があれば、インデントを何度も変えて古いコアに新しい構文を読み込ませようとせず、該当するコアのドキュメントを参照してください。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICでは接続パラメーターや伝送方式が異なります。プロトコル名だけで実際の速度を判断することはできません。回線品質、サーバー設定、パケットロス、端末の性能も結果に影響します。特にUDPベースの方式では、利用するネットワークが該当通信を許可している必要があります。クライアントが設定項目を認識しても、接続に必要な条件が整っているとは限りません。選ぶ際は、まずサービス提供元の指定パラメーターを満たし、そのうえでモバイル回線の切り替え、消費電力、メンテナンスの手間を検討しましょう。
Clash YAMLで使われるノード、グループ、ルールの基本項目には互換性がありますが、新しいプロトコル、DNSオプション、ルールデータ形式を古いコアが認識するとは限りません。完全な設定、ノードプロバイダー、単一ノードのリンクはそれぞれ別のものです。サブスクリプションを変換すると、クライアント固有の項目が失われたり、ルールとグループ名の対応が崩れたりすることがあります。読み込みエラーが発生したら、ログを見て構文解析、項目の対応状況、リソースのダウンロードのどこに問題があるか確認してください。構文が通ることは、接続確認の第一歩にすぎません。
長く使えるプロジェクトかを判断するには、公開ソースコード、リリースノート、課題のやり取り、機能変更に伴うドキュメント更新を確認しましょう。クライアントと内蔵コアの更新頻度は一致するとは限らず、ルールデータベースも別のリソースです。GUIアプリ、コア、サブスクリプションの更新はそれぞれ異なる問題に対応します。どれか一つの更新が成功しても、すべてが最新になったわけではありません。ダウンロードページでは現行の選択肢とメンテナンス終了後のアーカイブを区別しています。アーカイブは移行時や過去の設定を確認する際にご利用ください。
更新前に、動作確認済みの設定と上書き設定を保存し、使用中のプロキシモード、DNS方式、TUNの状態を記録しておきましょう。更新後は設定を再読み込みし、よく使うアプリ、ローカルサービス、出口の選択を確認してください。問題が起きた場合は、すべてを初期設定に戻すのではなく、変更履歴と照らして一つずつ確認します。不具合を報告する際は、問題を特定しやすくするため、OS、クライアント名、使用コア、機密情報を除いたエラー情報を添えてください。「接続できない」とだけ伝えるより有効です。
ノードの遅延テストで分かるのは、指定されたテスト先への接続結果です。すべてのサイトやアプリが同じ経路を使うとは限りません。設定が反映されているか確認するには、クライアントの接続履歴、適用ルール、実際の出口を確認し、アプリがシステムプロキシを参照しているか、TUNのルートで取り込まれているかも調べます。一部のアプリだけに問題がある場合は、通信の入口とアプリ側のプロキシ設定を優先して確認します。一部のドメインだけ失敗する場合は、DNSとルールの照合を調べると、関係のない設定変更を減らせます。
Fake-IP、ポリシーグループ、ルールプロバイダー、UWPループバックなどの用語が分からない場合は、まず用語集で基本を確認してからチュートリアルに進みましょう。技術リファレンスでは、プロトコルの仕組み、コアの関係、サブスクリプションの互換性を比較できます。クライアントやサーバーの構成を変更する前にご覧ください。このサイトの画面例は設定同士の関係を説明するもので、すべてのOSにおける特定クライアントの全画面を示すものではありません。インストール後は実際の接続も確認してください。
まず初回接続を完了し、その後で発生した問題に応じて詳しく調べましょう。ポリシーグループの選択、ルールデータベースの更新、ノードのタイムアウトはそれぞれ別の階層です。問題の発生箇所を特定してから、該当する設定を変更してください。
3種類の自動グループについて、速度測定の方法、切り替え条件、interval・toleranceの設定を解説。普段のブラウジング、安定性重視、複数回線の分散という用途別に設定例を紹介します。
ポリシーグループの解説を読む →サブスクリプションの期限、システム時刻のずれ、ポートの競合、ログのエラー内容を外側から順に確認し、ノードのタイムアウトを切り分けます。項目ごとの対処法も紹介します。
タイムアウトの確認手順を見る →GeoIP・GeoSiteのデータファイルの役割と主な入手先を解説し、geox-urlと自動更新間隔を設定。GEOIP・GEOSITEルールの正しい書き方も紹介します。
ルールデータの更新方法を見る →