Clashエコシステム · クライアントと設定
OSを選んで、サブスクリプションの追加、ルール分岐、DNS設定を確認できます。
CONFIGURATION / 設定ガイド
サブスクリプション、プロキシグループ、ルールの違いを押さえてから、アプリの通信をコアへどう流すか決めましょう。
クライアントはGUI、サブスクリプションの保存、OSとの連携を担い、コアは設定の読み込み、接続の確立、通信の振り分けを行います。以下は設定項目ごとの例で、単独で動作する完全な設定ではありません。使用前に有効なプロキシ定義を組み合わせ、プロキシグループ名とルール内の参照先が一致していることを確認してください。
サブスクリプションURLはリモート設定を取得するためのもので、クライアントのインストーラーではなく、ネットワーク接続を保証するものでもありません。クライアントのサブスクリプション画面にURLを貼り付け、ダウンロード後に設定を選択して、プロキシ一覧が表示されるか確認します。設定全体を取得するサブスクリプションと、プロキシ一覧だけを取得するサブスクリプションは分けて扱いましょう。後者はproxy-providersで読み込み、プロキシグループから参照する必要があります。リモート更新で元ファイルが上書きされる場合があるため、継続して使うルールはクライアントのオーバーライドやマージ設定に記述し、更新のたびに編集し直す事態を避けてください。サブスクリプションには認証情報が含まれるため、URLを共有したり、ログを公開したりする前に必ず隠してください。
Clash Vergeproxy-providers:
remote:
type: http
url: "https://example.com/sub?token=xxxx"
path: ./providers/remote.yaml
interval: 3600プロキシグループは複数の接続先をまとめ、ルールから参照できるようにします。selectは接続先を手動で固定する場合、url-testは指定したテスト先への応答をもとに候補を選ぶ場合、fallbackはリストの優先順に利用可能な接続先を探す場合に適しています。テスト時間は特定のURLとその時点のネットワーク状況を反映するもので、ダウンロード速度とは直接比較できません。まず手動選択で各接続先を確認してから自動切り替えを追加すると、接続先の問題と切り替えロジックの問題を切り分けやすくなります。以下のuseはサブスクリプション側のremote一覧を参照します。設定を統合するときは名前を一致させ、空のプロキシグループにならないよう注意してください。
proxy-groups:
- name: 自動選択
type: url-test
use:
- remote
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50ルールモードでは接続を上から順に調べ、最初に一致したルールのポリシーを適用します。それ以降のルールは確認しません。そのため、完全一致のドメイン、LANのアドレス範囲、特定アプリ向けのルールは、汎用ルールより前に置き、最後にMATCHで残りの通信を処理するのが基本です。DOMAIN-SUFFIXはドメインとそのサブドメインに一致し、IP-CIDRはIPアドレス範囲を扱うため、参照する情報が異なります。設定が正しそうなのに想定どおり動かない場合は、現在のノード名だけで判断せず、接続画面で実際に一致したルールと適用先のポリシーを確認してください。変更後は接続を確立し直しましょう。既存の長時間接続には変更がすぐ反映されないことがあります。
rules:
- DOMAIN-SUFFIX,example.com,自動選択
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,自動選択Fake-IPはドメインに予約済みアドレスを返し、その後の接続でコアがドメイン名を復元してルールを適用します。これにより、ドメイン情報を使った通信の振り分けが可能になります。ただし、単独でDNS漏れを防ぐ機能ではありません。アプリがコアのDNSを使っているか、システムルートがどのように制御されているか、上流DNSへの通信がどの接続先を通るかもあわせて確認してください。実際の名前解決結果を必要とする一部のLANサービスでは例外設定が必要になる場合があります。対象範囲はできるだけ絞りましょう。有効にした後は新しい接続でテストし、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-queryTUNは仮想ネットワークインターフェースを通じて通信を受け取るため、システムプロキシに従わないアプリも対象にできます。一方、クライアントの権限やドライバー、OSのネットワーク拡張が必要です。有効にする前にシステムプロキシで設定を確認し、接続先が使えることを確かめてからルート制御を設定しましょう。他のVPN、仮想マシン、社内ネットワークと併用する場合は、ルートの競合や除外するネットワークを確認してください。複数の通信制御ツールを何度も切り替えるのは避けましょう。例のDNSハイジャックが対象とするのはTUNに入る通常のDNSリクエストです。アプリ内蔵の暗号化DNSは別途確認が必要です。対応するネットワークスタックや権限設定の手順は、各OS向けクライアントの説明を参照してください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53システムプロキシは、アプリのプロキシ通信をローカルの待ち受けポートへ転送します。この設定に従うアプリだけが利用します。mixed-portはHTTPとSOCKSの両方を受け付けます。変更後はクライアントに表示されるシステムプロキシのアドレスも確認してください。OS起動時の自動起動はGUIクライアントの機能で、以下のコア設定項目とは別です。クライアントの起動、コアの起動、プロキシの自動有効化も、それぞれ独立した設定の場合があります。初回設定後は一度再起動し、通知領域のアイコン、コアの状態、システムプロキシの設定が一致しているか確認しましょう。クライアントを終了する前にシステムプロキシを無効にすると、停止したローカルポートを参照し続けるのを防げます。
mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: infoPACKAGES / OS別に選ぶ
OSとCPUアーキテクチャを確認してから、GUIクライアントを選びましょう。
Clashはエコシステムの名称であり、すべてのOSで同じインストーラーを使うわけではありません。クライアントによって画面、コアの更新頻度、OSとの連携方法が異なります。設定項目も、実際に使うコアの対応状況に合わせてください。ダウンロードページではOS別にインストーラー、メンテナンス状況、導入手順を確認できます。クライアントごとの違いはクライアント比較をご覧ください。
まずはClash Plusがおすすめです。Clash Verge Rev、FlClash、Clash Nyanpasuも選べます。インストール前にOSのアーキテクチャと必要なランタイムを確認してください。TUNサービスの権限と通常の起動権限は別々に扱います。
旧クライアントから移行する場合は、まずサブスクリプションとカスタムルールを書き出し、mixed-portと自動起動の設定を確認します。複数のクライアントから同時にシステムプロキシを変更しないでください。
ダウンロードページへApple SiliconかIntelかに合わせて、Clash Plus、Clash Verge Rev、FlClashを選びます。インストール後、OSの案内に従って必要な権限を許可し、メニューバーの状態とプロキシポートを確認してください。
システムプロキシとネットワーク拡張では、必要な権限が異なります。ネットワークに問題が起きたら、まず他のVPNや旧クライアントが起動したままになっていないか確認してから、DNSやTUNの設定を見直してください。
ダウンロードページへまずはClash Plusがおすすめです。Clash Meta for Android、FlClash、Surfboardも利用できます。端末のABIに合ったインストーラーを選び、初回接続時にOSのVPN接続許可を確認してください。
バックグラウンド接続が切れる場合は、バッテリー最適化、バックグラウンド実行、メーカー独自の省電力制限を確認してください。SurfboardはClash YAMLとは設定形式が異なるため、インポート前にサブスクリプションの形式を確認しましょう。
ダウンロードページへClash Plusを選び、ダウンロードページからApp Storeへ進んでください。製品情報は公式サイト clashplus.ioで確認できます。接続前に、OSの案内に従ってVPN構成を追加してください。
サブスクリプションを追加したら、設定とプロキシグループを選んでから接続を開始してください。デスクトップ版のサービスモードや自動起動などの設定は、モバイルOSにはそのまま適用できません。
ダウンロードページへGUI環境ではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージ形式を使ってください。サーバーやルーターで使う場合は、ダウンロードページのコア欄からmihomoを確認できます。
デスクトップ環境のシステムプロキシ設定は、すべてのターミナルプロセスに自動で引き継がれるわけではありません。コマンドラインアプリでは環境変数を確認し、サービスとして運用する場合は実行ユーザー、設定ディレクトリ、ログの保存先も明確にしてください。
ダウンロードページへSOURCE / コアとクライアント
オリジナルのClashは、ルールベースのプロキシとYAML設定の基礎を築きました。その後のクライアントやコアのフォークにも、よく似た画面名称が数多く引き継がれています。mihomoは以前Clash.Metaという名称で、既存の設定体系を拡張しながら、プロトコル、ルールセット、ネットワーク処理機能を追加してきました。名称の似たインストーラーを見つけた場合は、アイコンやファイル名だけで互換性を判断せず、開発・保守プロジェクトと同梱コアを確認してください。このサイトはダウンロード先と日本語情報を案内するもので、各クライアントの開発チームとは関係ありません。
mihomoはポートの待ち受け、DNS処理、ルールの読み込み、プロキシ接続を担当します。Clash Verge RevやFlClashなどのGUIクライアントは、サブスクリプション管理、トレイ操作、システムプロキシとの連携を提供します。この2つは別々に更新できるため、クライアントを変えるとサブスクリプションURLが同じでも、設定項目の場所や反映方法が変わることがあります。問題を調べるときは、クライアント名と使用中のコアを記録してから、最終的に生成された実行設定を確認しましょう。GUIのスイッチを標準YAMLの設定項目と混同しないことが大切です。
mihomoのソースコードは公開リポジトリで管理され、GPL-3.0ライセンスで公開されています。コード、コミット履歴、課題の議論から、実装や変更の背景を確認できます。ただし、ソースコードが公開されていても、あらゆる設定が想定どおり動くとは限りません。GUIクライアントにはそれぞれ独自のライセンス、依存関係、リリースノートがあります。コアのライセンスがインストーラー全体の利用条件を示すわけではありません。ビルドや再配布を行う場合は、該当プロジェクトのライセンスを確認し、保持が求められる表示を残したうえで、依存コンポーネントの利用条件も確認してください。
更新前に、サブスクリプションURL、オーバーライドファイル、カスタムルールを保存し、現在の待ち受けポートと通信の制御方法を記録してください。更新後はまず設定を読み込み、起動ログ、プロキシグループ、新しく確立した接続を確認してから、TUNと自動起動を再設定します。サブスクリプションの更新は設定の再取得、クライアントの更新はGUIや同梱コアの更新です。両者を混同しないようにしましょう。開発終了したクライアントは移行先を検討する際の参考にはなりますが、新しいOSやプロトコルへの長期対応を期待するのは避けてください。移行手順はClash for Windows終了後の代替クライアントをご覧ください。
NOTES / 活用とトラブル対処
設定を反映するには、クライアントが対応していること、コアの設定項目が有効であること、ネットワーク経路が正しいことのすべてが必要です。以下の記事では、具体的な症状や移行のケースを取り上げます。初回接続が完了した後の参照に役立ちます。原因を特定するには、一度に変更する項目を1つに絞り、元に戻せる設定のコピーを残してください。そうすれば、どの変更が結果に影響したか判断できます。
サポート終了したクライアントの代替候補を整理し、対応OSやコアの違いを比較します。移行はサブスクリプション、ルール、カスタム設定のバックアップから始め、ポート、システムプロキシ、自動起動を再確認しましょう。以前の設定が新しいクライアントに影響するのを防げます。
OSごとに設定の構文、ポートの競合、コアファイルのアクセス権、WebViewコンポーネントを確認します。まずログを保存して直近の変更を元に戻し、原因を特定する前にサブスクリプションやオーバーライドファイルを失わないよう、データディレクトリのリセットは最後に検討してください。
アプリの名前解決、コアの上流DNS、アプリ通信の接続先を分けて確認し、Fake-IP、nameserver-policy、respect-rules、TUNを使ってリクエスト経路を調べます。検出結果はネットワーク環境を踏まえて判断してください。一度のテスト画面だけで結論を出すことはできません。