オープンソース · mihomo搭載クライアントを継続更新

Clashクライアント全プラットフォーム対応

OSに合ったクライアントを選び、mihomoコアでプロキシ接続を処理。ルールによる振り分けで通信を管理し、日本語ドキュメントを参考に設定できます。

  • 共通の入口 HTTPとSOCKSを混合ポートで受け付け
  • 必要に応じて有効化 システムプロキシとTUNを個別に設定
  • 見通しのよい設定 サブスクリプション、プロキシグループ、ルールを整理して管理

MIHOMOコア · GPL-3.0オープンソース · ルールによる振り分け

ルールによる振り分けTUNモードサブスクリプション管理
PLATFORMS OSに合ったインストーラーを選択
COREmihomoプロトコルとルールのエンジン
LICENSEGPL-3.0コアのソースコードを公開
CONFIGURATIONYAML設定受信設定 / プロキシグループ / ルール
PROTOCOLS / CORE

プロトコルとコアの対応状況互換性を確認してから選択

プロトコル名は接続方式を示すもので、速度を保証するものではありません。サーバー側のパラメーター、ネットワーク経路、クライアントのコアが対応している必要があります。サブスクリプションを登録したら、まずプロトコル設定を現在のコアが認識できるか確認しましょう。

サブスクリプションを登録済み

サーバー側で指定されたプロトコルと転送パラメーターを使用します。クライアントが設定を読み込めることは最初の確認にすぎません。TLS、トランスポート層、プロキシグループの参照先がそろっているかも確認してください。

モバイル回線

ネットワーク切り替え後の復帰動作やバックグラウンド制限を確認しましょう。QUICベースのプロトコルはUDPが利用できることを前提としています。プロトコル名だけで電池消費や接続の安定性を判断することはできません。

デスクトップとサーバー運用

デスクトップではGUI操作やOSとの連携が重視され、サーバーではサービス管理や設定の保守性が重要です。プロトコルとコアの技術資料を見る →

01 / CLIENT SELECTION

Clashの全プラットフォーム対応クライアントOSとプロセッサに合わせて選択

GUIクライアントはサブスクリプション管理、プロキシ切り替え、OS連携を担い、コアはルールを解析して接続を確立します。まずデバイスに合ったインストーラーを選び、必要なプロトコルにコアが対応しているか確認しましょう。

Windows

GUIクライアントはClash Plus、Clash Verge Rev、FlClashなどから選べます。まずシステム情報でプロセッサのアーキテクチャを確認してください。インストール後はシステムプロキシで接続を確認し、システムプロキシを参照しないアプリも通したい場合は、ガイドに沿ってTUNを設定します。

ダウンロードへ Windowsクライアント→

macOS

Apple SiliconかIntelかを確認し、対応するビルドを選んでください。システムプロキシとネットワーク拡張では許可する場所が異なります。初回起動時はOSの案内に従って設定しましょう。クライアントを更新する前に設定をバックアップしてください。サブスクリプションやルールの問題は、再インストールではなく原因を切り分けます。

ダウンロードへ macOSクライアント→

Android

Clash Plus、Clash Meta for Android、FlClash、Surfboardなどを選べます。デバイスのアーキテクチャと設定形式を確認し、初回接続時はVPN接続を許可してください。アプリを切り替えた後に接続が途切れる場合は、バックグラウンド実行やバッテリー管理に関するOSの制限を確認しましょう。

ダウンロードへ Androidクライアント→

iOS

App StoreからClash Plusをインストールします。公式サイトはclashplus.ioです。設定をインポートしたら、VPN構成の追加を許可してプロキシグループを選択してください。アプリの画面はデスクトップ版と完全には同じではありません。接続状況、使用中の設定、ルールの適用状況を確認してトラブルを切り分けましょう。

ダウンロードへ iOSクライアント→

Linux

デスクトップ環境ではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージを使用します。GUIのないホストではmihomoを直接実行し、サービスマネージャーでプロセスを管理できます。設定ディレクトリの権限、リッスンアドレス、サービスログも確認してください。

ダウンロードへ Linuxクライアント→
02 / CONFIGURATION WORKBENCH

受信設定・ルール・プロキシグループ通信経路から設定を理解する

通信はローカルの受信設定、ルールの照合、出力先の選択という順に処理されます。この流れに沿って設定すると、複数のスイッチを同時に切り替えるより結果を確認しやすくなります。

ルールによる振り分け
TUNモード
混合ポート · LAN共有
mixed-port: 7890
allow-lan: false
サブスクリプションの更新
ノードの速度テスト
外部コントローラー
ログを確認
設定の上書き · ルールの順序
DOMAIN-SUFFIX,github.com,PROXY
GEOIP,CN,DIRECT
MATCH,DIRECT
DNS設定
プロキシグループ
複数の設定を切り替え

ルールは上から順に照合され、プロキシグループが出口を決める

ルールモードは、すべての接続を同じノードに送る機能ではありません。コアはドメイン、アドレス、ルールセットを上から順に確認し、一致した条件に対応するポリシーへ通信を渡します。ポリシーには直接接続のほか、プロキシグループも指定できます。設定を調整するときは具体的な条件を先に置き、最後にフォールバックのMATCHを配置し、ルールが参照するグループ名が存在することを確認してください。グローバルモードと違い、ルールモードでは通信ごとに経路を分けられますが、結果はルールの内容に左右されます。特定のアプリが意図しない出口を使う場合は、接続一覧で適用されたルールを確認してから該当条件を修正しましょう。すべてのノードを何度も切り替える必要はありません。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

速度テストの結果と実際のダウンロード速度は分けて考える

