No.1
おすすめの導入先Clash Plus
- システムプロキシ:オンの例
- TUNモード:オフの例
- サブスクリプションの自動更新:オンの例
設定項目の例です。実際の表示はOSやクライアントによって異なります。
Clashクライアント一覧・OS別
対応OS別にクライアントを整理し、サブスクリプションの追加やルール振り分けも解説。自分に合ったダウンロード先を選べます。
No.1
おすすめの導入先設定項目の例です。実際の表示はOSやクライアントによって異なります。
No.2
デスクトップ向け掲載順は編集上の整理であり、性能評価ではありません。
No.3
モバイル向けモバイル端末で通信を処理するには、通常VPN接続の許可が必要です。
CONFIG / 設定ガイド
クライアントは操作画面を提供し、コアが接続を処理します。まず設定項目の役割を理解してから、必要な機能を選びましょう。以下はMihomoの設定構文を使った例で、サブスクリプションやプロキシノードを含む完全な設定ではありません。
ルールモードでは、リストの上から順に接続を判定し、最初に一致したルールで通信先を決定します。末尾のMATCHは、ほかのルールに一致しない通信を処理します。特定のドメインを直接接続し、それ以外をプロキシグループに振り分けたい場合に便利です。すべてのアプリを同じ経路に固定する必要はありません。変更前に参照先のプロキシグループ名が存在するか確認してください。名前の指定を誤ると設定の読み込みに失敗します。ルールの編集画面はクライアントごとに異なりますが、互換性のあるコアなら対応する構文を利用できます。振り分け結果を調べるときは、プロキシのオン・オフだけでなく、接続ログに記録された適用ルールも確認しましょう。
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,DIRECT
プロキシグループを使うと、複数の接続先を手動で選んだり、自動判定したりできます。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは設定順に利用可能な接続先を探します。ルールモードやグローバルモードの別名ではありません。サブスクリプションを追加したら、グループに想定したノードが表示されることを確認し、ルールの振り分け先に設定しましょう。速度テストの結果は特定のテスト先への通信を示すもので、実際の利用環境での確認に代わるものではありません。以下では組み込みの接続先を使ってグループの構造を示します。実際の設定ではサブスクリプションで提供されたノード名を追加できます。
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
- REJECT
rules:
- MATCH,手動選択
DNS設定はドメイン名の名前解決方法を決めます。Fake-IPは仮想IPアドレスを使ってドメイン名と接続の対応関係を保ち、コアがドメイン名に基づいて通信を振り分けられるようにします。有効にした際に予約アドレス帯が表示されても、ノードの異常とは限りません。クライアントのログと実際のアクセス状況をあわせて確認してください。実際の名前解決が必要なLAN内サービスでは、コアのドキュメントを確認し、必要に応じてフィルター対象に設定します。クライアントをすぐに入れ替えるのではなく、名前解決のリクエストがコアに届いているか、上流DNSに接続できるかを先に確認すると、原因を絞り込みやすくなります。以下のDNSサーバーは設定項目の例です。利用するネットワークに合わせて変更してください。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost"
nameserver:
- https://dns.alidns.com/dns-query
システムプロキシは、OSのプロキシ設定に従うアプリで利用できます。一方、TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。システムプロキシを参照しないアプリにも適しています。有効化には管理者権限やサービスコンポーネント、モバイルOSでのVPN接続許可が必要な場合があり、操作方法はクライアントによって異なります。TUNを有効にしても、無効なサブスクリプションが復旧したり、すべてのアプリで動作が保証されたりするわけではありません。テスト時は現在の設定を残し、ルーティング、DNS、ほかのVPNとの競合を確認しましょう。一般のWebサイトにアクセスできることを確かめてから、目的のアプリを検証してください。複数のネットワーク設定を同時に変更するのは避けましょう。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
ルールモードでは、リストの上から順に接続を判定し、最初に一致したルールで通信先を決定します。末尾のMATCHは、ほかのルールに一致しない通信を処理します。特定のドメインを直接接続し、それ以外をプロキシグループに振り分けたい場合に便利です。すべてのアプリを同じ経路に固定する必要はありません。変更前に参照先のプロキシグループ名が存在するか確認してください。名前の指定を誤ると設定の読み込みに失敗します。ルールの編集画面はクライアントごとに異なりますが、互換性のあるコアなら対応する構文を利用できます。振り分け結果を調べるときは、プロキシのオン・オフだけでなく、接続ログに記録された適用ルールも確認しましょう。
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,DIRECT
プロキシグループを使うと、複数の接続先を手動で選んだり、自動判定したりできます。selectは手動選択、url-testはテスト結果に基づく選択、fallbackは設定順に利用可能な接続先を探します。ルールモードやグローバルモードの別名ではありません。サブスクリプションを追加したら、グループに想定したノードが表示されることを確認し、ルールの振り分け先に設定しましょう。速度テストの結果は特定のテスト先への通信を示すもので、実際の利用環境での確認に代わるものではありません。以下では組み込みの接続先を使ってグループの構造を示します。実際の設定ではサブスクリプションで提供されたノード名を追加できます。
proxy-groups:
- name: 手動選択
type: select
proxies:
- DIRECT
- REJECT
rules:
- MATCH,手動選択
DNS設定はドメイン名の名前解決方法を決めます。Fake-IPは仮想IPアドレスを使ってドメイン名と接続の対応関係を保ち、コアがドメイン名に基づいて通信を振り分けられるようにします。有効にした際に予約アドレス帯が表示されても、ノードの異常とは限りません。クライアントのログと実際のアクセス状況をあわせて確認してください。実際の名前解決が必要なLAN内サービスでは、コアのドキュメントを確認し、必要に応じてフィルター対象に設定します。クライアントをすぐに入れ替えるのではなく、名前解決のリクエストがコアに届いているか、上流DNSに接続できるかを先に確認すると、原因を絞り込みやすくなります。以下のDNSサーバーは設定項目の例です。利用するネットワークに合わせて変更してください。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "localhost"
nameserver:
- https://dns.alidns.com/dns-query
システムプロキシは、OSのプロキシ設定に従うアプリで利用できます。一方、TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。システムプロキシを参照しないアプリにも適しています。有効化には管理者権限やサービスコンポーネント、モバイルOSでのVPN接続許可が必要な場合があり、操作方法はクライアントによって異なります。TUNを有効にしても、無効なサブスクリプションが復旧したり、すべてのアプリで動作が保証されたりするわけではありません。テスト時は現在の設定を残し、ルーティング、DNS、ほかのVPNとの競合を確認しましょう。一般のWebサイトにアクセスできることを確かめてから、目的のアプリを検証してください。複数のネットワーク設定を同時に変更するのは避けましょう。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
設定項目が使えるかどうかは、実際に使用するコアによって異なります。ルールセット、ドメインスニッフィング、ローカルオーバーライド、外部コントローラーの設定は上級設定を参照してください。初めてサブスクリプションを追加する場合は、使い方ガイドから始めましょう。
画面の見た目が似ていても設定に互換性があるとは限りません。利用シーンに合わせて確認してください。
まず利用中のOSに合ったインストール先を探す場合は、一覧のおすすめから確認し、現在のプラットフォームで使える機能をチェックしましょう。
クライアントを比較する →デスクトップで設定やプロキシグループを管理したい場合に適しています。ローカルオーバーライドを使うときは、サブスクリプションの元データと最終的に適用される設定を区別しましょう。
クライアントを比較する →Androidでの設定のインポート、VPNの許可、アプリ通信の取り込み方法を確認したい場合に適しています。インストール前に端末のアーキテクチャを確認してください。
クライアントを比較する →DOWNLOAD / OS別ダウンロード
まずOSとプロセッサのアーキテクチャを確認し、そのうえでクライアントを比較しましょう。ダウンロード先ではインストールパッケージを選び、利用可能な接続先はサブスクリプションで用意します。それぞれ別に準備が必要です。インストールしただけではプロキシサービスを利用できません。
まずClash Plusを確認し、Clash Verge Rev、FlClash、Clash Nyanpasuと比較しましょう。古い設定の移行方法を調べる場合は、開発が終了したClash for Windowsのアーカイブ情報を参照してください。長期的に更新されるクライアントとして旧版を選ぶことはおすすめしません。
初回起動時はサブスクリプションを追加し、コアが正常に起動したことを確認してからシステムプロキシを有効にします。ポートが使用中の場合は、まず競合しているプロキシアプリを特定しましょう。TUNが必要なら、クライアントの案内に従ってサービスをインストールするか、管理者権限を許可してください。初回起動時にすべてのネットワーク機能を有効にする必要はありません。
「このMacについて」でApple SiliconかIntelかを確認し、対応するインストーラーを選びましょう。ダウンロードページではClash Plus、Clash Verge Rev、FlClashを主な選択肢として掲載しています。ClashX Metaは開発終了のアーカイブ版として別途案内しています。
インストール後に表示される権限の確認と、サブスクリプションの追加は別の手順です。ネットワーク拡張機能やサービスの許可は通信の取り込みに関わり、ノードやルールはサブスクリプションで設定します。キーチェーンの確認画面が出たら、まず要求元のアプリを確かめてからシステム設定に従って対応してください。起動時のメッセージをすべてノードの利用不可と結び付けないようにしましょう。
ダウンロードページではClash Plus、Clash Meta for Android、FlClash、Surfboardを順に紹介しています。比較的新しい端末の多くはARM64に対応していますが、旧型端末では別のアーキテクチャが必要な場合があります。端末のメーカー名で推測せず、まず端末情報を確認しましょう。
設定を追加したら、使用する設定を選び、OSのVPN接続許可を行います。アプリの切り替えや画面ロック後に接続が切れる場合は、バックグラウンド動作とバッテリー管理を確認してください。アプリごとに通信を振り分ける場合は、対象アプリの設定が許可リストか除外リストかを確認し、意図と逆のリストに入れないようにしましょう。
Clash PlusはApp Storeからインストールできます。製品の公式サイトはclashplus.ioです。ダウンロードページからストアの商品ページを開き、端末の対応条件を確認してから、クライアントの案内に従って設定を追加してください。
初回接続時はVPN構成の追加を許可してください。接続状態はシステム設定で確認できます。デスクトップ版の設定項目や操作手順をモバイル版でそのまま使えるとは限りません。サブスクリプションの形式に互換性がない場合は、サービス提供元がどの形式でエクスポートしているかを確認し、使用中のクライアントの説明と照らし合わせてください。
デスクトップで使う場合はClash Verge RevとFlClashを比較し、ディストリビューションに合ったDEBやRPMなどの形式を選びましょう。サーバーやルーターでは、GUIクライアントとMihomoコアを区別する必要があります。デスクトップ用インストーラーを汎用のコマンドラインプログラムとして扱わないでください。
インストール前にプロセッサのアーキテクチャと実行環境を確認しましょう。デスクトップのシステムプロキシ、ターミナルのプロキシ環境変数、TUNの通信取り込み範囲はそれぞれ異なります。ブラウザーで接続できても、コマンドラインの通信がプロキシ経由とは限りません。対象のプログラムごとに動作を確認し、サービスの権限、ルーティング、DNSの名前解決経路もチェックしてください。
ECOSYSTEM / オープンソース
順位だけでメンテナンス状況を判断したり、インストールパッケージの性能で通信速度を説明したりせず、プロジェクトのドキュメントと実際の設定をもとに機能を確認しましょう。
上級設定を見る →Clashエコシステムには、設定のインポート、プロキシグループの選択、ログの確認、ネットワーク機能の切り替えなどを行うGUIクライアントが複数あります。MihomoはClash.Metaから派生したプロキシコアのプロジェクトで、プロトコル処理、ルール判定、DNS、接続の転送を担います。クライアント名にClashやMetaが含まれていても、すべてのソフトウェアが同じコアを採用しているとは限らず、設定をすべて相互にコピーできるわけでもありません。設定項目が使えるかどうかは、実際のコアとクライアントによる設定生成方法を確認してください。
この関係を理解しておくと、問題の切り分けに役立ちます。画面が開かない場合はプログラムの実行環境、設定の読み込みに失敗する場合は構文や設定項目、ルールが想定どおりに適用されない場合は最終設定と接続ログを確認します。特定の接続先だけ使えない場合は、サブスクリプションサービスや接続先のネットワークを調べましょう。原因の異なる問題を混同すると、クライアントを何度も再インストールしても解決しないことがあります。トップページの設定例は項目の説明用です。詳細は各プロジェクトの最新ドキュメントを参照してください。
Mihomoのソースコード、課題の議論、ドキュメントは、コアの動作を理解するための情報源です。プロトコル対応、DNSの挙動、ルーティングに疑問がある場合は、まずドキュメントで設定項目名を検索し、関連する議論も確認してください。問題を報告する際は、OS、再現手順、個人情報を伏せたログを添え、サブスクリプションから生成された設定とローカルで変更した設定を区別しましょう。公開情報を使えば設計や修正の経緯を追えますが、オープンソースだからといって、すべてのクライアントで機能、権限の仕組み、リリース時期が同じとは限りません。
以下のコマンドはMihomoのソースコードを取得するためのものです。実装を読んだり、ビルド環境を準備したり、設定の動作を調べたりする場合に利用できます。リポジトリをクローンしても、デスクトップクライアントが自動でインストールされたり、利用可能なサブスクリプションが作成されたりするわけではありません。設定を追加して使い始めたい場合は、上部のOS別ダウンロード先を利用してください。コアの設定項目を確認する場合はMihomoドキュメントを開き、項目名から該当する説明を探せます。
クライアントの更新では画面、OSとの連携、同梱コアが変わります。サブスクリプションの更新ではノード、プロキシグループ、サービス提供元が配信するルールが変わります。この2つは別々に更新できます。ノード一覧が変わらない場合は、サブスクリプションの取得に成功しているか、URLが有効かを確認してください。特定のプロトコルを読み込めない場合は、現在のコアが対応しているかを確認しましょう。リモートのサブスクリプションを再取得すると、元データに直接加えた変更が上書きされる場合があります。長く使うルールは、クライアントが対応するオーバーライド機能で管理してください。
更新前に、現在動作している設定を保存し、手動で変更したポート、DNS、通信の取り込み方法を記録しましょう。更新後は設定を読み込めることを確認してから、普段使う接続先で動作を検証し、最後にルールが想定どおりに適用されるか確認します。クライアント、サブスクリプションURL、DNSの上流サーバーを同時に変更しないでください。問題が起きた際に原因を特定しにくくなります。開発終了したクライアントは過去の設定を調べる用途に適していますが、アーカイブ版で新しいOSやプロトコルへの対応が続く保証はありません。
クライアントは接続に使うツールで、サブスクリプションは通常ユーザーが別途用意します。サブスクリプションURLには認証情報が含まれる場合があるため、パスワードと同様に保管してください。スクリーンショット、公開ログ、オンラインでの質問には、URL全体、コントロールパネルのキー、ノードの認証情報を含めないようにしましょう。設定を追加する前に入手元が信頼できるか確認し、サービスの対象範囲、有効期間、通信量の制限を把握してください。不明なURLを第三者の変換サービスに渡すと、設定全体がサービス提供者に見られる可能性があります。利用前にデータの取り扱いを確認しましょう。
設定を追加した後は、接続アイコンだけで判断しないでください。追加した設定が現在選択されていること、プロキシグループに選択可能な接続先があることを確認してから、目的のサイトにアクセスし、接続ログで適用ルールと接続先を確認します。ノードのテストに成功しても、すべてのWebサイト、アプリ、UDP通信が使えるとは限りません。直接接続とプロキシ接続の両方に問題がある場合は、まずローカルネットワークを確認します。特定のドメインだけ失敗する場合は、名前解決、ルール、接続先のサービスを確認しましょう。この順番で検証すれば、根拠のない設定変更を減らせます。
NOTES / 使い方メモ
症状に合った記事を選んでください。起動できない場合はまずポート、初回起動時の警告はOSの権限、接続後にアクセスできない場合はプロキシ、名前解決、ルール、接続先の順に確認します。
起動時にaddress already in useと表示されたら、まずnetstatまたはlsofで7890を使用中のプロセスを特定します。次に設定のmixed-portと外部コントロール用ポートを変更し、システムプロキシの設定も合わせて更新してください。
ポートの確認手順を読む →macOSでクライアントを初めて起動した際に表示される「開発元を検証できません」、ネットワーク拡張機能の未許可、キーチェーンによる繰り返しのパスワード要求などを整理し、システム設定から順に許可する方法を紹介します。
システム権限の説明を見る →クライアントが接続済みでもブラウザーからアクセスできない場合に、システムプロキシの反映、DNSの名前解決、ルールの適用、接続先ノードの4段階で確認します。各段階で状態を検証する方法も紹介します。
接続トラブルの確認リストを読む →