クライアント・コア・プロトコルのガイド
端末や設定に合わせてマルチプラットフォーム対応クライアントを比較し、ルール分岐とプロトコルの選び方を確認。互換性を確かめてから接続方法を調整しましょう。
よくあるつまずき / まず原因を特定
インポート成功、プロキシ有効化、Webページへのアクセスは、それぞれ別の確認段階です。エラーの内容を記録し、一度に変更する設定は一つに絞りましょう。ノード、コア、DNSを同時に変えるより、原因を特定しやすくなります。
まずログで、リクエストのタイムアウト、サーバーからの拒否、設定の解析エラーを切り分けます。タイムアウトの場合は、現在のネットワークと更新リクエストがプロキシ経由かを確認します。アクセスを拒否された場合は、サブスクリプションの有効期限とアカウント状態を確認してください。解析エラーの場合は、返された内容がログインページではないか、形式が対応しているかを確認します。リンク全体を何度も公開・貼り付けしないでください。また、設定をすぐにすべて削除する必要もありません。以前の動作する設定を残し、一つずつ検証しましょう。詳しくはサブスクリプションに関するFAQをご覧ください。
証明書エラーが出ても、新しい証明書のインストールが必要とは限りません。まずシステムの日時とタイムゾーンを確認し、プロキシを無効にした場合やノードを切り替えた場合と比較して、異常が端末側か接続経路上かを判断します。通常のHTTPS通信では、クライアントによるWeb通信の復号は不要です。出所不明のルート証明書を入れると、システムの信頼チェーンが変わるおそれがあります。証明書検証を無効にして問題を隠さず、具体的なエラーコードを記録して証明書エラーの確認手順に沿って調べてください。
システムプロキシの影響を受けるのは、プロキシ設定に従うアプリだけです。すべてのドメイン検索がコアで処理されるとは限りません。ブラウザーのセキュアDNS、システムのDNSキャッシュ、別のVPNによって実際の経路が変わることもあります。まず、どのアプリからリクエストが送信されたかを確認し、コアのDNS機能が有効か、TUNが通信を処理しているか、DNSサーバーに到達できるかを調べます。確認ページ一つだけで全通信の経路を判断せず、ログと接続記録もあわせて確認してください。詳しくはDNSとネットワークに関するFAQをご覧ください。
設定ガイドを見る
GUIクライアントが担う機能と、コアが処理する機能を切り分けてから、複雑な設定が必要か判断しましょう。以下の設定例は各項目の説明用で、そのままインポートできる完全なサブスクリプションではありません。
ルールモードでは、設定の上から順に対象ドメイン、アドレス、ルールセットと照合し、一致した項目に指定されたポリシーを適用します。直通通信とプロキシ接続を併用する日常環境に適しており、アプリごとにグローバルモードへ切り替える必要はありません。カスタムルールを追加する前に、指定したポリシー名が存在することを確認し、先行するルールに上書きされていないか調べましょう。単一のオン・オフ切り替えを提供するプロキシツールと異なり、Clashエコシステムではポリシーグループとルールの組み合わせが重視されます。ルールセットの対象範囲や更新元、最終的なフォールバックの仕組みも把握しておく必要があります。
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,PROXYTUNは仮想ネットワークインターフェースで通信を受け取り、システムプロキシに従わないアプリにも対応できます。ただし、有効にするだけですべての接続問題が解決するわけではありません。デスクトップクライアントでは、サービスモードや適切なシステム権限が必要になることがあり、ルーティングとDNSの設定も整える必要があります。別のVPN、仮想マシン、社内ネットワーク用ソフトウェアを同時に使う場合は、まずインターフェースやルートの競合を確認し、対象範囲を段階的に広げてください。システムプロキシよりネットワーク層に近い分、TUNのトラブルシューティングは複雑です。通常のWeb閲覧であれば、まずシステムプロキシを使い、必要な場合にTUNを有効にしましょう。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: truemihomoは、Clash Metaプロジェクトを引き継いで開発されているコアです。GUIクライアントは設定編集、トレイ操作、システム連携などを担います。両者はソフトウェアの異なる層にあるため、画面にプロトコル名が表示されても、同梱コアが対応する設定項目をサポートするとは限りません。古い設定を移行する際は、プロトコルの種類、ルールプロバイダー、DNS設定を確認し、新しいコアで名前解決をテストしてください。mihomoはオリジナルのClashよりプロトコルやルール機能が拡張されていますが、新機能に伴って設定の互換性も改めて確認が必要です。クライアント名だけで対応状況を判断しないでください。
# ターミナルでコアのコマンドヘルプを確認
mihomo -h
# ローカル設定の構文をテスト
mihomo -t -f config.yamlサブスクリプションリンクはリモート設定を取得するためのもので、クライアントそのものではありません。また、ルールやポリシーグループがすべて含まれるとは限りません。インポート前に、提供元がClash互換形式を出力しているか確認してください。更新後は、現在有効な設定が切り替わっているかも確認します。リモート設定ファイルを直接編集すると、次回の更新で変更が上書きされる可能性があります。クライアントの上書き・マージ機能を使い、ローカルの設定を保存する方法が安全です。サブスクリプションの変換にはリンク内の認証情報が関わるため、扱いに注意し、よく知らないWebサービスにリンク全体を送信しないでください。
# 設定の主な項目を確認
proxies: []
proxy-groups: []
rules:
- MATCH,DIRECT同じ設定でも、端末によって異なるシステム上の制限を受けることがあります。デスクトップではシステムプロキシ、バックグラウンドサービス、自動起動を確認し、モバイルではVPNの許可、バックグラウンド実行、省電力設定を確認しましょう。ダウンロード時は、まずOSとCPUアーキテクチャに合うものを選び、次にコア、サブスクリプションの上書き機能、ルール管理方式を比較します。Clash Plusを選定の出発点にし、デスクトップとの連携機能を重視する場合は、Clash Verge Revなども比較してください。あるプラットフォームのメニュー位置を別の端末に当てはめないようにしましょう。機能名が似ていても、実装が異なる場合があります。
# デスクトップクライアントでよく使う設定
システムプロキシ
TUNモード
スタートアップ起動
サービスモード
LAN接続を許可SS、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ設計目標や通信方式が異なります。実際の性能は、サーバー設定、ネットワークのパケットロス、端末の性能にも左右されます。QUICベースの方式は特定の回線で有利な場合がありますが、ネットワーク側でUDP通信が許可されている必要があり、モバイル端末の電池消費に影響することもあります。選ぶ際は、まずクライアントのコアが対応しているか確認し、接続確立、長時間接続の安定性、バックグラウンド時の電池消費を比較しましょう。一度の速度テストだけで判断するのは避けてください。プロトコルガイドでは利用シーンごとの選び方を解説し、プロトコル名が性能を保証するものではないことも説明します。
# ノードのtypeでよく使われる値
# ss / vmess / trojan / vless
# hysteria2 / tuic
# その他の項目はサーバー設定と合わせるガイドは9秒ごとに切り替わります。タブのクリック、キーボード操作、フォーカス時には停止します。動きを減らす設定では、表示を固定して読めます。
端末に合わせてダウンロードページへ
GUIクライアントはデスクトップやモバイルでの日常利用に適し、単体のコアはサーバーなどを自分で管理するユーザー向けです。ダウンロードページでは、インストーラーの形式、アーキテクチャの選び方、メンテナンス状況を掲載しています。まず端末の要件を確認してから機能を比較し、似たファイル名の別パッケージを誤ってインストールしないようにしましょう。
まずClash Plusを比較し、サービスモード、サブスクリプションの上書き機能、画面の使い勝手に応じてClash Verge Rev、FlClash、Clash Nyanpasuを選びましょう。Clash for Windowsは開発・保守が終了しています。アーカイブ版は明確な互換性要件がある環境向けで、名前に見覚えがあるという理由だけで新規インストール用に選ぶのはおすすめできません。
ダウンロードページへまず「このMacについて」でAppleシリコンかIntelプロセッサかを確認し、対応するインストーラーを選んでください。Clash Plus、Clash Verge Rev、FlClashを比較できます。ClashX Metaはメンテナンスが終了しています。インストール後は、システム権限、プロキシによる通信の処理、バックグラウンドサービスを個別に確認しましょう。ウィンドウが開くことだけでは、接続を確認したことにはなりません。
ダウンロードページへまずCPUアーキテクチャとOSのインストール要件を確認し、Clash Plus、Clash Meta for Android、FlClash、Surfboardの設定形式を比較してください。初回接続時には通常、VPNの許可が必要です。バックグラウンドで接続が切れる場合は、サブスクリプションを次々に切り替えるのではなく、省電力制限や他のVPNとの競合を確認しましょう。
ダウンロードページへClash PlusはApp Storeからインストールできます。製品情報は公式サイト clashplus.ioで確認してください。インポート前に設定の互換性を確かめ、初回接続時はシステムの案内に従ってVPN構成の追加を許可します。接続の切り替えやバックグラウンド動作に問題がある場合は、システムの許可、サブスクリプションの状態、ノードへの到達性を切り分けて確認しましょう。
ダウンロードページへデスクトップでは、まずClash Verge RevとFlClashを比較し、ディストリビューションに合うパッケージ形式を選んで、GUI環境と依存関係を確認してください。サーバー、ルーター、起動サービスを自分で管理するユーザーは、ダウンロードページのmihomoコアの項目をご覧ください。GUIクライアントと単体コアは、動作させるために両方インストールする必要はありません。
ダウンロードページへ初期設定 / 3ステップ
インストール、設定、通信の処理を分けて進めましょう。問題が起きたら、最初から再インストールするより、現在の手順でログを確認するほうが有効な手がかりを残せます。
クライアントの設定またはサブスクリプション画面でリンクを追加し、更新に成功したら、その設定を明示的に選択します。ポリシーグループが表示されるか、解析エラーがないかを確認してください。ログインページが返された場合は、サブスクリプションの提供元を先に確認しましょう。リンク全体には通常、認証情報が含まれています。スクリーンショットを共有したり、サポートを依頼したりする前に、必ず隠してください。
普段はルールモードを選び、ポリシーグループで利用可能なノードを選択してから、システムプロキシを有効にします。システムプロキシに従わないアプリの通信を処理する必要がある場合に限り、TUNを設定しましょう。グローバルモードは短時間の比較やトラブル調査に使うもので、ルールモードより機能が充実しているわけではありません。また、ルールが意図どおり適用されているかの確認にも代わりません。
対象サービスにアクセスした後、接続画面で該当ドメイン、適用されたルール、実際のポリシーを確認します。速度テストが一度成功しても、そのときテスト対象に接続できたことしか分からず、すべてのアプリの通信が処理されているとは限りません。確認後は、動作する設定と必要なローカル上書きを保存しておきましょう。今後の更新で問題が起きた際に、明確な比較基準になります。
オープンソースのエコシステム / 情報源
Clashエコシステムは、単一のインストーラーからなる製品群ではありません。初期のClashがプロキシ、ポリシーグループ、ルール設定の基本構造を築き、その後、コアとGUIクライアントはそれぞれ異なる方向に発展しました。Clash測評はダウンロードと選び方を紹介する情報サイトであり、各プロジェクトの開発元ではありません。プラットフォームの対応状況、必要な機能、メンテナンス状況を基準に紹介しており、サイトのブランドをソフトウェアの公式な身分として扱うことはありません。
こうした関係を理解しておくと、更新情報を読み解きやすくなります。画面の修正はシステムトレイやウィンドウの動作だけに関わる場合があります。一方、コアの更新ではプロトコルの解析、ルール処理、DNSの動作が変わる可能性があります。選ぶ際は両方の更新状況を確認し、インストーラー名や一度の画面変更だけで機能全体の変化を判断しないようにしましょう。
プロトコルとコアの技術資料を読む →mihomoの公開リポジトリでは、ソースコード、課題の議論、リリース履歴を確認できます。以下のコマンドはプロジェクトのソースコードを取得するだけです。クライアントをインストールしたり、端末上のGUIを置き換えたりするものではありません。
git clone https://github.com/MetaCubeX/mihomo.gitClash Metaは後にmihomoへ名称変更されたため、ガイド内では両方の名称が使われることがあります。旧名称は資料の出所を確認する手がかりになりますが、古い設定が現在のコアと完全に互換であることを示すものではありません。古い記事を読むときは、概念の説明と具体的な設定項目を分けて確認してください。ポリシーグループやルールの照合順序は今も参考になることがありますが、プロトコルのパラメーター、DNSの動作、プラットフォームの権限は改めて確認が必要です。Clash for Windowsの開発終了は、Clashエコシステム全体の開発終了を意味しません。
公開ソースコードがあれば、実装や変更の履歴を追えます。ただし、オープンソースであること自体は、環境ごとの動作確認に代わるものではありません。より有用な判断材料は、問題を再現できるか、ログが同じモジュールを示しているか、修正が使用中のクライアントのリリースに含まれているかです。問題を報告する際は、OS、コアの入手元、再現手順、個人情報を伏せたログを記載してください。サブスクリプション全体や個人のネットワーク情報はアップロードしないでください。他のユーザーによる同様の報告は手がかりとして参考になりますが、現在の端末に対する診断結果としてそのまま扱わないようにしましょう。
移行前に元の設定のコピーを保存し、新しいクライアントにインポートしてテストしましょう。構文チェックに通ることは最初の確認にすぎません。ポリシーグループの参照、ルールセットの取得、DNSの名前解決、実際の接続経路も検証してください。クライアントに設定のマージ機能がある場合は、リモートサブスクリプションで管理される項目とローカル上書きの項目を切り分けます。まず最小限の設定で動作を確認し、応用設定を一つずつ戻すほうが、古いフォルダーを丸ごとコピーするより差分を特定しやすく、過去のキャッシュによる誤判定も防げます。
クライアント、同梱コア、サブスクリプション、ルールセットはそれぞれ別に更新されることがあり、一つを更新しても他が自動で同期されるとは限りません。アップグレード前に、自分が使う機能に関係する変更内容を読み、アップグレード後は同じ宛先への接続を検証してください。長く使う場合は、名称に「新」と付いているかではなく、メンテナンス状況、設定の移行しやすさ、トラブル情報の分かりやすさを重視しましょう。ダウンロードページでは入手先をまとめ、クライアント比較ページでは選ぶ理由を解説します。プロトコルガイドは、通信方式や互換性について詳しく比較するための資料です。
Clash測評のノート / 最新記事
各記事では、一つの具体的な問題を取り上げます。まず現象を整理し、原因となる仕組みを説明したうえで、結果を確認できる手順を紹介します。端末固有の環境に関わる場合は元の設定を残し、一つの問題向けの変更をすべての接続に広げないようにしてください。
設定ファイルの破損、ポートの競合、コアの権限、ランタイムの不足という4つの原因別に、ログの確認方法、クラッシュ箇所の特定、正常起動に戻す手順を解説します。
修復手順を読む →システム時刻、中間者による通信の復号、ノードの異常、ブラウザーのキャッシュなどの原因を分析し、証明書エラーとプロキシの関係を説明します。簡単な確認から順に進める手順も紹介します。
原因と対処法を読む →ルール項目の3つの要素からなる構文を解説し、上から順に照合される仕組みを説明します。ルールセットやMATCHによるフォールバック、よくある記述位置の誤りを確認する方法も紹介します。
ルールの解説を読む →