ノードの速度テストは通常、指定した測定先への応答時間を測るもので、継続的なダウンロード速度を測定するものではありません。応答が速いノードでも、帯域幅、サーバーの負荷、接続先サイトの制限によって速度が出ないことがあります。比較するときは同じネットワーク、同じ測定先、近い時間帯にそろえ、変更する条件は1つだけにしてください。ブラウザーは使えるのにターミナルで失敗する場合は、ターミナルがプロキシ環境変数を参照しているか確認しましょう。すぐにノードの障害と決めつけないでください。

ログは問題の発生段階を特定するために使う

サブスクリプションの取得失敗、設定の解析失敗、ドメイン名の解決失敗、接続先への接続失敗を切り分けてから、該当する設定を確認しましょう。調査中にログの詳細度を一時的に上げると役立ちますが、共有する前にサブスクリプションURL、認証情報、個人のアドレスを削除してください。使用中の設定、モード、再現手順を記録すると、何度も再インストールするより原因を見つけやすくなります。

03 / FIRST CONNECTION

サブスクリプションの登録と接続確認再現可能な接続を1つ確立する

初回設定ではポートをデフォルトのままにし、必要なネットワークモードだけを有効にしてください。手順ごとに状態を確認してから、次へ進みましょう。

STEP 01

サブスクリプションを登録して有効化する

クライアントのサブスクリプションまたは設定画面でURLを追加し、ダウンロード後にその設定を選択します。設定を解析できること、プロキシグループに選択可能な項目があることを確認してから次へ進みましょう。サブスクリプションURLにはアクセス認証情報が含まれることがあるため、公開の掲示板には貼らないでください。インポート時にエラーが出た場合は、取得内容が設定ファイルなのかエラーページなのかをまず確認します。

STEP 02

モードと出口を選択する

通常はルールモードから始め、主要なプロキシグループで利用可能なノードを1つ選びます。デスクトップではシステムプロキシを有効にし、モバイルではOSの案内に従ってVPN接続を許可してください。複数のプロキシアプリを同時に有効にしたり、基本接続を確認する前にDNS、ポート、ルーティングなど複数の設定を変更したりしないでください。

STEP 03

接続先にアクセスして通信を確認する

確認したいアプリを開き、接続一覧で該当するドメインまたはプロセスを見つけ、適用ルールと実際の出口を確認します。スイッチがオンになっているだけでは、通信がコアに届いたとは限りません。アプリの通信記録がない場合はプロキシの入口を確認し、記録はあるのに失敗する場合は名前解決、ノードへの接続、接続先サービスを調べましょう。

詳しい使い方を見る →

04 / OPEN SOURCE CONTEXT

Clashエコシステムとmihomoコアクライアントの画面だけではわからないプロジェクトの関係

ここでいうClashは、共通の設定モデルを持つクライアントとコアのエコシステムを指します。すべてのアプリが同じチームによって開発されているわけではありません。画面が似ていても、プロトコル対応や設定の動作まで同じとは限りません。

従来の設定モデルからmihomoへ

ClashではYAMLを使ってプロキシ、プロキシグループ、ルールを定義し、GUIクライアントがそのモデルをもとにインポート、切り替え、OS連携の機能を提供します。オリジナルのプロジェクトがメンテナンスを終了した後も、エコシステム内の各プロジェクトは開発を続けています。Clash Metaという名称と後継のmihomoには、プロジェクトの変遷におけるつながりがあります。そのため、古いガイドでは両方の名称が使われています。機能が使えるかどうかは、アプリ名にMetaが含まれるかではなく、現在実行中のコアで判断してください。

オープンソースの範囲とライセンスは個別に確認する

mihomoコアはGPL-3.0ライセンスを採用しており、ソースコード、課題、コミット履歴はプロジェクトのリポジトリで確認できます。GUIクライアント、システムサービスのコンポーネント、設定ツールには、それぞれ別のリポジトリやライセンスが適用される場合があります。コアのライセンスがすべてのソフトウェアに適用されるわけではありません。コードの改変、再配布、組み込みを行う場合は、対象プロジェクトのライセンスファイルと依存関係の表記を確認してください。日常的な接続に使う場合は、まずダウンロードページでメンテナンス状況とシステム要件を確認できます。

設定の互換性は、すべての項目が同じように動作することを意味しない

古い設定の基本ルールや一部のプロキシ項目は引き続き使える場合がありますが、新しいプロトコル、ルール種別、高度なDNS項目には対応するコアが必要です。設定を別のクライアントにコピーする前に、YAML全体を受け取るのか、ノードのサブスクリプションだけを受け取るのかを確認してください。クライアントがデフォルト設定を自動でマージするかどうかも確認が必要です。解析エラーが出たら、ログで示された項目を1つずつ確認します。設定を読み込ませるために、認識されない項目をまとめて削除することはおすすめしません。

クライアント、コア、サブスクリプションはそれぞれ別に更新される

クライアントの更新では主に画面、プラットフォーム連携、パッケージ内のコンポーネントが変わります。コアの更新はプロトコルの実装やルールの解析に影響し、サブスクリプションの更新はリモートで提供されるノードや設定を変更します。それぞれ解決する問題は異なります。更新前に復元できる設定を保存し、更新後は使用中の設定、リッスンポート、システムプロキシの状態を確認しましょう。使用中の接続に変化があった場合は、まず更新内容を照らし合わせてから、設定の復元か調整かを判断してください。

05 / TECHNICAL NOTES

Clashの設定とトラブル対処ガイド症状から該当する設定を特定

クイックスタートでは初回接続を案内し、技術資料ではプロトコルとコアを解説します。個別の問題については、関連記事で確認手順を紹介しています。状況を整理して、目的に合ったガイドを選んでください。

すべての記事を見る →