サブスクリプション、システムプロキシ、TUNをデスクトップ画面から管理したい方に適しています。デバイスのアーキテクチャとシステム要件を確認し、クライアントの手順に沿ってインストールしてください。ブラウザーはシステムプロキシを利用できても、ターミナルや一部のゲームは利用しない場合があります。より広い範囲の通信を制御するには、TUNの権限とルーティング設定を確認しましょう。Clash for Windowsは開発が終了しているため、ダウンロードページではアーカイブ版として個別に表示しています。
mihomoコア · 全プラットフォーム対応クライアント
Clash 正規版公式サイト クライアントのダウンロードとルール設定
サブスクリプションの読み込みからルールによる振り分けまで、プラットフォームに合ったクライアントを選び、通信経路に沿って設定を確認できます。
オープンソースコア
日本語ドキュメント
手順に沿ったトラブル対処
CLIENT SELECTION
Clashのダウンロード：プラットフォーム別
OSとプロセッサのアーキテクチャを確認してから、クライアントを選びましょう。ダウンロードページでは、インストール先、システム要件、メンテナンス状況をまとめて確認できます。
デスクトップとモバイルでは操作画面が異なりますが、基本的な設定手順は共通です。利用可能なサブスクリプションを読み込み、設定を有効にして、プロキシグループと通信の制御方法を選びます。初めてインストールする場合は、まずClash Plusのプラットフォーム別案内をご覧ください。LinuxではClash Verge RevとFlClashを比較できます。現在のクライアントが問題なく使えているなら、名前が違うという理由だけで設定を移行する必要はありません。
Apple SiliconまたはIntelプロセッサに合ったインストーラーを選んでください。初回起動時は、システムが求めるアクセス許可を与えてからサブスクリプションを読み込みます。権限の問題をノードの不具合と誤認しないためです。システムプロキシを使う場合は、ネットワーク環境やほかのネットワークツールが設定を上書きしていないか確認しましょう。クライアントの終了後は、システムプロキシが元に戻っていることも確認してください。ClashX Metaは開発が終了しているため、今後の互換性も考慮して選びましょう。
インストール前にプロセッサのアーキテクチャを確認し、初回起動時にVPN接続を許可してください。Androidでは通常、VPNサービスが通信を制御するため、デスクトップのシステムプロキシと同じ手順は使えません。画面ロック後に接続が切れる場合は、ノードを変更する前にバッテリー最適化、バックグラウンド実行の権限、ほかのVPNアプリとの競合を確認しましょう。アプリごとに通信を振り分ける場合は、クライアントが該当機能に対応しているか確認してください。
ダウンロードページからClash PlusのApp Storeページに進み、公式サイト clashplus.io もご確認ください。インストール後、システムの案内に従ってVPN構成の追加を許可し、クライアントに対応するサブスクリプションを読み込みます。アプリによって対応するルール構文は異なるため、設定ファイルの拡張子だけでは互換性を判断できません。読み込みに失敗した場合は、サブスクリプションの形式と具体的なエラーを確認してください。
デスクトップ環境では、まずGUIクライアントを選びましょう。サーバーやルーターでは、mihomoの単独運用も選択肢になります。インストール時は、ディストリビューションのパッケージ形式、プロセッサのアーキテクチャ、必要な権限を確認してください。コマンドラインプログラムはデスクトップのシステムプロキシを参照しない場合があります。systemdで管理する場合は、設定ディレクトリ、実行ユーザー、ログの確認先もデスクトップ起動時とは異なるため、実際のサービス環境に沿って対処しましょう。
RULE ENGINE
Clashのルールによる通信振り分け
まず具体的なドメインのルールを記述し、その後に地域別のルールと最終ルールを配置します。mihomoは通常、ルールを上から順に照合し、最初に一致したルールの指定先へ通信を渡します。具体的なドメインを広範なルールより前に置くことで、先に振り分けられるのを防げます。設定内のポリシー名は、定義済みのプロキシグループ名と一致させてください。YAMLの構文が正しくても、名前が一致しなければ読み込めない場合があります。
普段使いでは、動作確認済みの設定を残し、変更が必要な項目だけを調整しましょう。変更後はモードボタンの点灯だけで判断せず、接続ログで適用されたルールと最終的な接続先を確認してください。Fake-IPは合成アドレスを使ってドメインとの対応関係を保持する仕組みで、すべてのリクエストを必ずプロキシ経由にするわけではありません。実際の通信経路は、ルール、DNS、通信の制御範囲によって決まります。右側の設定例はルールの順序を示すものです。既存の完全な設定に追加して使用してください。
ルール設定の手順を見る →config.yaml / rules
# PROXY は完全な設定内で定義する必要があります
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXYドメインルール → 地域別ルール → 最終ポリシー
PROXY GROUPS
プロキシグループとノードの選び方
ルールは通信をどのグループに渡すかを決め、プロキシグループはどの接続先を使うかを決めます。手動選択グループは、特定の地域を固定したい場合やサービスのセッションを維持したい場合に適しています。自動テストグループは測定結果に基づいて接続先を選び、フェイルオーバーグループは設定順に利用可能な接続先を探します。自動切り替えにはそれぞれ条件があり、どんな状況でも最速のノードが選ばれるわけではありません。
まず手動選択グループでノードの接続を確認してから、自動選択を設定すると、設定ミスと速度測定の問題を切り分けやすくなります。ノードを比較する際は、接続先の地域、通信量の倍率、利用するサービスへの到達性、実際の通信品質を確認しましょう。測定した遅延は測定先やネットワークの変動に左右され、すべてのサイトでの速度を示すものではありません。ログイン状態を維持したいアプリでは、最低遅延を頻繁に追うより、安定した接続先が適していることがあります。動作確認済みの予備も用意しておきましょう。
3種類の自動プロキシグループを比較 →まず単一の接続先を確認し、その後で自動選択を設定します。
TRAFFIC CAPTURE
TUNとシステムプロキシの設定
システムプロキシは、OSのプロキシ設定を参照するアプリに適しています。設定が簡単で、どこから通信がコアに入るかも確認しやすい方法です。TUNは仮想ネットワークインターフェースを通じて、ルーティング対象の通信を制御します。システムプロキシを利用しないアプリにも対応できますが、権限、DNS、ルーティング、ほかのネットワークソフトへの影響を考慮する必要があります。どちらも通信の入口であり、ルールモードやグローバルモードと同じ種類の設定ではありません。
初めて設定するときは、まずシステムプロキシでブラウザーの接続を確認し、必要に応じてTUNを有効にしてください。ブラウザーはつながるのにターミナルが直接接続する場合は、ターミナルがプロキシ環境変数を参照しているか確認しましょう。すぐにサブスクリプションを変更したり、クライアントを再インストールしたりする必要はありません。TUNの有効化後にLANへ接続できなくなった場合は、ノードを何度も切り替えるのではなく、ルーティングの除外設定とDNSを確認してください。右側は通信の入口を説明する静的な設定例で、現在のデバイスの動作状態を示すものではありません。
システムプロキシが機能しない場合の対処 →TRAFFIC / 設定例
システムプロキシオンの例
TUNモードオフの例
実行モードrule
まずアプリの通信がコアに入っているかを確認し、その後にルールの適用状況を調べます。
PROFILE MAINTENANCE
サブスクリプションの更新と設定の管理
サブスクリプションを読み込んだら、対象の設定が選択されていることを確認し、ノードとプロキシグループが表示されるかを確認しましょう。更新の成功は、内容を取得して処理できたことを示すだけで、すべてのノードが接続可能とは限りません。ノードを選び、目的のサービスにアクセスできるか確認してください。自動更新の間隔は、サービス提供元の要件、デバイスの消費電力、ネットワーク環境を考慮して設定しましょう。頻繁に更新をリクエストする必要はありません。
リモート設定、ローカル上書き、ルールセットは、それぞれ別に更新される場合があります。重要な変更は、次回のサブスクリプション更新で手動編集が上書きされないよう、クライアントの永続的な上書き機能に保存してください。更新後に未対応のフィールドやプロキシグループの不足が見つかった場合は、エラーと直近の正常なバックアップを残し、互換性を一つずつ確認しましょう。下の4項目は動作の違いを説明するものです。最初の3つは照合方法を決め、TUNは通信を制御する範囲を変えます。実際の画面では、通常これらを別々に設定します。
サブスクリプションの読み込みと接続確認を見る →PROFILE / 設定項目の説明
自動更新の間隔用途に合わせて設定
ローカル上書き個別に管理
ルール：日常の通信振り分け
コアに入ったリクエストは、設定内のルールに順番に照合され、対応するプロキシグループまたは直接接続先に振り分けられます。ローカルサービスへの直接接続と、指定した通信先へのプロキシ接続を併用する普段使いに適しています。接続を確認するときは、ログに表示されるルールの種類、ポリシー名、最終的なノードを確認してください。リクエストがコアに入っていなければ、ルールを変更しても反映されません。グローバルモードより細かく通信先を振り分けられる一方、ルールの順序やドメイン情報が重要になります。まずはサブスクリプションの既定ルールを使い、必要なカスタムルールを一つずつ追加すると、変更の原因を特定しやすくなります。
グローバル：接続先をまとめて確認
コアに入ったリクエストをまとめてグローバルポリシーで処理します。ルールによる振り分けの影響を一時的に切り分けるのに便利です。切り替えた後も、グローバルグループでどの接続先を選んでいるか確認してください。デバイス上のすべてのアプリが自動的に制御されるわけではありません。グローバルモードではアクセスでき、ルールモードでは失敗する場合は、適用ルールとプロキシグループを比較しましょう。両方で失敗する場合は、ノード、サブスクリプション、ネットワーク環境を確認してください。テスト後はルールモードに戻し、LANや本来直接接続すべきサービスがプロキシ経由にならないようにしましょう。
直接接続：通常のネットワークを確認
コアに入ったリクエストを直接接続で処理します。通常のネットワークが使えるか、プロキシ経由とローカル接続でアクセスに差があるかを確認するときに便利です。直接接続にしてもクライアントが終了するわけではなく、仮想ネットワークインターフェースが停止するとは限りません。DNSリクエストも、現在のコア設定の影響を受ける場合があります。クライアントを終了すると正常なのに、直接接続モードでは問題が起きる場合は、ノードだけでなくDNSとルーティングも確認してください。通常のネットワークでアクセスできる宛先をテストに使い、終了後は元のモードに戻して、以降の切り分けに影響しないようにしましょう。
TUN：通信の制御範囲を広げる
TUNは仮想ネットワークインターフェースを通じた通信の入口です。ルールモードと併用できますが、ルール照合の第4の方式ではありません。ルーティングの対象となるアプリの通信を制御できますが、その結果はシステム権限、自動ルーティング、DNSのハイジャック、除外設定によって異なります。有効にする前に通常のプロキシ接続を確認し、有効化後はWebページ、ターミナル、LAN機器への接続をそれぞれ確認してください。競合が発生した場合は、ほかのVPNや同種の通信制御ツールを一時停止しましょう。管理者権限が必要な場合は、クライアントの案内に従ってください。ネットワークの問題をすべてサブスクリプション設定のせいにする必要はありません。
OPEN SOURCE / MIHOMO CORE
オープンソースコアとクライアントのエコシステム
画面、コア、サービスの提供元を区別すると、各機能の担当と更新の影響を把握できます。
Clash 正規版公式サイト
クライアントのダウンロードと技術情報
Clash、mihomo、GUIクライアント
Clashのエコシステムには、過去のプロジェクト、継続的に開発されるコアの派生版、コアを基盤とするGUIクライアントがあります。mihomoはエコシステム内のオープンソースプロキシコアで、ネットワーク接続、ルール照合、DNS、ポリシーの処理を担います。Clash Verge Revなどのクライアントは、サブスクリプション管理、トレイ操作、システムプロキシ、権限連携などの機能を提供します。画面上の名称が違っても、基盤となるルールがすべて異なるとは限りません。一方、似た画面のクライアントでも、同じ機能に対応するとは限りません。
ガイドを読むときは、コアの設定項目についての説明か、クライアントのボタン操作についての説明かをまず確認しましょう。コアが対応するパラメーターも、クライアントが正しく渡さなければ機能しません。クライアント独自の便利な設定が、そのクライアントでしか使えない場合もあります。iOSなどのプラットフォームには、それぞれのネットワークインターフェースやアプリの実装による制約があります。デスクトップ向けの機能一覧を、すべてのプラットフォームで共通して使える機能と見なすことはできません。クライアントの比較ガイドでは、ソフトウェア名だけでなく、こうした違いを整理しています。
公開ソースコードから機能の範囲を確認する
オープンソースプロジェクトでは、リポジトリのコード、ドキュメント、課題、変更履歴から機能の変化を追えます。新しいフィールドを読み込めない場合は、使用中のクライアントが採用しているコアと、そのバージョンのドキュメントを確認してから、アップグレードの必要性を判断しましょう。当サイトでは、確認できないダウンロード数や評価を根拠にクライアントを推奨しません。メンテナンス状況、プラットフォームへの対応、設定の互換性、実際の操作手順が、選択時に役立つ情報です。
以下のコマンドはmihomoのソースコードを取得するもので、実装の確認や研究を行う方向けです。クライアントのインストールに必要な作業ではありません。リポジトリをクローンしても、ネットワークが設定されたり、利用可能なサブスクリプションが作成されたりするわけではありません。一般ユーザーはダウンロードページをご覧ください。開発や独自ビルドを行う場合は、リポジトリ内のビルド要件とライセンス情報も確認してください。
更新前に復元可能な設定を保存
クライアント、コア、サブスクリプション、ルールセットは、それぞれ異なるタイミングで更新されます。クライアントの更新は画面やシステム連携の問題に影響し、コアの更新はプロトコルやルールの挙動に影響します。サブスクリプションの更新ではノードやポリシーが変わり、ルールセットの更新では振り分け対象が変わります。一度に変更する対象を一つに絞り、変更後の結果を記録すると、ソフトウェアの再インストール、DNSのリセット、サブスクリプションの変更を同時に行うより原因を特定しやすくなります。
アップグレード前に、現在動作している設定とローカル上書きを保存し、選択中のプロキシグループとシステムプロキシまたはTUNの状態を記録しましょう。更新後は、まず設定を読み込めるかを確認し、次に普段使う宛先とLANへの接続をテストします。問題を報告する際は、OS、クライアント名、再現手順、個人情報を伏せたログを添えてください。サブスクリプションURL、認証情報、個人用ドメインなどの機密情報は削除しましょう。設定全体をそのまま公開したり、トラブル対処のために詳細ログを長期間有効にしたりしないでください。
利用シーン別にクライアントを比較 →CONFIGURATION NOTES
Clashの設定・導入ガイド
プロキシグループやノードの選び方からLinuxでのサービス運用まで、目的に合わせてご覧ください。
まず基本の接続を確認してから、自動切り替えやバックグラウンドでのサービス管理に進みましょう。記事内の設定例はパラメーターの関係を説明するものです。使用時は既存のプロキシグループ名、システム上のディレクトリ、権限に合わせて調整してください。リモート設定全体をそのまま置き換えないでください。
Clashのurl-test・fallback・load-balance：プロキシグループの違いと設定方法
3種類の自動プロキシグループについて、切り替えの仕組み、速度測定のパラメーター、用途を解説。書き換えて使えるproxy-groupsの設定例も紹介します。
プロキシグループの解説を読む →Clashのノード選び：遅延・通信量倍率・地域・プロトコルを比較
測定遅延が低くても、使いやすいとは限りません。通信量倍率、接続先の地域、プロトコル、利用シーンを踏まえて、普段使いと予備のノードを選ぶ方法を紹介します。
ノードの選び方を見る →Linuxにmihomoコアを導入する方法：GUIクライアントとsystemdで管理するCLIの2通り
Ubuntu、Debian、ArchへのGUIクライアントのインストール方法と、systemdでmihomoコアを管理して起動時に自動実行する方法を解説。ディレクトリ構成と権限についても紹介します。
Linuxの導入手順を読む →