オープンソースクライアント集 mihomo コア

Clash配布ページマルチプラットフォーム クライアント

マルチプラットフォーム対応クライアント、ルール分岐、日本語設定ガイドを掲載。デバイスに合ったクライアントを選び、コアの対応機能を確認できます。

オープンソースコア設定リファレンス移行ガイド

Clashクライアントのダウンロード

まずOSを選び、次にCPUアーキテクチャを確認します。デスクトップではトレイ管理や設定編集、モバイルではバックグラウンド動作の権限、バッテリー管理、OSのネットワーク機能も確認しましょう。名前が似ていても、インストーラーやコア、サブスクリプション形式が同じとは限りません。

Windows版クライアント

まずはClash Plusがおすすめです。Clash Verge Rev、FlClash、Clash Nyanpasuも選べます。インストール前にWindowsの種類を確認してください。TUNを使う場合は、クライアントの案内に従ってサービスの権限を設定します。Clash for Windowsは開発が終了しています。旧環境から移行する際は、サブスクリプション、オーバーライドルール、システムプロキシのポートも確認しましょう。プログラムのフォルダーをコピーするだけでは移行できません。

ダウンロードページへ

macOS版クライアント

まずはClash Plusがおすすめです。デスクトップでルールを管理するなら、Clash Verge RevやFlClashも選べます。システム情報でApple SiliconかIntelかを確認し、対応するインストーラーを選んでください。ネットワーク機能を許可したら、ほかのプロキシアプリがシステム設定を変更していないか確認しましょう。アーカイブ済みのClashX Metaは旧設定の確認には役立ちますが、新しい環境での第一候補には向きません。

ダウンロードページへ

Android版クライアント

まずはClash Plusがおすすめです。Clash Meta for Android、FlClash、Surfboardの選び方も紹介しています。新しい端末の多くはARM64ですが、端末のシステム情報で確認してください。初回接続時はVPN接続の許可が必要です。バックグラウンドで切断される場合は、バッテリー最適化の設定を確認しましょう。SurfboardはClash YAMLと設定方式が異なるため、同じサブスクリプションURLをそのまま使えるとは限りません。

ダウンロードページへ

iOS版クライアント

まずはClash Plusがおすすめです。ダウンロードページにはApp Storeへのリンクと、公式サイト clashplus.ioがあります。設定を読み込んだら、画面の案内に従ってVPN構成の追加を許可し、ルールとプロキシグループが読み込まれたことを確認してください。iOSクライアントはOSが許可するネットワーク機能を使います。デスクトップのサービスモード、ポートの制御、コアの入れ替え手順をそのままスマートフォンに適用することはできません。

ダウンロードページへ

Linux版クライアント

デスクトップ環境ではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージをインストールできます。プロキシの切り替えはデスクトップ環境とアプリの対応状況によって異なり、ターミナルのツールでは環境変数を別途設定する場合があります。サーバーやルーターで使う場合は、ダウンロードページからmihomoコアを確認できます。サービスを起動する前に設定ディレクトリ、待ち受け範囲、権限を確認し、ローカルポートが意図せずLANに公開されないようにしてください。

ダウンロードページへ

mihomoコアと設定機能

GUIは管理を担い、コアは接続を処理します。以下は設定項目の例で、インポートしてすぐ使える完全なサブスクリプションではありません。実際に使うには、プロキシグループと接続情報を追加してください。

ルール分岐:宛先に応じて接続先を選ぶ

ルールモードでは、リストの順にドメイン、IPアドレス範囲、ルールセットを照合し、最初に一致したルールに指定されたプロキシ設定を適用します。すべての通信を同じ接続先に通すのではなく、ローカルサービス、仕事用リソース、その他の通信を分けたい場合に便利です。問題を調べるときは、まず接続画面で一致したルールを確認し、次にプロキシグループの選択を見ます。ルールを増やせば必ず精度が上がるわけではありません。単一のプロキシ切り替えだけを提供するツールとは異なり、mihomoではルールの配布元を分けて管理できますが、ルールセットの形式や更新間隔を把握する必要があります。以下の例はローカルのルールファイルを参照します。実際のポリシー名は設定済みのグループ名に合わせてください。

rule-providers:
  work:
    type: file
    behavior: domain
    path: ./rules/work.yaml
rules:
  - RULE-SET,work,DIRECT
  - MATCH,PROXY

Clashの使い方:3ステップで確認

まず最小限の接続を確立し、動作を確認してから通信を取り込む範囲を広げましょう。各ステップで結果を確認できる状態にすれば、サブスクリプション、プロキシの選択、システム設定を切り分けて調べられます。

  1. サブスクリプションを読み込み、設定を確認

    サブスクリプションURLまたはYAMLファイルを読み込み、設定を選びます。プロキシグループが表示され、解析エラーがないことを確認してください。URLには認証情報が含まれる場合があるため公開せず、質問時は機密情報を削除しましょう。

  2. ルールモードと接続先を選ぶ

    ルールモードを維持し、必要なグループで接続先を選びます。遅延テストは実際の通信速度を保証しません。まずブラウザーで接続を確認し、システムプロキシだけで足りる場合はTUNの導入を後回しにしましょう。

  3. 接続、DNS、終了後の復旧を確認

    接続画面で宛先、一致したルール、実際の接続先を確認します。アプリとLAN接続もテストしてください。終了前にシステムプロキシをオフにして通常の通信に戻ることを確認しましょう。詳しい対処法はガイドを参照してください。

