設定・コア・画面、それぞれの役割
Clash はプロキシツールのエコシステムであり、すべてのプラットフォームで同じアプリが使われているわけではありません。クライアントは設定の読み込みや切り替え、ログ表示を担い、コアはプロトコル接続とルールの適用を、設定ファイルはプロキシノードやポリシーを定義します。クライアントを選ぶときは、まず OS と CPU アーキテクチャを確認し、使用中の設定にコアが対応しているかを調べましょう。画面の名称が似ていても、設定項目や必要な権限が同じとは限りません。
Clash はプロキシツールのエコシステムであり、すべてのプラットフォームで同じアプリが使われているわけではありません。クライアントは設定の読み込みや切り替え、ログ表示を担い、コアはプロトコル接続とルールの適用を、設定ファイルはプロキシノードやポリシーを定義します。クライアントを選ぶときは、まず OS と CPU アーキテクチャを確認し、使用中の設定にコアが対応しているかを調べましょう。画面の名称が似ていても、設定項目や必要な権限が同じとは限りません。
設定画面にサービス提供元から案内されたサブスクリプション URL を貼り付け、ダウンロード完了後にその設定を選択します。続いてプロキシ画面を開き、プロキシグループに利用可能なノードが含まれているか確認してください。読み込みに成功しても、システム通信がプロキシ経由になったとは限りません。サブスクリプション URL に認証情報が含まれる場合があるため、スクリーンショットやログを共有する前に必ず削除してください。
普段はルールモードから使い始めるとよいでしょう。通信は接続先のドメインや IP アドレスに応じてルールと照合され、該当するプロキシグループで処理されます。手動選択グループは出口を固定したい場合に、自動テストグループは設定された条件に応じて候補ノードを選びたい場合に便利です。特定のサイトだけ開けないときは、接続画面で適用されたルールと実際の出口を確認しましょう。すぐにすべての通信をグローバルプロキシに切り替える必要はありません。
システムプロキシが適用されるのは、主に OS のプロキシ設定に従うアプリです。TUN は仮想ネットワークインターフェースを使い、より広い範囲の通信を取り込みます。どちらも接続先までの回線品質を直接改善するものではありません。トラブル時は、まず通信がコアに届いているかを確認し、その後ルール、名前解決結果、出口を調べましょう。設定は一度に一つだけ変更し、動作する設定を残しておくと、変更の効果を判断しやすくなります。
ルールは上から順に評価され、通常は最初に一致したルールで通信先が決まります。明確なドメイン指定を広範なルールより前に置き、末尾の MATCH で残りの通信を処理します。DOMAIN-SUFFIX はドメインとサブドメインに、IP-CIDR は IP アドレス範囲に一致します。GEOIP は地理データベースを利用します。例の PROXY はプロキシグループ名です。使用前に、設定内で同じ名前のグループを定義してください。変更後は設定を再読み込みし、接続画面で実際に適用されたルールを確認しましょう。サイトが開くかどうかだけで効果を判断しないでください。
プロキシグループを使うと、ノードを整理して出口を選べます。select グループは手動選択、url-test グループは設定されたテスト先・間隔・許容差をもとに候補ノードを選び、fallback グループは利用可否と指定順に応じて切り替えます。自動選択でも実際のダウンロード速度が必ず上がるとは限らず、テスト結果がすべてのサイトに当てはまるわけでもありません。まず手動グループでノードの利用可否を確認してから、自動選択を検討しましょう。サブスクリプションの更新後はグループ内のメンバーも確認し、削除済みまたは名称変更されたグループをルールが参照していないかチェックしてください。
| 種類 | 対象 | ポリシー |
|---|---|---|
| DOMAIN-SUFFIX | github.com | PROXY |
| IP-CIDR | 192.168.0.0/16 | DIRECT |
| GEOIP | CN | DIRECT |
| MATCH | その他の通信 | PROXY |
この例はルールの照合関係を示すもので、単独で動作する完全な設定ではありません。LAN のアドレス範囲は実際のネットワークに合わせて追加してください。地理ルールだけに頼らず、対象サービスのドメインを明示することも大切です。
Clash のプロキシグループを見る →コマンドラインツールやゲーム、独自のネットワーク機能の中には、システムプロキシを参照しないものがあります。クライアントが TUN に対応していれば、仮想ネットワークインターフェースとルーティング設定を通じて通信をコアに送り、ルールに基づいて直接接続またはプロキシ接続できます。デスクトップではサービスモードや管理者権限が必要な場合があり、モバイルでは通常、OS の VPN インターフェースを使用します。有効にする前に通常の接続が動作することを確認し、対象アプリで個別にテストしましょう。TUN ですべての通信を取り込めるとは限らず、実際の範囲はルートの除外設定、OS の権限、ほかのネットワークソフトに左右されます。
DNS はドメイン名を IP アドレスに変換し、ドメインルールに必要な情報を提供します。Fake-IP モードでは予約済みアドレスを使ってドメインとの対応を保持し、後続の接続をドメインに関連付けます。実際の名前解決結果を必要とする機器やアプリでは、コアのドキュメントを確認し、fake-ip-filter の設定を検討してください。DNS のリダイレクト、OS の暗号化 DNS、アプリ独自の名前解決によって通信経路が変わる場合があります。設定を変更するときは元の値を記録し、一度に一項目だけ変更して、Web 閲覧、LAN サービス、アプリへのログインをそれぞれテストしましょう。
TUN を有効にしたら、スイッチの状態だけで判断せず、コアのログにネットワークインターフェース、権限、ルーティングのエラーがないか確認してください。デスクトップではクライアントのサービスが正しくインストールされているか、モバイルでは VPN の許可が取り消されていないかを確認します。既存の VPN、仮想マシンのネットワークインターフェース、セキュリティソフトがデフォルトルートに影響することもあります。問題を切り分ける際は一つずつ無効にして比較してください。有効化後にすべての通信が止まった場合は、まず TUN をオフにして基本接続を復旧し、エラー情報を保存してから、クライアントのドキュメントに沿って権限やルートの競合に対処しましょう。
システムプロキシと TUN は通信を取り込む方式、ルールモードは出口を選ぶ方式です。役割の階層が異なるため、TUN を有効にしたままルール分岐を利用できます。
ネットワーク設定ガイドを読む →まず OS、アーキテクチャ、必要な権限を確認してから、インストール方法を選びましょう。既存の設定がある場合は、使用中のプロトコルやコアの設定項目との互換性も確認してください。
初めて設定する場合は Clash Plus から始めるか、使い方に合わせて Clash Verge Rev や FlClash などを選べます。ダウンロード前に OS の設定で CPU アーキテクチャを確認し、パソコンのメーカーだけで判断しないでください。インストール後は設定を読み込み、システムプロキシを有効にします。ほかのアプリの通信も取り込む場合は、サービスモードと TUN の権限を確認しましょう。
ブラウザーではアクセスできるのに一部のシステムアプリで接続できない場合は、まずそのアプリがシステムプロキシに従うか確認してください。UWP アプリのループバック制限は別途対処が必要で、ノードの障害とは限りません。クライアントを切り替える前に、使用中のクライアントを終了し、複数のアプリがローカルの待ち受けポートを取り合わないようにしましょう。
ダウンロードページへApple Silicon と Intel のデバイスでは、それぞれに合ったアーキテクチャのインストーラーを選びます。Clash Plus、Clash Verge Rev、FlClash は画面や設定管理の方法が異なるため、インストール前にダウンロードページで比較してください。初回起動時は OS の案内に従って権限を設定し、メニューバーのクライアントが実際に起動しているか確認しましょう。
システムプロキシとネットワーク拡張では許可される範囲が異なります。通信の取り込み方式を変更した後は、対象アプリで接続を確認してください。社内ネットワークで自動プロキシ設定や特定の DNS が必要な場合は、先に元の設定を記録しておきましょう。クライアントを終了するときはプロキシを正しくオフにし、停止したローカルポートをシステムが参照し続けないようにしてください。
ダウンロードページへ設定に合わせて Clash Plus、Clash Meta for Android、FlClash から選べます。インストール前にデバイスの対応アーキテクチャを確認し、サブスクリプションを読み込んだら OS の VPN 許可を承認して、プロキシグループから出口を選びましょう。Android の VPN インターフェースは、通常ほかの VPN アプリと同時に使用できません。
画面ロック後に接続が切れる場合は、バックグラウンド動作の権限、バッテリー最適化、メーカー独自の省電力設定を確認してください。異常をすべて省電力機能のせいにせず、モバイルデータと Wi-Fi で比較し、サブスクリプションの期限やノードの状態、ネットワーク切り替え後に復旧するかも確認しましょう。
ダウンロードページへダウンロードページには Clash Plus の App Store リンクと公式サイト clashplus.io を掲載しています。インストール後、アプリの案内に従って対応する設定を読み込み、VPN 構成を追加して OS の許可を完了してください。最初の接続では普段使うサイトをテストし、アプリ内のプロキシグループと接続履歴を確認して、選択した出口が想定どおりか確かめましょう。
モバイル OS ではバックグラウンド動作やネットワーク拡張が制限されます。デスクトップ向けガイドにあるサービスのインストールやループバック設定などを、そのまま適用することはできません。サブスクリプションの読み込みに失敗した場合は、VPN 構成を何度も削除するのではなく、まず形式とクライアントの互換性を確認しましょう。
ダウンロードページへデスクトップ環境では Clash Verge Rev と FlClash を比較し、ディストリビューションに合ったパッケージ形式とシステム依存関係を確認してください。ターミナルのプログラムはデスクトップのプロキシ設定を引き継がない場合があります。必要に応じて、実行中のプロセスにプロキシ環境変数を設定するか、ルーティングへの影響を十分に理解したうえで TUN を有効にしましょう。
サーバーやルーターで使う場合は、コアのセクションで Mihomo のパッケージを確認してください。コアを単独で実行するには、設定ファイルのパス、サービス権限、ログを自分で管理する必要があります。他のデバイスのネットワークインターフェース名やルーティング設定をそのまま使わないでください。リモート操作の前に、接続を復旧する手段を用意しましょう。
ダウンロードページへプロジェクトの開発元、クライアントの開発・保守元、ネットワークサービスを区別すると、更新やトラブル対処を適切に進められます。
Clash は当初、ルールベースのプロキシコアを中心に開発され、その後、デスクトップ画面、モバイルクライアント、設定ツールなどへとエコシステムが広がりました。オリジナルのプロジェクトと派生プロジェクトでは、メンテナンス状況が異なります。現在「Clash」と呼ばれるものは、コアや設定形式、あるいは特定のクライアント名を指す場合があります。互換性について問い合わせる際は、単に「Clash が使えない」とするのではなく、クライアント名、コアの種類、OS 環境をあわせて記載しましょう。
Clash 使い方ガイドでは、クライアントのダウンロード先と日本語の操作ガイドをまとめています。各クライアントの開発チームではなく、プロキシノードの提供も行っていません。ダウンロードページではプラットフォームごとにクライアントを紹介し、開発が終了したプロジェクトにはその旨を記載しています。選ぶ際は、メンテナンスが継続され、使用中の設定を読み込めるクライアントを優先してください。古いガイドの画面や項目名は参考情報として扱い、具体的な操作は現在のクライアントの説明に従いましょう。
Mihomo は、Clash エコシステムで継続的に開発されているオープンソースのコアで、以前は Clash.Meta と呼ばれていました。コアはプロトコル処理、DNS、ルール照合、通信の転送を担います。グラフィカルクライアントは設定管理、システム連携、操作画面を提供します。画面上の一つのスイッチが、コアの設定と OS の設定を同時に変更することもあります。問題の発生箇所を切り分けるには、まず設定が読み込まれているかを確認し、次にコアのログ、最後にシステムプロキシとルートを調べましょう。
Clash 形式の YAML に対応していても、すべてのコアが同じ項目をサポートするとは限りません。新しいプロトコル、ルールプロバイダー、DNS オプションには、対応するコアが指定されている場合があります。設定を移行する際は元のファイルを残し、新しいクライアントには複製したファイルを読み込ませましょう。不明な項目や存在しないポリシーが表示された場合は、該当箇所を確認し、DNS やルールをまとめて削除しないでください。以下のコマンドは Mihomo のソースコードを取得するだけで、グラフィカルクライアントのインストールや利用可能なノードの生成は行いません。
クライアントの更新ではシステム連携や画面が変わり、コアの更新ではプロトコルやネットワーク動作が改善されることがあります。サブスクリプションの更新は主にノード、プロキシグループ、ルールの更新です。この3つは別のものです。更新前にローカルの上書き設定、分岐ルール、必要な画面を保存してください。更新後は設定が選択されたままかを確認し、ノードの構成と通信の取り込み方式も確認します。クライアント、サブスクリプション、DNS を一度に変更すると、問題がどの変更から発生したのか追跡しにくくなります。
サブスクリプション管理機能によっては、手動での変更が上書きされることがあります。独自ルールを継続して使う場合は、クライアントが上書きやマージに対応しているか確認し、マージ後の最終設定もチェックしてください。対応機能がない場合は、少なくとも独立したコピーを保存しておき、次回の更新で消えないようにしましょう。起動時に自動実行する場合は、クライアントの自動起動、コアの起動、プロキシ設定の復旧をそれぞれ確認してください。タスクトレイにアイコンが表示されるかだけでは判断できません。
自動起動とメンテナンスを見る →接続画面では通常、接続先、適用ルール、出口のポリシーを確認できます。ログ画面は名前解決、ハンドシェイク、権限のエラーを調べるのに便利です。速度テストの応答時間は特定の条件で測定された結果であり、帯域幅や安定性、すべてのサイトでの速度を示すものではありません。比較可能な結果を得るには、ネットワークとテスト先を固定し、候補ノードを一つずつ切り替えてください。
トラブル対処の情報を共有する際は、エラーの種類、発生した手順、OS 環境、関連する設定項目を残し、サブスクリプション URL、アカウント情報、ノードの認証情報は削除してください。ブラウザーでは正常なのに特定のアプリだけ動かない場合は、通信の取り込み範囲を確認します。すべての通信に問題がある場合は、コア、DNS、出口を調べましょう。複数のスイッチを次々に切り替えるより、変更前後の接続履歴を比較するほうが原因を特定しやすくなります。
ノードの速度測定と確認方法を見る →モバイル端末のバックグラウンド動作、DNS モード、速度低下の原因を、設定と確認の手順に分けて解説します。
VPN の常時表示、バックグラウンド制限、メーカー独自の省電力設定から確認し、TUN や DNS の設定も踏まえて電池消費の原因を探ります。通信が継続しているのか、アプリが異常に再起動しているのかを切り分けてから、バックグラウンド権限を調整しましょう。通信量を確認せず、動作を維持することだけを優先しないようにしてください。
記事を読む →予約済みアドレスとドメインの対応付けが接続処理にどう使われるかを解説し、2つの名前解決モードの違いを比較します。LAN へのアクセスや実 IP アドレスを必要とするアプリも踏まえ、DNS の方式全体を切り替えるのではなく、除外設定が必要なケースを判断できます。
記事を読む →ノードの品質、プロバイダーの回線、ルールの適用状況、DNS の名前解決、端末側のネットワークを分けて確認します。ほかの条件は変えずに各項目を比較し、再現可能な結果をもとに、高遅延、転送速度の不足、接続確立の失敗を切り分けましょう。
記事を読む →