Clash クライアント · 設定とルール
mihomo カーネル· GPL-3.0 オープンソース
OSに合ったクライアントを選び、サブスクリプションの読み込み、ルールによる振り分け、プロキシ設定を行います。
CLIENTS / プラットフォーム別
まずOSとCPUアーキテクチャを確認してから、クライアントを選びましょう。GUIは設定を管理し、カーネルは接続を処理します。同じ設定項目でも、クライアントによって設定画面の場所は異なります。
Clash Plusを起点に、Clash Verge Rev、FlClash、Clash Nyanpasuの画面やサービスの動作方式も比較できます。インストール前にシステム設定でCPUの種類を確認し、ファイルのアイコンだけでインストーラーの対応可否を判断しないでください。
初回接続ではシステムプロキシを使い、ブラウザーのリクエストが接続ログに記録されることを確認してから、必要に応じてTUNを有効にします。旧クライアントから移行する場合は、先に旧アプリを終了してプロキシ設定を解除し、ポートの競合や複数サービスによるルート変更を防ぎましょう。Clash for Windowsは開発が終了しており、旧環境との比較用にアーカイブ版を掲載しています。
ダウンロード Windows クライアントApple Silicon用とIntel用でインストーラーが異なります。Clash Plus、Clash Verge Rev、FlClashでは設定管理の方法も異なります。バックグラウンドサービスが必要かどうかは、システムプロキシやTUNの権限、起動時の自動実行要件に応じて判断してください。
クライアントを「アプリケーション」フォルダに移動してから、初回起動とシステム権限の許可を済ませます。接続できない場合は、現在のネットワークサービスに設定されたプロキシのアドレスとポートが、起動中のクライアントと一致しているか確認してください。Wi-Fiを切り替えた後も再確認が必要です。メニューバーのアイコンだけでは通信がプロキシ経由になっているか判断できません。ClashX Metaのアーカイブ状況はダウンロードページに記載しています。
ダウンロード macOS クライアントClash Plus、Clash Meta for Android、FlClash、Surfboardを比較できます。インストーラーのCPUアーキテクチャが端末に合っているか確認してください。サブスクリプションの形式も事前に確認し、別形式の設定をClash YAMLとしてそのまま読み込まないようにしましょう。
初回接続時、システムからVPN接続の許可を求められます。アプリをバックグラウンドにすると接続が切れる場合は、バッテリー最適化とバックグラウンド実行の制限を確認し、クライアントのログも確認してください。ほかのVPNアプリが動作している場合は、どちらが接続を制御しているか確認しましょう。2つのアプリを何度も切り替えると、テスト結果を比較しにくくなります。
ダウンロード Android クライアントダウンロードページではClash PlusのApp Storeページと、公式サイトclashplus.ioを案内しています。インストール前にストアのシステム要件を確認し、読み込み前にサブスクリプションの設定形式がクライアントに対応しているか確認してください。
設定を追加したら、システムの案内に従ってVPN構成の作成を許可し、クライアントに戻って使用するサブスクリプションと接続先を選びます。Wi-Fiとモバイル回線はそれぞれ個別に確認してください。片方の回線で問題が起きた場合は、ネットワーク環境、名前解決の結果、接続ログを記録してからDNSを調整するか判断します。VPNアイコンの表示はトンネルが有効であることを示すだけで、ルールの適用や接続先へのアクセス確認の代わりにはなりません。
ダウンロード iOS クライアントデスクトップではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージ形式でインストールできます。サーバーやルーターでは、ダウンロードページのmihomoカーネルを確認してください。CPUアーキテクチャ、実行権限、設定ディレクトリを確認してからサービスを起動します。
デスクトップのシステムプロキシが、コマンドラインツールにも適用されるとは限りません。ターミナルのプログラムでは、独自のプロキシ設定や環境変数を確認してください。TUNを使う場合は権限とルートも確認が必要です。システムサービスとして動かす際は、設定ファイルのパスを明示し、参照できるログを残してください。サービスの実行プロセスが、現在のターミナルと同じ作業ディレクトリやユーザー権限を使うとは限りません。
ダウンロード Linux クライアントCONFIGURATION / 設定機能
すべてのスイッチを一度に有効にせず、問題に合わせて設定を選びましょう。以下の例は項目の関係を示すもので、利用可能なプロキシサーバーは含みません。実際に使うには、サブスクリプションや接続先の情報が必要です。
mode: rule
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTmode: global
GLOBAL
→ 選択した接続先mode: direct
DIRECT
→ 接続先アドレスルールモードでは、リストの順にドメイン、アドレス、ルールセットを照合し、一致した接続を指定の接続先へ渡します。末尾のMATCHが、ほかのルールに一致しない接続を処理します。プロキシ経由の接続を一時的に比較する場合は、グローバルモードに切り替え、GLOBALで実際に選択されている接続先を確認してください。直接接続モードはローカルネットワークとの比較に使うもので、クライアントを停止する設定ではありません。接続先を一律に指定するだけのツールとは異なり、Clashでは設定から振り分け条件を確認できます。問題の切り分けでは、まず適用されたルールを確認してから順序を変更し、接続先の障害をルールの不具合と誤認しないようにしましょう。
TUNは仮想ネットワークインターフェースで通信を受け取り、システムプロキシを参照しないアプリにも対応します。有効にする前に、サブスクリプションと接続先が利用できることを確認し、クライアントに必要なサービス権限や管理者権限があるか確かめてください。システムプロキシより広い範囲の通信を制御できる一方、ルート、DNS、ファイアウォール設定の影響を受けやすくなります。例では自動ルートとDNSハイジャックを使っていますが、すべてのプラットフォームで同じ方式とは限りません。有効化後にLANへ接続できない場合は、ルートの競合や除外ルールを確認し、複数の通信制御サービスを重ねて有効にしないでください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53サブスクリプションはサーバー情報や設定全体を更新するためのものです。読み込み後に選択して有効にする必要があり、ダウンロードできただけでは接続完了ではありません。設定一式を含むサブスクリプションと、proxy-providersで管理するプロキシの集合は別の階層です。内容に合った読み込み方法を選んでください。リモートの設定を直接編集する代わりにローカルオーバーライドを使うと、ポートやカスタムルールを維持しやすく、次回更新で設定が上書きされるリスクも抑えられます。更新に失敗したら、リクエストエラーと設定の解析エラーを記録し、ネットワーク経路とYAML構文を分けて確認してください。アクセス情報を含むサブスクリプションURLを公開しないでください。
proxy-providers:
remote:
type: http
url: "https://example.org/proxies.yaml"
path: ./providers/remote.yaml
interval: 3600
proxy-groups:
- name: PROXY
type: select
use:
- remoteexample.orgは設定項目の位置を示すための例であり、実際のサブスクリプションURLではありません。
DNSはドメイン名の名前解決を担い、ルールは接続をどの接続先に渡すかを決めます。両者を合わせて設定してください。fake-ipは予約済みアドレスでドメインとの対応関係を作り、カーネルが後続の接続を識別しやすくします。nameserver-policyでは、指定したドメインごとにDNSサーバーを選べます。システムDNSの変更だけの場合と異なり、カーネルのDNSは通信制御経路に沿って名前解決を処理できます。ただし、アプリ独自の暗号化DNSは別途確認が必要です。設定変更後は接続をやり直して名前解決ログを確認し、必要に応じてキャッシュを消去してください。名前解決に成功しても、プロキシの接続先が利用可能とは限りません。別々に検証しましょう。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.alidns.com/dns-query
nameserver-policy:
"+.example.org":
- https://dns.alidns.com/dns-queryClashエコシステムでは似たYAML構造が使われていますが、カーネルによって対応するプロトコルや項目は異なります。mihomoはClash形式の設定を引き継ぎ、一部のプロトコルやルール機能を拡張しています。旧カーネルでは新しい項目を読み込めなかったり、想定どおりに処理できなかったりする場合があります。クライアントの外観だけで比較せず、移行時にはカーネル名、設定構文、機能の対応状況を確認してください。クライアントにカーネルの選択機能がある場合は、切り替える前に設定をバックアップしましょう。例は基本的な項目のみですが、移行後はDNS、接続先グループ、最終ルールを一つずつ検証してください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- GEOIP,CN,DIRECT
- MATCH,DIRECT共通の接続先グループとルールは、複数端末の設定の土台にできます。ただし、システム権限、ファイルパス、通信の制御方法は端末ごとに調整が必要です。デスクトップではシステムプロキシから始めることが多く、モバイル端末では通常、システムのVPNインターフェースを使います。サーバーではサービス設定を明示する方法が適しています。設定ファイル全体をそのままコピーするより、共通ルールと端末固有の設定を分けて管理すれば、ポートや通信制御の違いを保ちやすくなります。移行後は接続先グループの参照先が存在するかを確認し、名前解決と接続を検証してください。デスクトップ用の絶対パスをスマートフォンにそのまま移すことはできません。
# 端末ごとにローカルポートを確認
mixed-port: 7890
allow-lan: false
# 共通して管理できるルール構成
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYまずリクエストがクライアントに届いていることを確認し、次に名前解決、ルールの適用、接続先の選択を確かめましょう。設定画面のPROXYはグループ名であり、インストーラーにプロキシサービスが付属するわけではありません。
QUICKSTART / 3ステップで確認
初回設定では、まず接続経路を一つ作り、動作を確認します。手順ごとに確認してから次へ進めば、問題が読み込み、通信制御、接続先のどこで起きているか把握しやすくなります。
クライアントのサブスクリプションまたは設定画面でURLを追加するか、ローカルのYAMLファイルを読み込みます。保存後に解析結果を確認し、想定した接続先グループが表示されていることを確かめてから、使用する設定として選択してください。サブスクリプションが一覧に表示されただけでは、カーネルに読み込まれたとは限りません。
読み込みに失敗した場合は、まずネットワークリクエストと設定構文のどちらのエラーか確認してください。ウェブページ形式の説明URLはサブスクリプションとして使えません。項目のインデントに誤りがある場合は、ファイルを修正します。初回は元の設定を保存し、独自の設定はクライアントが対応するオーバーライド機能で追加しましょう。リモート更新分とローカルの変更を後から区別しやすくなります。
普段使いではルールモードから始め、実際に使用する選択グループで接続先を指定します。デスクトップではシステムプロキシを有効にして、待ち受けポートを確認してください。モバイル端末ではシステムの案内に従ってVPN接続を許可します。システムプロキシに従わないプログラムも対象にする場合は、プラットフォームごとのTUN設定を確認しましょう。
グローバルモードは、カーネルに届いた接続の接続先を切り替えるだけです。まだ通信制御されていないプログラムを自動的にクライアントへ通す機能ではありません。モードを切り替えたらリクエストを再実行し、ログを確認してください。違いを検証する際は、接続先のアドレスとネットワーク環境を一定に保ち、一度に変更する項目を一つに絞りましょう。そうすれば、一時的な回線変動を設定の効果と取り違えにくくなります。
テスト対象のURLを開き、接続ログから該当ドメインを探して、適用されたルールと最終的な接続先を確認します。次に、直接接続する想定のアドレスも試し、ルールが順番どおりに適用されるか確認してください。アプリとブラウザーの両方でテストすると、プロキシ設定が一部のプログラムにしか適用されていないことも見つけやすくなります。
接続ログがない場合は、システムプロキシ、アプリ側の設定、TUNによる通信制御を優先して確認します。ログがあるのに接続できない場合は、名前解決、接続先の稼働状況、接続先からの応答を調べてください。使用を終えるときは、クライアントの通信制御を先にオフにしてからアプリを終了し、システムにローカルポートを指すプロキシ設定が残らないようにしましょう。詳しい手順と元に戻す方法はチュートリアルをご覧ください。
SOURCE / オープンソースエコシステム
クライアント名、カーネル名、サブスクリプションサービスは分けて考える必要があります。機能が使えるかどうかは、ソフト名にClashが含まれているかではなく、プロジェクトのドキュメント、実際のカーネル、ローカルログをもとに判断してください。
Clashは当初、ルールベースのプロキシカーネルとして設定エコシステムを築き、その後、デスクトップやモバイル向けのGUIクライアントが登場しました。元のClashプロジェクトや初期のクライアントの一部は、すでに開発・保守を終了しています。現在は名前が似たクライアントでも、メンテナンス状況は異なる場合があります。古い解説にあるボタンの場所、サービスのインストール方法、プロトコル対応を、すべての新しいクライアントにそのまま当てはめることはできません。
選ぶ際は、まずプロジェクトに最近のリリースがあるか確認し、システム要件と設定の対応状況を調べましょう。旧環境で動いているプログラムでも、新しいサブスクリプションの項目を認識できない場合があります。移行前に設定、グループの選択、ローカルルールを保存し、移行後は接続を再検証してください。起動できたことだけを完了の基準にしないようにしましょう。
mihomoはClashエコシステムで継続的に開発されているカーネルプロジェクトで、設定の解析、ルールの照合、接続先との接続を担います。GUIクライアントは、サブスクリプション一覧、システムプロキシの切り替え、サービスのインストール、ログ画面などを管理します。同じカーネルを使うクライアント同士では、基本的な設定機能が近い場合がありますが、ローカルオーバーライド、権限処理、システム連携には違いが残ることがあります。
そのため、画面にスイッチがあるかどうかだけでは、カーネルが該当項目に対応しているか判断できません。説明と画面の内容が異なる場合は、まずクライアントの情報画面でカーネルを確認し、該当するドキュメントを参照してください。ダウンロードページではクライアントを選べます。詳しいドキュメントではインストール手順とカーネル設定を分けて説明しているため、実際の環境に合わせて確認できます。
mihomoはGPL-3.0ライセンスで公開されており、ソースコード、課題の議論、リリースノートはプロジェクトのリポジトリで確認できます。このライセンスが適用されるのは該当プロジェクトです。すべてのGUIクライアント、サブスクリプションサービス、追加コンポーネントが同じライセンスを使っているとは限りません。ソフトウェアを配布または改変する場合は、各プロジェクトのライセンスファイルと依存関係の説明を確認してください。
ソースコードや課題の記録は、設定項目の動作、プラットフォームの制限、既知の問題を確認するのに役立ちます。このサイトでは、確認できていないダウンロード数、ユーザー評価、接続速度の統計は掲載していません。オープンソースコードは実装を確認する手がかりになりますが、通信状況はローカル環境、接続先のサービス、選択した接続先にも左右されます。プロジェクトの知名度を実機テストの代わりにすることはできません。
クライアント、カーネル、サブスクリプションの更新は、それぞれ別の操作です。クライアントの更新では画面やシステムサービスが変わることがあり、カーネルの更新では設定項目の対応状況や接続動作が変わる可能性があります。サブスクリプションの更新では、主にサーバー、ルール、設定内容が置き換わります。問題が起きたら、どの層に変更があったか記録してから、設定を戻すかリリースノートを確認してください。
更新前にローカルオーバーライドとカスタムルールを書き出し、ポートと通信制御の方法も記録しておきましょう。更新後はまず設定を読み込めるか確認し、次にプロキシグループの参照、DNS、ルートを確認します。サブスクリプションだけを更新して問題が起きた場合は、すぐクライアントを再インストールせず、まず更新前後の内容を比較してください。変更点を層ごとに記録すれば、同じ確認を繰り返さずに済みます。
Clashクライアントをインストールしても、プロキシサーバーが自動的に使えるようになるわけではありません。接続先は自分で構築したサービス、または既存のサブスクリプションから取得します。クライアントは設定に基づいて通信を処理します。サブスクリプションに含まれるアドレス、アクセス情報、アカウント情報は機密情報として扱ってください。問題の相談でログを共有する際は、エラーの種類と必要な項目だけを残し、サービスへのアクセスに使える情報は削除しましょう。サブスクリプション全体を公開リポジトリに登録しないでください。
このページの編集画面は設定項目の構造を示す例です。選択グループ内のDIRECTは直接接続を意味し、プロキシ回線が設定済みであることを示すものではありません。用語がわからない場合は、用語集でカーネル、接続先グループ、ネットワークモードを確認し、クライアント比較で各クライアントの違いを見てください。特定のプラットフォームで権限やサービスの問題がある場合は、詳しいドキュメントからOS別の説明を参照できます。
以下のコマンドはプロジェクトのリポジトリをクローンするもので、ソースコードやドキュメントを読む場合に適しています。通常のインストールでは、クライアントを選ぶだけで利用できます。ソースコードをビルドするには、プロジェクトのドキュメントに記載されたツールチェーンと環境も必要です。
git clone https://github.com/MetaCubeX/mihomo.gitNOTES / 最近の記事
実際の環境に即して操作手順を解説します。接続経路に沿って問題を切り分け、まずどの段階で起きているか確認してから設定を変更します。変更前後のテストでは、同じネットワークと接続先を使ってください。
インストーラーの選び方からサブスクリプションの読み込み、システムプロキシやTUNサービスの有効化まで、Windowsでの設定手順を順に解説。ポートの競合やサービスのインストール失敗など、よくあるエラーもまとめています。
インストールガイドを読む →検査ページでDNSリクエストの実際の行き先を確認し、fake-ip、nameserver-policy、TUNによるDNSハイジャックの3段階で対策します。変更箇所を照合できるdns設定例も掲載。
DNS設定を読む →接続先の品質、中継経路、端末の設定を順に切り分けます。接続先を切り替えて比較し、通信経路を確認し、TUNスタックとDNS設定を調べて速度低下の原因を特定します。
対処手順を読む →「接続できない」と「接続が遅い」は分けて確認してください。前者では、まずリクエストがカーネルに届いているかを確認します。後者ではテスト条件を一定に保ちます。設定項目の詳しい説明と各プラットフォームでの復旧手順は、設定に関するよくある質問をご覧ください。