ガイドの全手順を見る →

Clashのオープンソースエコシステムと保守状況

クライアント、コア、設定の配布元はそれぞれ独立した要素です。それぞれの役割を把握すると、ソフト名だけを覚えるより、移行や更新、問題の切り分けに役立ちます。

プロジェクトの経緯:旧版と後継の分岐を区別

ClashではYAML設定、ルール、プロキシグループを中心とした使い方が広まり、後続のクライアントはこれらの仕組みをGUIで管理できるようにしました。オリジナルのプロジェクトや一部の初期クライアントの開発終了後も、コミュニティの派生プロジェクトがプロトコルやネットワークスタックを拡張しています。古いガイドを見つけたら、まず対象クライアントを確認し、現在の画面や設定項目と照らし合わせてください。スクリーンショットが似ているというだけで、手順をすべて引き継ぐのは避けましょう。

Clash for WindowsとClash Verge Revは別のプロジェクトです。前者の開発終了は、Clash関連クライアントがすべて更新を停止したという意味ではありません。また後者への移行も、旧プログラムのフォルダーを上書きすれば完了するわけではありません。旧環境のサブスクリプションURL、ショートカットキー、サービスコンポーネント、オーバーライドスクリプトは、それぞれ記録しておきましょう。移行後は古い設定のバックアップを残し、新環境の動作を確認してから、旧サービスや残ったプロキシ設定を整理してください。

コアの系譜:Metaとmihomo

Clash Metaはmihomoの歴史を理解するうえで重要な名称です。古い記事では両方の名前が並んでいることがありますが、実際に使える機能は稼働中のコアとそのドキュメントで確認してください。GUIクライアントの設定画面では、一部の項目が表示されないことや、独自のオーバーライド機能で最終設定が生成されることがあります。画面にスイッチがないからといって、コアがその機能に対応していないとは限りません。同様に、項目を入力できても、実際に動作する保証にはなりません。

mihomoコアはGPL-3.0ライセンスのオープンソースソフトウェアです。プロジェクトのリポジトリでソースコード、リリース履歴、課題の議論を確認できます。GUIクライアント、アイコン素材、サブスクリプションサービスのライセンスや保守状況は、それぞれ個別に確認してください。コアのライセンスから他の要素の条件を推測することはできません。このサイトではクライアント選びと日本語資料をまとめていますが、実装の詳細は各プロジェクトのドキュメント、ソースコード、リリースノートを参照してください。

更新の仕組み:アプリと設定を分けて考える

クライアント、コア、サブスクリプションの更新では、それぞれ異なる部分が変わります。クライアントの更新では画面やサービスコンポーネント、設定のマージ方法が変わることがあります。コアの更新では設定項目の解析、プロトコルの挙動、DNSの処理が変わる可能性があります。サブスクリプションの更新では、主に接続先や配布元のルールが置き換わります。更新後に問題が起きたら、まずどの要素を変更したか記録し、保存した設定のコピーで再現してください。複数のコンポーネントを一度に入れ替えるのは避けましょう。

アップデート前にリリースノートを読み、ローカルのオーバーライドと必要なログを保存してください。ログではエラーの発生時刻、宛先、一致したルールを確認し、共有前にサブスクリプションURLや認証情報を削除しましょう。長期間使う端末では、内容を把握でき、元に戻せる更新方法を優先してください。テストチャンネルは特定の修正を試すためのものです。名称が新しいというだけで、安定して動作している環境を置き換える必要はありません。ダウンロードページにはインストール方法を掲載しており、トップページでは特定のリリース番号に固定していません。

コミュニティでの協力:再現できる情報で原因を探す

問題を記録するときは、OS、クライアント、動作モード、エラーが発生するまでの手順を明記し、ブラウザー、ターミナルからのリクエスト、LAN内サービスの状況を分けて説明しましょう。「接続できない」や単発の遅延結果だけでは、原因を判断できないことがほとんどです。まず最小限の設定で再現し、ルールやオーバーライドを一つずつ戻していけば、接続情報、設定の組み合わせ、ローカル環境のどこに問題があるか特定しやすくなります。

詳しく確認する場合は、プロトコルガイドで方式ごとの違いを調べ、用語集で設定項目の意味を確認できます。症状に応じた対処法はよくある質問を参照してください。オープンソースの利点は、実装を確認でき、変更を追跡でき、問題を議論できることです。すべてのプラットフォームや設定が同じ環境で動くと考えることではありません。

mihomoソースコードリポジトリ

実装やリリース履歴の確認にはリポジトリをクローンできますが、一般ユーザーがクライアントをインストールするために必要な手順ではありません。ビルドに必要な依存関係やコマンドはリポジトリの案内を確認してください。

MetaCubeX/mihomoを見る →
git clone https://github.com/MetaCubeX/mihomo.git

Linuxのペンギンアイコン:Font Awesome、CC BY 4.0。単色で表示しています。

設定とトラブル対処の記事

症状を確認したら、ログ、設定、ネットワーク経路の順に調べていきましょう。以下は新着記事3件です。基本的なインストールを終えたあと、必要に応じてご覧ください。