Clash Meta · オープンソースのプロキシコア
プラットフォーム別にクライアントを選び、ルールによる振り分け、TUNモード、DNS設定を確認できます。
まず通信の入口を把握し、そのうえで出口を決めましょう。システムプロキシとTUNは通信をコアに取り込み、ルールとプロキシグループは出口を選択し、DNSはドメイン名を解決します。以下の画面は設定項目の例です。実際の表示名は使用するクライアントによって異なります。
RULES
ルールモードでは、設定順にドメインや宛先アドレスなどの条件を照合し、一致したルールに指定されたポリシーを適用します。グローバルモードではグローバルプロキシグループを使い、DIRECTモードではプロキシを経由せず接続します。普段はサブスクリプションに含まれるルールをそのまま使い、接続ログでどのルールに一致したかを確認するのがおすすめです。特定サイトの接続先を変える場合は、具体的なルールを汎用ルールより前に置き、指定したポリシー名が存在することも確認してください。モードの切り替えで変わるのは出口の選択です。システムプロキシが有効になるわけではなく、ノードの接続確認にもなりません。
詳しく見る →TUN
TUNは仮想ネットワークインターフェースで通信を受け取るため、システムプロキシ設定を参照しないアプリにも適しています。有効にする前に、クライアントが必要とする権限を許可し、別のVPNがデフォルトルートを制御していないことを確認してください。自動ルートはTUNに通信を流す経路を設定します。厳格なルート制御の動作はOSによって異なるため、スイッチ名だけで影響を判断できません。まずシステムプロキシで設定が機能することを確認してから、TUNを個別に有効にしましょう。LAN接続やリモート接続に問題が起きた場合は、ルートと除外アドレスを確認してください。
詳しく見る →DNS
Fake-IPはドメイン名に対応する仮想アドレスを返し、以降の接続でコアが元のドメイン名を識別できるようにします。これはリモートサーバーの実アドレスではなく、Webサイトの内容がローカルから配信されるという意味でもありません。設定時はDNSサーバー、通信を取り込む方法、アプリ独自のDNS動作をあわせて確認しましょう。enhanced-modeを変更するだけでは、すべての問い合わせがコアに届くとは限りません。実アドレスを必要とするLANサービスには、fake-ip-filterの利用を検討してください。トラブル時は、名前解決の失敗と接続の失敗を切り分け、設定全体を何度も入れ替えるのは避けましょう。
詳しく見る →PROFILES
クライアントには、サブスクリプションURLまたはローカルファイルから設定を読み込めます。ただし、ダウンロードに成功しても設定が有効になったとは限りません。追加後は対象の設定を選択し、解析時の警告を確認してから、プロキシグループに利用可能な選択肢があるか確認しましょう。設定一式を含むサブスクリプションと、ノードだけを提供するプロキシリストは用途が異なり、読み込み先をそのまま置き換えることはできません。自動更新の間隔はクライアントまたはproviderの設定によって決まり、図の数値は項目例です。個別ルールはクライアントのオーバーライド機能で保存すると、次回更新時に手動変更が上書きされるのを防げます。
詳しく見る →すべてのスイッチを一度に変更する必要はありません。該当する症状を選び、まず関連する項目を確認してから、詳しいガイドに進みましょう。
まずルールモードになっていることを確認し、接続ログでドメイン、適用ルール、最終的なポリシーの経路を確認します。ルールが一致すると、後続の同種ルールは検索されません。そのため、前にある広い条件が後ろの具体的な条件に優先する場合があります。変更前の結果を記録し、変更後は新しく接続し直してください。既存の接続を新しいルールの検証結果と誤認しないようにしましょう。
ルールの順序とプロキシグループを見る →まず、アプリがシステムプロキシを参照するか確認してください。ブラウザーはプロキシ経由なのにゲームやコマンドラインアプリが直接接続する場合、原因はルールではなく通信の取り込み口にあるかもしれません。TUNを使う場合は、サービスやネットワークに必要な権限を許可し、ほかのVPNを一時停止します。有効にした後は、接続ログに対象アプリの通信が表示されるか確認し、そのうえで出口のポリシーを確認してください。
TUNとルート設定を見る →まず、失敗したドメイン名とエラーメッセージを記録し、名前解決エラー、接続タイムアウト、証明書エラーを切り分けます。クライアントのDNSが有効か、上流のDNSサーバーに接続できるか、ブラウザーが独自の暗号化DNSを使っていないかを確認してください。Fake-IP利用時に仮想アドレスが表示されるのは想定どおりです。実際の通信がコアに取り込まれているかをもとに原因を判断しましょう。
DNS動作モードを見る →URLにアクセスできない、返された内容の形式が違う、設定の解析に失敗する、といった問題を切り分けましょう。ログイン画面やエラーページをYAMLとして保存して使わないでください。以前の設定が使える場合は残したうえで、サブスクリプションURL、ネットワーク接続、クライアントのログを確認します。調査情報を他の人に共有する前に、URLに含まれるアクセス用認証情報や個人アカウント情報を削除してください。
サブスクリプションと設定管理を見る →GUIクライアントは設定管理、権限の申請、実行制御を担い、コアはネットワーク通信を処理します。初めて使う場合は、各OS向けクライアントから始めるのがおすすめです。独立したコアを先にインストールする必要はありません。以下のリンクからダウンロードセンターの各プラットフォームタブに移動し、インストール方法やCPUアーキテクチャを比較できます。
Clash Plus、Clash Verge Rev、FlClashなどのGUIクライアントから選べます。インストール前にシステム情報でCPUアーキテクチャを確認してください。インストール後は設定を追加してからシステムプロキシを有効にします。TUNを使う場合は、クライアントの説明に従ってサービスをインストールし、必要な権限を許可してください。以前のクライアントから設定を移行する際は、一度に進めず段階的に行い、複数のプロキシアプリが同じ待ち受けポートを取り合わないようにしましょう。
ダウンロードページへ →まずAppleシリコン搭載モデルとIntel搭載モデルを確認し、対応するインストーラーを選んでください。初回起動時にセキュリティ警告が表示された場合は、アプリの入手元を確認してからシステム設定の案内に従います。システムプロキシ、バックグラウンドサービス、TUNの権限はそれぞれ別の設定です。アプリが起動しているだけでプロキシが有効とは限りません。アップデート後も必要な権限と有効な設定を確認してください。
ダウンロードページへ →機能に応じてClash Plus、Clash Meta for Android、FlClash、Surfboardから選べます。対応する設定形式はクライアントごとに異なります。初めて接続するときは、通常、システムのVPN権限を許可する必要があります。バックグラウンドで切断される場合は、省電力設定とバックグラウンド実行の権限を確認してください。アプリごとのプロキシ設定では、対象アプリが選択対象に含まれるのか、除外されるのかも確認しましょう。
ダウンロードページへ →ダウンロードセンターではClash PlusのApp Storeページを案内しています。公式サイトはclashplus.ioです。インストール後、アプリの案内に従って設定を追加し、VPN権限を許可してからポリシーを選んで接続してください。デスクトップ向け設定のプロセスルール、ファイルパス、システムルートの項目がモバイルでもそのまま使えるとは限りません。アプリが実際に対応している範囲を確認してください。
ダウンロードページへ →デスクトップ環境ではClash Verge RevやFlClashを確認し、ディストリビューションに合ったパッケージ形式を選べます。サーバーやルーターでは、独立したMihomoコアを利用し、設定ディレクトリ、サービスの起動、権限を自分で管理できます。コマンドラインアプリはデスクトップのシステムプロキシを参照しないことがあります。テスト時は、トレイアイコンの状態だけで判断せず、使用するプロキシ環境変数やTUNルートを明確にしてください。
ダウンロードページへ →設定は移行できますが、システム設定は改めて確認が必要です。同じYAMLを複数のクライアントで使う場合も、コアの機能、オーバーライドの仕組み、OSの権限によって動作が異なることがあります。移行前に使える設定をエクスポートし、プロキシグループの選択とカスタムルールを記録してください。移行後は基本的な接続から検証し、TUN、DNSなどの上級設定を順に戻します。サブスクリプションURLは機密情報です。公開スクリーンショットやリポジトリ、掲示板に載せないでください。
すべてのクライアントを見る →OPEN SOURCE
Mihomo、GUIクライアント、サブスクリプションはそれぞれ役割が異なります。アプリ名だけで選ぶのではなく、三者の関係を理解すると、クライアント選びや問題の切り分けに役立ちます。
Mihomoは、前身をClash.MetaとするClashエコシステムのオープンソースプロキシコアです。古いガイドにあるClash Meta、設定で使われるmihomo、クライアントの設定画面に表示されるコア名は、同じプロジェクトの異なる時期の名称を指している場合があります。判断するときはインストーラーのファイル名だけでなく、実際のプロジェクトの提供元とクライアントのコア情報を確認してください。プロジェクトのソースコードと変更履歴はMetaCubeX/mihomoリポジトリで確認できます。
コアはプロトコル処理、ルール照合、DNS、ネットワークスタックに関する機能を提供します。GUIクライアントはその上に設定選択、サブスクリプション更新、ログ表示などの機能を備えています。画面にスイッチがないからといって、コアに該当機能がないとは限りません。逆に、画面に設定項目が残っていても、現在のコアが受け付けるとは限りません。新しい設定項目を変更する前に、現在の実行環境に対応した説明を確認してください。
クライアントのインストーラーには通常、利用可能なリモートプロキシサービスは含まれていません。ノードのパラメーター、認証情報、サブスクリプション内容はユーザー自身が用意する設定元から取得します。接続できるかどうかは、リモートサービス、現在のネットワーク、プロトコル設定にも左右されます。サブスクリプションにアクセスできない、アカウントの期限が切れている、リモート側で接続を拒否されるといった場合は、クライアントのインストール失敗と決めつけず、該当する提供元を確認してください。
GUIクライアントによって設定のマージ順序は異なります。たとえば、画面上の設定がオーバーライド層を通じてサブスクリプションに適用される場合があります。一方、ダウンロードしたファイルを直接編集すると、更新時に置き換えられる可能性があります。元のサブスクリプション、個人用オーバーライド、実行時設定を明確に分けて管理しましょう。長期間使うルールはクライアントが対応する永続化先に保存し、更新後に最終的な適用内容を確認してください。
MihomoリポジトリはGPL-3.0ライセンスを採用しています。ソースコード、課題の議論、リリースノートは、設定の動作を確認するための情報源です。クライアントや付属コンポーネントのライセンスは、それぞれのライセンスファイルを確認してください。当サイトでは、ダウンロード数、ノード数、速度測定の結果を根拠の代わりにはしません。ソフトウェア選びでは、機能の範囲、動作条件、メンテナンス情報が明確かどうかを確認しましょう。
コミュニティの課題を調べるときは、OS、コア、エラーメッセージが一致する事例を優先してください。似た症状でも原因が同じとは限りません。Webページのタイムアウトは、ルールの接続先、名前解決、リモート接続のいずれが原因の場合もあります。問題を報告する際は再現手順と、個人情報を伏せたログを添えてください。サブスクリプションの認証情報、パスワード、個人のネットワーク情報は削除しましょう。設定画面全体のスクリーンショットより、再現できる手順のほうが原因の特定に役立ちます。
GUIクライアント、コア、サブスクリプションの更新は、それぞれ別の更新経路です。クライアントの更新で画面や権限管理が変わることがあり、コアの更新で設定の対応範囲が変わることがあります。サブスクリプションの更新では、リモートから取得した設定内容が置き換わります。三種類を同時に更新してからテストすると、問題が起きた際に原因を特定しづらくなります。使える設定を保存し、一つずつ更新してログを確認してください。
日々の管理では、設定の入手元、TUNの有効・無効、DNS動作モード、カスタムルールの保存場所を簡単に記録しておくと便利です。アップグレード後は、まず通常のWebサイトとLANサービスをテストし、次にUDPが必要なアプリを確認してください。UDP転送には、プロトコル、ノード、リモートサービス、ローカルの通信取り込み経路すべての対応が必要です。スイッチを一つ有効にするだけで、すべてのアプリが同じように動作するとは限りません。
Gitがインストールされている場合は、以下のコマンドでソースコードを取得できます。リポジトリをクローンしても、プロジェクトのソースコードが取得されるだけで、クライアントのインストールや起動は行われません。
git clone https://github.com/MetaCubeX/mihomo.git最近の記事では、Androidのバックグラウンド動作、接続後の段階的な確認、macOSの権限を取り上げています。トラブル対処では、通信の入口、名前解決、ルールの一致、リモート側の出口を順番に確認しましょう。一度に変更する条件は一つにし、変更前後の症状を記録してください。
AndroidのVpnService許可画面、VPNの常時接続、アプリ別プロキシの設定方法と、主要メーカーの省電力対象外設定を解説し、バックグラウンドでの切断を防ぎます。
記事を読む →システムプロキシの有効状態、ポートの競合、DNSの名前解決、ルールの一致、ノードの接続状況を順に確認し、接続済みなのにインターネットを利用できない原因を特定します。
記事を読む →開発元を確認できないアプリのブロック、システム拡張機能の許可、TUNに必要なネットワーク拡張機能の承認、繰り返し表示されるキーチェーンの確認画面への対処を解説します。Appleシリコン搭載モデルとIntel搭載モデルの違いも紹介します。
記事を読む →