チップとシステム要件を確認
Appleメニューから「このMacについて」を開き、チップまたはプロセッサ名を確認します。Apple SiliconとIntelではインストールパッケージのアーキテクチャが異なります。次にダウンロードページでクライアントの最低動作要件を確認し、アプリを「アプリケーション」フォルダへ移してから起動してください。ディスクイメージ内から常用するのは避けましょう。
システムプロキシによる通信の取り込みからルール分岐まで、Macのチップに合ったクライアントを選び、YAML設定とTUNの使い方を確認できます。
利用できる機能はクライアントの実装と使用するカーネルによって異なります。設定名は実際の画面で確認してください。
システムプロキシを設定すると、現在のネットワークサービスのHTTP、HTTPS、SOCKSの接続先がローカルの待ち受けポートになります。まずブラウザーをClashに接続したい場合に便利です。設定を読み込んでカーネルを起動したら、クライアントでシステムプロキシを有効にします。ポート番号は実行中の設定と一致させてください。Safariは通常システム設定を参照しますが、ターミナルのツールではプロキシを個別に指定する必要がある場合があります。システムプロキシは、プロキシ設定に従うアプリの通信を取り込む仕組みです。すべてのプロセスを自動的に対象にするわけではなく、最終的な接続先を決める機能でもありません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
TUNは仮想ネットワークインターフェース経由で通信を受け取り、システムプロキシ設定を参照しないアプリにも利用できます。mihomoベースのクライアントでは、通常、サービスのインストールまたは許可を済ませてからTUNを有効にし、ルーティングやDNSを設定します。システムプロキシより広い範囲の通信を取り込める一方、ほかのVPNや仮想マシン、企業ネットワークの設定と競合しやすくなります。初めて設定する場合は、まず通常のプロキシが使えることを確認してからTUNを個別にテストしてください。通信できなくなったらTUNを無効にし、ログを保存してルーティングを確認します。一度に複数の設定を変更しないでください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
ルール分岐では、リクエストの特徴に応じて、直接接続、拒否、または指定したプロキシグループへ振り分けます。ルールモードでは、カーネルがリストの上からドメインや宛先IPなどの条件を照合し、一致したルールに対応する接続先を使用します。最後にフォールバック用のルールを配置します。グローバルモードとは異なり、ルールモードではローカル向けの通信とプロキシが必要な通信を分けて処理できます。プロキシグループは接続先を選び、ルールはどのリクエストをそのグループへ送るかを決めます。両者は別の役割です。変更後は接続ログで適用されたルールを確認し、Webページが開くかどうかだけで設定の成否を判断しないでください。
mode: rule
rules:
- DOMAIN-SUFFIX,local,DIRECT
- IP-CIDR,127.0.0.0/8,DIRECT
- MATCH,DIRECT
設定の上書きを使うと、ローカル環境の設定とリモートのサブスクリプションを分けて管理できます。たとえば、待ち受けポートを固定する、LAN向けの直接接続ルールを追加する、ログレベルを変更するといった使い方があります。ダウンロードしたサブスクリプションのファイルを直接編集すると、次回の更新で変更が失われる可能性があります。上書きに対応したクライアントなら、実行用の設定を生成する際にローカルの内容を統合できます。ただし、これはClashカーネル共通の機能ではなく、オブジェクトや配列、スクリプトの扱いはクライアントごとに異なります。有効にする前に元の設定をバックアップし、統合順序を確認してください。特に、ルールが追加される位置や、同じ名前のプロキシグループが置き換わっていないかを最終的な設定で確認しましょう。
mixed-port: 7890
allow-lan: false
log-level: info
まず通常のシステムプロキシ接続を確認し、必要に応じてTUNや設定の上書きを追加すると、各手順の変化を把握しやすくなります。
Appleメニューから「このMacについて」を開き、チップまたはプロセッサ名を確認します。Apple SiliconとIntelではインストールパッケージのアーキテクチャが異なります。次にダウンロードページでクライアントの最低動作要件を確認し、アプリを「アプリケーション」フォルダへ移してから起動してください。ディスクイメージ内から常用するのは避けましょう。
信頼できる提供元のサブスクリプションURL、またはローカルのYAMLファイルを使用します。読み込み後、設定が選択されていることを確認し、プロキシグループで接続先を選びます。クライアントと設定の提供元は別のものです。アプリをインストールしただけでは、利用可能なリモートノードやネットワークサービスは用意されません。
カーネルの起動後にシステムプロキシを有効にし、ブラウザーで必要なサイトにアクセスしてから、接続ログで宛先、適用ルール、プロキシグループを確認します。ブラウザーでは接続できてもターミナルで失敗する場合は、ターミナル側でプロキシを指定しているか確認してください。原因をすぐにノードと決めつけたり、クライアントを再インストールしたりしないでください。
初回の接続では、通信を取り込む方法を一つだけ有効にするのがおすすめです。ほかのVPNやプロキシツールを同時に使っている場合は、用途を記録して一時停止し、ルートやDNSを複数のプログラムが交互に変更するのを避けてください。テスト後はクライアントを通常の手順で終了し、システムプロキシが元の状態に戻ったことを確認します。権限の許可手順や問題発生時の復旧方法は設定ガイドを参照してください。
OS別のクライアント一覧から選べます。インストールパッケージ、対応アーキテクチャ、システム要件はダウンロードページで確認してください。
複数のデバイスで使う場合、設定の構文が似ていても機能がすべて共通とは限りません。まずクライアントが採用するカーネルを確認し、プロトコル、ルールセットの形式、DNS設定項目に対応しているか調べてください。Macのシステムプロキシ、モバイル端末のVPN許可、デスクトップのサービスインストールは、各プラットフォームで通信を取り込む方法です。ある端末の画面操作を別の端末にそのまま当てはめないでください。サブスクリプションを共用する場合も、ローカルの待ち受けポート、ファイルパス、画面上の設定は各端末に分けて保存しましょう。
まずApple SiliconまたはIntelに合ったパッケージを選び、Clash Plus、Clash Verge Rev、FlClashの設定管理方法を比較しましょう。メニューバー操作やTUNが必要な場合は、画面上の機能とサービスの権限をそれぞれ確認してください。特定のクライアントの設定項目を、すべてのMac向けクライアントに共通する機能と考えないようにしましょう。
ダウンロードページへ macOSクライアントClash PlusやClash Verge RevなどのGUIクライアントを確認し、macOSのバージョンとアーキテクチャ要件をチェックしてください。Clash for Windowsの代替を探している場合は、移行前にサブスクリプションとローカルルールをバックアップします。ストア版アプリでループバック接続の問題が起きた場合は、設定ガイドのWindows向け補足を参照してください。
ダウンロードページへ Windowsクライアント端末のプロセッサアーキテクチャに合ったインストールパッケージを選び、初回接続時はシステムのVPN許可ダイアログを確認してください。モバイルOSのバックグラウンド制限で接続が途切れることがあります。ネットワークを切り替えたら、名前解決と接続状態を改めて確認しましょう。デスクトップのシステムプロキシと同じ手順で原因を調べられるとは限りません。
ダウンロードページへ AndroidクライアントダウンロードページにはClash PlusのApp Storeリンクと公式サイト clashplus.io を掲載しています。設定を読み込んだら、システムの案内に従ってVPN構成を追加し、利用するアプリで接続を確認してください。Macとサブスクリプションを共用する前に、モバイル版が設定内のプロトコルや項目に対応しているか確認し、各端末のローカル設定は個別に保存しましょう。
ダウンロードページへ iOSクライアントデスクトップ環境ではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージ形式を確認してください。サーバーやルーターで使う場合は、カーネルのダウンロードページからmihomoを確認できます。カーネル単体で動かすには、設定ディレクトリやプロセス管理、ネットワーク権限を自分で設定する必要があります。デスクトップのメニューから通信を取り込むことはできません。
ダウンロードページへ Linuxクライアントポートと通信の取り込み方法。このページの画面例に表示されるのはローカルプロキシの接続口で、リモートノードのアドレスではありません。クライアントで別のポートを使う場合は、システムのネットワーク設定やコマンドライン引数も合わせて変更します。YAMLのポートだけ変更して設定を再読み込みしないと、実行中のプロセスは古い値を使い続けることがあります。ログと現在の待ち受けポートを確認してから接続をテストしてください。
サブスクリプションとローカルの変更。サブスクリプションURLには認証情報が含まれる場合があります。機密情報として管理し、公開画像やリポジトリに載せないでください。クライアントを乗り換えるときは、まずローカルルールと上書き設定をエクスポートしてから、サブスクリプションを再読み込みします。アプリのデータフォルダを丸ごとコピーすると、古いパスやキャッシュ、互換性のない画面設定まで引き継ぐことがあります。
Clashのエコシステムは、ひとつの名前で統一された単一のソフトウェアではありません。設定の解析、ルールの実行、接続の確立を担うのがカーネルです。サブスクリプション管理、システムプロキシの切り替え、メニューバー、アップデート画面を担うのがGUIクライアントです。この役割分担を理解すると、「画面に設定項目がない」「設定項目がサポートされていない」「通信の取り込みが機能していない」といった問題を切り分けられます。再インストールや根拠のない設定変更を減らすことにもつながります。
オリジナル版Clashの開発終了後も、コミュニティでは派生カーネルやGUIクライアントの開発が続いています。mihomoはClash Metaの系譜を引き継ぎ、多くの既存設定項目を維持しながら独自の機能も追加しています。古い設定を読み込めても、新しいプロトコルやルールセット形式、DNS設定が旧カーネルで動作するとは限りません。解析エラーが発生したら、アプリのアイコンやインストーラー名だけで判断せず、実際に動作しているカーネルの名称を確認して対応するドキュメントを調べてください。
古いガイドでは、メニュー名や権限の設定手順が現在と異なる場合もあります。参考にする際は、「現在のネットワークサービスのプロキシ設定を開く」「実行中の最終設定を確認する」など、操作の目的を読み取り、使用中のクライアントで該当する項目を探してください。アーカイブされたクライアントは過去の設定を理解する手がかりになりますが、選定時は現在のOSとの互換性やプロジェクトの説明を確認しましょう。古い画面キャプチャが現行画面と同じとは限りません。
同じmihomoを使うクライアントでも、設定の上書き方法、サブスクリプションの更新方法、システムサービスの管理手順は異なる場合があります。カーネルが設定項目に対応していても、GUIに専用のボタンがあるとは限りません。画面にTUNの切り替えがあっても、サービスの権限が設定済みとは限りません。問題を調べる際は、まず設定の生成、次にカーネルの起動、最後にOSから正しい接続口へ通信が送られているかを確認します。複数の設定を一度に変更するより、段階を分けて検証するほうが結果を再現しやすくなります。
このページのYAML例は設定項目の位置を示すもので、そのまま接続できる完全なサブスクリプションではありません。実際に使うには、ノード、プロキシグループ、用途に合ったルールも必要です。既存のファイルに例を追加する前に、インデントと項目の階層を確認し、トップレベルのキーを重複させないようにしてください。変更後はクライアントの設定チェック機能を使ってから実行用の設定を再読み込みし、元に戻せるよう変更前のバックアップを残しましょう。
mihomoのソースコードとドキュメントでは、設定項目の意味、プラットフォームごとの制限、変更履歴を確認できます。カーネルのリポジトリとGUIクライアントのリポジトリは分けて調べてください。プロキシプロトコル、ルール照合、DNSの動作は通常カーネルのドキュメントを、サブスクリプション一覧、メニューバー、サービスのインストールは該当クライアントの説明を参照します。コードを公開しているため実装を追跡できますが、設定の提供元やローカルの権限に関する判断に代わるものではありません。
プロジェクトに問題を報告する際は、必要なシステム情報、カーネルの種類、再現に必要な最小限の設定を添えてください。ログにはアクセス先のドメイン、サブスクリプションURL、ノード情報が含まれる場合があります。公開する前に必ず機密情報を削除してください。「何を操作したか」「期待した結果」「実際に起きたこと」を具体的に説明し、日常使用している設定を丸ごとアップロードしないようにしましょう。開発者が問題を特定しやすくなり、関係のない情報の公開も防げます。
クライアント、カーネル、サブスクリプションの更新は、それぞれ別の手順です。クライアントの更新で設定管理や権限の手順が変わることがあり、カーネルの更新では設定項目の動作が変わる場合があります。サブスクリプションの更新ではノードやルールが置き換わる可能性があります。更新前に通信の取り込み方法とローカルの上書き設定を記録し、更新後はブラウザー、コマンドライン、LAN内のサービスを個別に確認してください。アプリが起動しただけで、すべての通信経路が正常とは限りません。
更新後に問題が起きたら、まず最終的な実行設定とログを比較し、どの層を元に戻すか判断します。リモートのサブスクリプションに変更が上書きされた場合は、アプリを再インストールするよりローカルルールを復元するほうが直接的です。システムプロキシが残っている場合はネットワークサービスの設定を、TUNを起動できない場合はサービスの許可と競合するプログラムを確認してください。一度に変更する項目を一つに絞ると、原因を追う手がかりを残せます。
実装や変更履歴を調べるためのものです。通常のインストールでリポジトリを複製したり、カーネルを自分でビルドしたりする必要はありません。
git clone https://github.com/MetaCubeX/mihomo.git
ローカル接続の問題からプロキシグループの選び方まで、目的に合った記事を確認できます。
ノードの品質、接続先の回線、Macの設定を順に確認。DNSモード、TUNのスタック選択、Wi-Fiの省電力設定による影響も取り上げ、macOSの速度低下の原因を絞り込みます。
記事を読む →3種類の自動プロキシグループについて、速度測定の仕組み、切り替えタイミング、intervalやtoleranceなどの設定項目を解説。YAML例と用途別の選び方も紹介します。
記事を読む →オリジナルカーネルの開発終了からmihomoへの移行までをたどり、カーネル、GUIクライアント、ルールセットプロジェクトの役割を整理。macOSに適したクライアントの組み合わせ選びをサポートします。
記事を読む →