Windows
Windowsデバイスを優先して案内します。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、アーカイブ済みクライアントを比較できます。インストール前にGUIクライアントと単体コアを区別してください。
ダウンロードへ
OPEN SOURCE CLIENT ROUTE
Clash Windows版
Clash Windows版
クライアントのダウンロードとルール分岐設定
Windowsを中心に、デスクトップ・モバイルの各プラットフォームをカバー。まずクライアントを選び、サブスクリプションのインポート、ルール分岐、Fake-IP DNSを具体的なメニューと設定項目に沿って進めます。
完全無料
オープンソース
日本語ドキュメント
ルールモード
PLATFORMS: WINDOWS / MACOS / ANDROID / IOS / LINUX
CORE: MIHOMO
MODE: RULE / GLOBAL / DIRECT
CONFIG: YAML
PLATFORM ENTRY
システム別にクライアントをダウンロード
トップページではプラットフォームへの振り分けに絞り、インストーラーの一覧は掲載していません。対応するシステムを選ぶとダウンロードページへ移動し、そのプラットフォームに自動で切り替わります。クライアントの種類、対応アーキテクチャ、メンテナンス状況、インストール方法もそこで確認できます。まず端末のOSを確かめてからGUIクライアントを選ぶほうが、合わないパッケージを入手してやり直すより効率的です。
macOS
Apple SiliconとIntelに合わせてパッケージのアーキテクチャを選びます。GUIクライアントは日常のメニューバー操作に向き、単体コアはターミナル、自動化、サービス運用に適しています。
ダウンロードへAndroid
スマートフォンやタブレット向けです。ダウンロード前に端末のアーキテクチャとOSの制限を確認し、サブスクリプションをインポートしたらローカルVPN接続の許可も必要です。OSのバッテリー設定がバックグラウンド接続に影響する場合もあります。
ダウンロードへiOS
アプリストアからClash Plusを入手します。インストール後、サブスクリプションURLから設定をインポートし、用途に応じてプロキシグループを選択します。ネットワーク設定の許可を求められたら、内容を確認して承認してください。
ダウンロードへLinux
デスクトップ環境ではGUIクライアント、サーバー・ソフトルーター・コンテナ環境では通常mihomoコアを直接使います。まずCPUアーキテクチャを確認し、debパッケージか圧縮ファイルかを選びます。
ダウンロードへ
WINDOW PANE ROUTER
4つの設定ポイントを分けて理解
Clashで難しいのは、スイッチ操作そのものよりも、設定ファイル、プロキシグループ、ルール、DNSが互いに影響する点です。実際の確認手順に沿って分解します。まず通信がどのルールに一致したかを確認し、次にプロキシグループの選択、最後にDNSとサブスクリプションの更新を確認します。左側でテーマを切り替え、右側には実際のYAMLやルール断片を表示します。
ルール分岐：一致順がそのまま実行順になる
ルールモードではリクエストを上から順に確認し、一致するとそれ以降の判定を停止します。ドメインルールは特定のサービスに適し、GEOIPは地域情報に基づく処理に使えます。最後にMATCHで残りの通信を受けます。設定では、範囲が具体的なルールを前に、フォールバックとなるルールを最後に置いてください。広すぎるルールを先に置くと、通信を誤って先取りします。全体スイッチだけを備えたクライアントと違い、ClashではDIRECT、PROXY、REJECTを1つの読みやすいルール表に記述でき、接続ログから一致した項目も追跡できます。
DOMAIN-SUFFIX,github.com,PROXY
DOMAIN-SUFFIX,local,DIRECT
GEOIP,CN,DIRECT
MATCH,Fallbackプロキシグループ：行き先を決めるのはルール、使うノードを決めるのはグループ
ルール内のPROXYは、特定のノードではなくプロキシグループ名であることが一般的です。selectは手動選択、url-testはテスト結果による自動選択、fallbackは利用可能性に応じた順次切り替えに適しています。設定時は、rulesが参照するグループ名が実際に存在するか、グループ内のノードや子グループが揃っているかを確認してください。用途の分類と個別ノードを分離すれば、サブスクリプションのノードを入れ替えてもルール全体を書き直す必要がありません。複数設定を長期運用するうえで、扱いやすい構成です。
proxy-groups:
- name: PROXY
type: select
proxies:
- Auto
- DIRECT
- name: Auto
type: url-testFake-IP DNS：ドメインのマッピングと接続処理を連動させる
Fake-IPモードでは、まず予約アドレスを返し、接続時にコアが元のドメインを復元してルールを適用します。ドメインルールによる分岐を安定させられる一方、システムDNS、クライアントの待受ポート、ルール設定の整合性が必要です。LAN内の端末に異常が出る、特定のアプリだけ接続できない、名前解決がルールを迂回するといった場合は、ノードを何度も交換する前にfake-ip-filter、nameserver、respect-rulesを確認してください。DNSの問題とプロキシノードの問題は分けて診断します。
dns:
enable: true
enhanced-mode: fake-ip
respect-rules: true
fake-ip-filter:
- "*.lan"ルールによるブロック：明確なリクエストをルーティング層で停止
REJECTは、条件に一致する接続を直接拒否するために使います。確認済みのトラッキングドメイン、テレメトリーのエンドポイント、アクセスしたくない宛先などに適しています。ルールの範囲は絞り、正確なドメインやメンテナンスされたルールセットを優先してください。広すぎるサフィックスは、ログイン、決済、メッセージサービスまで誤って遮断するおそれがあります。ページの一部だけ読み込めない場合は、まず接続ログでREJECTへの一致を確認し、一時的にルールを切り替えて検証します。ブロックは追跡可能で取り消せる状態にし、曖昧なルールを積み重ねてブラックボックス化しないことが重要です。
DOMAIN,telemetry.example,REJECT
DOMAIN-SUFFIX,tracker.example,REJECT
DOMAIN-SUFFIX,service.example,PROXY
MATCH,Fallbackサブスクリプション設定：更新されるのはProfileであり、個別ノードではない
サブスクリプションURLは通常、ノード、プロキシグループ、ルール、DNSを含む完全な設定を返します。インポート後は更新結果を確認し、現在有効なProfileがどれかを確かめてください。「更新に成功した」ことと「新しい設定へ切り替わった」ことは別です。複数のサブスクリプションを使う場合は、提供元や用途が分かる名前を付け、デフォルト名のままにしないでください。リモート設定を編集する前に、次回更新時にローカル変更が上書きされるかどうかも確認します。長期的なカスタマイズには、オーバーライド層とリモートサブスクリプションを分けて管理すると安全です。
profile:
store-selected: true
store-fake-ip: true
mode: rule
log-level: info
OPEN SOURCE LINEAGE
オープンソースのエコシステムとコアの関係
実際の利用場面で「Clash」は、ルール体系、設定形式、コアの派生版、複数のGUIクライアントを同時に指すことがあります。これらの層を分けて考えることで、解説が画面操作、YAML項目、コアの機能のどれを扱っているのか判断できます。
オリジナル版Clashが築いた設定モデル
オリジナル版Clashは、プロキシノード、プロキシグループ、ルーティングルール、DNSを1つの設定モデルにまとめました。多くのクライアントがこの考え方を引き継いでいるため、現在もproxies、proxy-groups、rulesといったおなじみの項目が使われています。プロジェクトの歴史を知れば設定形式の理由は分かりますが、インストール先は「Clash」という名前だけで決めず、クライアントの保守状況、採用コアの派生元、対象システムとの互換性まで確認してください。
GUIクライアントは操作を、コアは実行を担当
GUIクライアントはサブスクリプション管理、システムプロキシの切り替え、プロキシグループの選択、接続ログ、設定画面を提供します。設定の解析、接続処理、ルールの実行を担うのは実際のコアです。2つのクライアントで画面がまったく違っていても、近いコアと互換性のある設定を使っていれば、基盤となる分岐ロジックはよく似ている場合があります。逆に、画面に同名の項目があっても、コアの機能、設定の互換範囲、更新頻度まで同じとは限りません。
mihomoがMetaの機能を継承・拡張
mihomoは現在のClashエコシステムで広く使われている活発なコアです。Clash.Metaの系譜を受け継ぎ、プロトコル、ルール、DNS、透過プロキシの機能を拡張し続けています。デスクトップでは通常、mihomoを組み込んだGUIクライアントから利用します。サーバー、ルーター、自動化環境ではコアを直接実行することもあります。選ぶ際はまずGUIが必要かを判断し、次にプロトコルと設定機能を確認してください。コアの圧縮ファイルをデスクトップ用インストーラーと混同しないようにしましょう。
更新はクライアント、コア、サブスクリプションの3系統に分けて考える
クライアントの更新は画面やOS連携を修正し、コアの更新はプロトコル、ルール、DNSの挙動に影響します。サブスクリプションの更新ではノードとリモート設定が変わります。3つは同じ操作ではありません。障害が起きたら、最近の変更がどの層で発生したかを記録してください。クライアントを変更したのか、コアを更新したのか、サブスクリプションを再取得したのかが分かれば、プログラムのロールバック、コアの切り替え、Profileの復元のどれを行うべきか判断できます。すべてをノード障害と決めつけずに済みます。
QUICK DIAGNOSIS
よくある質問
症状ごとに層を分けて確認し、いきなり再インストールしないでください。クライアント画面、サブスクリプション設定、システムプロキシ、DNS、ノード経路を個別に確認すると、故障箇所を早く特定できます。
サブスクリプションをインポートしてもノードが表示されない？
まずProfileの更新通知と返却内容を確認し、現在有効なのがインポートしたばかりの設定か確かめます。サブスクリプションURLの失効、形式の非互換、空のリモート内容、更新後にProfileを切り替えていないことなど、原因が違っても一覧が空白になる場合があります。更新ボタンを繰り返し押す前に、エラーメッセージを読んでください。
インストールと設定のQ&Aを見る →Clashを有効にするとインターネットに接続できない？
設定が正常に読み込まれたか、システムプロキシまたはTUNが有効か、プロキシグループで利用可能な項目が選ばれているか、接続ログがREJECTに一致していないかを順に確認します。すべてのリクエストが失敗する場合は、DIRECTに切り替えて基準テストを行い、プロキシ経路と端末側のネットワークのどちらに問題があるか判断します。
トラブルシューティングを見る →ルールモードとグローバルモードはどう選ぶ？
日常利用では、設定に応じてDIRECT、PROXY、REJECTを振り分けるルールモードを優先します。グローバルモードはプロキシ経路の一時的な検証には向きますが、長期的な判断には適しません。ダイレクトモードではローカルネットワークを確認できます。モード切り替えは診断のための手段であり、強いほど優れているというものではありません。
基本操作を見る →遅延が低いのに、なぜ通信が重い？
クライアントの遅延テストは通常、テスト先までの1回のハンドシェイク経路しか示さず、継続的な帯域幅、パケットロス、混雑、接続先サイトまでの経路を表しません。ノード選びでは地域、倍率、プロトコル、実際の用途でのテストも考慮してください。単一のミリ秒値は初期選別に使える程度です。
遅延の仕組みを見る →
FIELD NOTES
最新の利用ノート
「万能パラメータ」を並べるのではなく、1つの具体的な問題を軸に、設定構造、判断の順序、誤解しやすい概念を詳しく解説します。以下の3記事では、サブスクリプション形式、ノード選び、遅延テストを扱い、日常利用で起こりやすい3種類の判断ミスに対応します。
Clashのサブスクリプション形式を解説：base64、YAML、汎用形式の違いと相互変換
Clash YAML、base64の共有内容、汎用サブスクリプション構造を比較し、変換時に失われる可能性があるプロキシグループ、ルール、拡張項目と、クライアント移行前に確認すべき互換性を解説します。
続きを読む →Clashのノード選び：遅延、倍率、地域、プロトコルから実用的に判断する
遅延は初期選別に使い、倍率は通信コストを左右し、地域はコンテンツと経路に影響し、プロトコルは安定性と端末への負荷に関係します。最低値だけを見るより信頼できる選択手順を紹介します。
続きを読む →Clashの遅延テストの数値はどう算出される？60msのノードでも動画が止まる理由
クライアントが行う遅延テストの実態を分解し、ハンドシェイクの往復時間、継続スループット、パケットロス、接続先サイトまでの経路を区別します。見栄えのよい数値でも、高負荷時の安定性を保証するものではありません。
続きを読む →