Windows
Clash Plus をおすすめトレイからの管理、システムプロキシ、ルールの切り替えが必要なデスクトップユーザーに適しています。ダウンロードページではClash PlusやClash Verge Revなどを選べます。まず動作要件を確認し、環境に合ったインストーラーを選んでください。TUNを使う場合は、クライアントのサービスインストール案内と管理者権限の許可を確認し、複数のプロキシサービスを同時に動かさないようにしましょう。
Clashの利用では、クライアント選び、サブスクリプションの読み込み、ルール振り分けの確認がポイントです。クライアントは設定画面を提供し、コアがプロキシ、ルール、DNSを処理します。システムプロキシとTUNは接続をコアに取り込む方法を決め、ポリシーグループは接続の出口を決めます。
サブスクリプションはクライアントのインストーラーではなく、インストールしただけで利用可能な接続先が用意されるわけでもありません。まず利用権のあるサブスクリプション、または自分で用意した設定を準備し、形式とクライアントの互換性を確認してください。初回接続ではネットワーク設定を初期状態のままにして、ルールモードから動作を確認するのがおすすめです。システムプロキシに従わないアプリの通信も取り込みたい場合は、TUNとDNSの設定を確認しましょう。
まずOSを確認し、次にCPUアーキテクチャを確認してください。デスクトップではインストーラーの形式とサービスの権限を、モバイルではVPNの許可とバックグラウンド設定を確認します。以下のリンクは各プラットフォームのダウンロードページへ移動するもので、インストーラーを直接ダウンロードするものではありません。
トレイからの管理、システムプロキシ、ルールの切り替えが必要なデスクトップユーザーに適しています。ダウンロードページではClash PlusやClash Verge Revなどを選べます。まず動作要件を確認し、環境に合ったインストーラーを選んでください。TUNを使う場合は、クライアントのサービスインストール案内と管理者権限の許可を確認し、複数のプロキシサービスを同時に動かさないようにしましょう。
「このMacについて」でApple SiliconかIntelかを確認し、対応するアーキテクチャを選びます。初回起動時は、システムの案内に従ってネットワーク拡張機能や補助サービスの権限を許可してください。システムプロキシの影響を受けるのは、プロキシ設定に従うアプリが中心です。ほかの通信も処理する場合は、ルーティング、DNS、クライアントのTUN対応状況をあわせて確認しましょう。
初回接続時に、システムのVPN利用を許可する必要があります。画面ロック後に切断される場合は、サブスクリプションを何度も変更するのではなく、バッテリー最適化、バックグラウンド動作、メーカー独自の自動起動設定を確認してください。アプリごとのプロキシ設定でVPNを経由するアプリを選べます。VPNトンネルを使うほかのアプリと併用する場合は、システム上でVPN接続を競合していないか確認しましょう。
App StoreでClash Plusの対応要件とアプリの説明を確認してください。公式サイトは clashplus.io です。サブスクリプションを追加したら、アプリの案内に従ってVPN構成を許可し、ポリシーを選んで接続します。デスクトップ向けガイドのサービスインストール、待ち受けポート、システムプロキシの設定をiOSにそのまま当てはめず、アプリの画面に従って操作してください。
デスクトップではClash Verge RevやFlClashから選び、ディストリビューションのパッケージ形式とデスクトップ環境に応じて依存関係を確認してください。サーバーやルーターなど、デスクトップ環境のない機器では、コアのページでmihomoを確認しましょう。コマンドラインで動かす場合は、設定ディレクトリ、サービス権限、ログ、起動時の自動実行を自分で管理する必要があります。デスクトップ版のスイッチ設定をそのまま流用するだけでは不十分です。
クライアントを乗り換える前に、設定とローカルのオーバーライドをバックアップしてください。同じサブスクリプションを複数のクライアントに読み込めますが、ポリシーグループ名、対応するプロトコル項目、ネットワーク権限は異なる場合があります。以前のクライアントのローカル設定がサブスクリプションと一緒に移行されるとは限りません。読み込み後、現在のモードとデフォルトのポリシーを確認しましょう。
すべてのクライアントを見る →設定例を通して、それぞれの項目の役割を確認します。ここで示すのは項目の説明であり、プロキシノードやポリシーグループを含む完全なサブスクリプションの代わりにはなりません。既存の設定に追加する前に、コアの対応状況とクライアントのオーバーライド方法を確認してください。
8秒ごとにテーマを切り替えます。クリック、キー操作、フォーカス後は停止します。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
# 完全な設定にはプロキシとポリシーグループの定義も必要
# リモート設定を更新する前にローカルのオーバーライドを保存
サブスクリプションURLの応答は、YAML形式の完全な設定の場合もあれば、ノード一覧だけの場合もあります。読み込み後、利用可能なポリシーグループが表示されるか、また現在どの設定が有効かを確認してください。リモート更新では通常、サーバー側の内容が再読み込みされます。ダウンロードしたファイルを直接編集すると、次回更新時に変更が失われるおそれがあります。ルール、ポート、DNSなど、継続して使いたい変更には、クライアントが提供するオーバーライド機能を優先して使いましょう。オーバーライドの構文やマージ順序はクライアントによって異なるため、移行時はサブスクリプションURLをコピーするだけでなく、項目ごとに確認が必要です。
サブスクリプションの読み込み手順を見る →rules:
- DOMAIN-SUFFIX,github.com,Proxy
- DOMAIN-KEYWORD,ads,REJECT
- GEOIP,CN,DIRECT
- MATCH,Proxy
# Proxy は既存のポリシーまたはポリシーグループ名を指定
# 範囲の広いキーワードルールは誤判定の原因になることがある
ルールモードでは、リストの上から順に接続を照合し、最初に一致したルールで指定されたポリシーに振り分けます。ドメインサフィックスルールは対象サイトを明確に指定する場合に、IPルールは接続先アドレスで判定する場合に適しています。どのルールにも一致しない接続を処理するMATCHは最後に置きます。例のProxyは任意のポリシー名で、設定内にある名前と一致させる必要があります。一部のサイトで問題が起きたら、まず接続ログで適用されたルールを確認し、より具体的なルールを汎用ルールより前に置いてください。グローバルモードに切り替えるより、ほかの接続の直接接続を維持しやすく、変更の理由も追いやすくなります。
ルールセットの管理を見る →proxy-groups:
- name: Default
type: select
proxies:
- DIRECT
- REJECT
rules:
- MATCH,Default
ポリシーグループを使うと、ルールと実際の接続先を分けて管理できます。ルールからグループ名を参照し、グループ内でノード、別のポリシーグループ、または組み込みポリシーを選べるため、接続先を変える際にルール全体を変更する必要がありません。selectは手動選択に使います。url-testやfallbackでは、検査先のURLや動作の設定も必要です。グループ名は重複させず、参照関係が循環しないようにしてください。ここでは構造の例として組み込みポリシーを使っており、プロキシノードは含まれていません。実際にはサブスクリプション内のノードやプロバイダーを参照し、自動選択が対象サイトの利用要件に合うか確認してください。
ポリシーグループの設定を見る →dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
# ネットワーク環境に応じて上流DNSサーバーも設定
# DNSの取り込みとルーティング設定を組み合わせる
Fake-IPは合成アドレスを使ってドメインと接続を関連付け、接続を受け取ったときにコアがドメイン情報を保持できるようにします。単独で速度を上げる機能ではなく、DNSの取り込み、上流DNS、ルーティングと組み合わせて設定する必要があります。LAN内サービスや実アドレスを必要とするアプリに問題が起きたら、まずフィルター対象と名前解決の経路を確認してください。DNSを変更した後は、OSやアプリのキャッシュにも注意が必要です。ネットワークによって到達可能な上流DNSは異なるため、アドレスをそのまま流用する前に、接続できるか、プロキシサーバーのドメインをどう名前解決するかを確認しましょう。
Fake-IP と DNS の用語を見る →tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
# 対応するシステム権限とルーティング機能が必要
TUNは仮想ネットワークインターフェースを使い、対応する経路に入る接続を受け取ります。システムプロキシ設定を参照しないアプリにも適しています。有効にする前に、クライアントのサービス権限を確認し、ほかのVPN、仮想ネットワークインターフェース、セキュリティソフトがルーティングに与える影響も確認してください。TUNを有効にしても、すべての接続が強制的にプロキシへ送られるわけではありません。最終的な出口はモード、ルール、ポリシーグループで決まります。LANに接続できない、またはDNSに異常がある場合は、まずログを保存してから元の設定に戻して検証してください。モバイルでは通常、システムのVPNインターフェースを通じて通信を取り込むため、画面上の項目はデスクトップ版のTUN設定と完全には対応しません。
TUN とルーティングの説明を見る →mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
# mixed-port:アプリ向けプロキシの接続口
# external-controller:管理用インターフェース
# サンプルのパスワードは自分で生成した値に置き換える
外部コントローラーは、クライアントの画面やコントロールパネルが状態を取得したりポリシーを切り替えたりするためのインターフェースです。アプリが使う混合プロキシポートとは役割が異なり、同じポートで待ち受けることはできません。ローカルからのみ操作する場合は、ループバックアドレスにバインドし、個別のアクセスパスワードを設定して、管理用の入口をLANやインターネットに直接公開しないでください。画面で接続失敗と表示されたら、まずアドレス、ポート、認証設定を確認し、次にコアが起動しているかを確認します。サブスクリプションやログには機密情報が含まれる場合があります。スクリーンショットを共有したり設定を公開したりする前に、個人用リンクや認証情報を削除してください。
外部コントローラーの説明を見る →クライアント名、コアの機能、サブスクリプションの内容はそれぞれ別の要素です。選ぶ際は、メンテナンス状況、対応する設定項目、設定の入手元を個別に確認し、画面上の名称だけで互換性を判断しないでください。
Clashのエコシステムには、設定、ルール、プロキシプロトコルを扱うさまざまなクライアントがあります。mihomoは関連するコアの機能を引き継ぎ、さらに拡張しています。プロジェクトは以前Clash Metaという名称を使用していたため、ガイド内ではMetaやmihomoなど複数の呼び方が登場します。GUIクライアントはコアの上に、サブスクリプション管理、ポリシー選択、システムプロキシ、ログの画面を提供します。同じGUIプロジェクトでも、開発状況に応じて内蔵するコアが更新される場合があります。ソフトウェアを比較する際は、クライアントとコアの両方の説明を確認してください。
オープンソースプロジェクトの動作は、ソースコード、設定ドキュメント、課題の議論から確認できます。このサイトでは日本語でダウンロード先と操作方法を案内していますが、サードパーティ製クライアントを同じ開発チームの製品として扱ったり、特定の画面の機能をエコシステム全体の共通機能とみなしたりはしません。設定項目の意味を確認する場合は、利用中のコアのドキュメントを優先してください。ボタンの場所を確認する場合は、該当するクライアントの説明を参照します。両方を照らし合わせることで、原因が設定、システムによる通信の取り込み、画面上の操作のどこにあるか判断できます。
サブスクリプションの提供元は、更新時にノード名、ポリシーグループ、ルールを変更することがあります。クライアントに保存された選択状態はこれらの名前に依存するため、名前が変わると選び直しが必要になる場合があります。更新前に正常に動作している設定を保存し、更新後はルールモードが維持されているか、ポリシーグループに有効な出口があるか、重要なドメインに想定どおりのルールが適用されているか確認してください。設定管理画面に複数のサブスクリプションを保存している場合は、最後に読み込んだものだけでなく、実際に有効な設定を確認しましょう。
サブスクリプションURLには通常、アクセス用の認証情報が含まれるため、個人情報として安全に管理してください。URL全体を公開の質問欄に貼ったり、個人用サブスクリプションを含む設定を公開リポジトリに登録したりしないでください。形式変換サービスは入力したリンクや設定内容を扱うため、利用前にデータの処理方法を確認しましょう。可能であれば、管理された環境で変換してください。ノード一覧、共有リンク、完全なYAMLでは含まれる情報が異なります。また、変換に成功しても、利用者に合ったルールやポリシーグループが自動で補われるとは限りません。
クライアントの更新とサブスクリプションの更新は別のものです。クライアントを更新すると、コア、権限の要求、設定の解析方法が変わる可能性があります。一方、サブスクリプションの更新で主に変わるのはリモート設定の内容です。更新後に問題が起きたら、まずどの層を変更したか記録し、ログに明確なエラーがないか確認してください。ポート競合なら待ち受けプロセスを特定し、設定の解析エラーなら項目やインデントを確認します。一部のサイトだけ不具合がある場合は、適用されたルールとDNSを確認しましょう。手当たり次第に再インストールするより、エラーの種類に応じて調べるほうが効果的です。
新しいクライアントに移行する際は、まず古いクライアントのシステムプロキシとバックグラウンドサービスを無効にしてから、設定を読み込んでテストするのがおすすめです。動作を確認してから起動時の自動実行を有効にし、複数のクライアントがプロキシやルーティングを繰り返し変更するのを防ぎましょう。テストでは、対象のWebサイトやアプリを明確にし、通常のブラウザー、システムプロキシに従わないアプリ、LAN内サービスそれぞれの動作を確認してください。接続ログで振り分け結果は確認できますが、一度のテストだけで、すべてのアプリの通信が取り込まれたと判断しないでください。
利用権のあるサブスクリプション、または自分で用意したプロキシ設定が必要です。クライアントは設定を読み込んで実行しますが、接続先を自動で提供するものではありません。まずサブスクリプションが対応形式で返されるか確認し、読み込んでからポリシーを選択してください。ノードしか表示されずルールがない場合は、完全な設定ではなくノード一覧を読み込んだ可能性があります。クライアントの対応方法に従って、ポリシーとルールを追加してください。初期設定の手順をすべて見る →
初期設定では、まずルールモードを使ってサブスクリプションとポリシーが機能するか確認してください。グローバルモードは接続先の選択を変えますが、すべてのアプリの通信がコアに入るわけではありません。TUNは主に通信を取り込む仕組みで、有効にした後もルールによる振り分けができます。「接続がクライアントに入っているか」と「入った接続がどこへ出ていくか」を分けて考えてから、変更する設定を決めましょう。モードとネットワークスタックの用語を見る →
リモート設定が再読み込みされると、直接編集したサブスクリプションファイルが置き換えられることがあります。保持したい変更は、クライアントが正式に対応するオーバーライド、スクリプト、マージ機能に設定し、適用順序も確認してください。リストの追加や置き換えの動作はソフトウェアによって異なります。特にルールの順序やポリシーグループの参照は、保存完了の表示だけで判断できません。ローカルオーバーライドとマージの説明を読む →
OS、クライアント名、現在のモード、TUNの有効・無効、ログに最初に出た関連エラーを記録してください。すべての接続に失敗するのか、特定のアプリだけに問題があるのかを説明し、変更前後の設定の違いも残します。スクリーンショットを共有する前に、サブスクリプションURL、プロキシの認証情報、コントローラーのパスワードを削除してください。個人情報を含む設定全体を公開しないでください。ヘルプセンターへ →
設定ファイルの構造、LAN内共有、サブスクリプションの形式について、さらに詳しく解説します。各項目の関係と操作上の注意点を説明しているため、初回の読み込みを終えた後、目的に合わせてご覧ください。
完全なconfig.yamlを項目ごとに分解し、トップレベルの項目、dns、proxies、proxy-groups、rule-providers、rulesの役割と記述順を解説します。各セクションの役割を整理してから、どの階層を変更すべきか判断しましょう。
記事を読む →混合ポートの仕組みから、allow-lanとbind-addressの設定、ファイアウォールの許可、ほかの機器でプロキシアドレスを設定する手順まで解説します。プロキシ共有用の接続口と管理インターフェースを区別し、機器を接続するためのネットワーク条件を確認できます。
記事を読む →サブスクリプションでよく使われる形式を解説し、mihomoがそのまま認識できるもの、変換が必要なもの、自分で変換する際に注意すべきルールやグループの問題を紹介します。読み込む前にデータ形式を見分け、互換性の問題による試行錯誤を減らしましょう。
記事を読む →