macOSにClashクライアントをインストール：ネットワーク拡張、VPN認証、キーチェーンの確認

インストール前にチップのアーキテクチャとクライアント形態を確認

macOSでいう「Clash」は、GUIクライアントを指す場合もあれば、mihomoなどのコマンドラインコアを指す場合もあります。GUIクライアントはサブスクリプションの取り込み、プロキシグループの選択、システムプロキシの切り替え、ログ表示を担当します。コアは設定の読み込み、ローカルポートの待ち受け、ルールの実行を担います。GUIクライアントのインストール時に表示されるネットワーク拡張、VPN構成、補助ツールの許可は、クライアントが採用する通信の取り込み方式に由来するもので、サブスクリプションサービスが同じシステム権限を取得するという意味ではありません。

Apple SiliconとIntelのインストーラーを取り違えない

M1、M2、M3、M4シリーズを搭載したMacはApple Siliconで、対応するインストーラーには通常 arm64、aarch64、またはApple Siliconと記載されています。古いIntel Macでは x64、x86_64、またはIntelを選びます。画面左上のAppleメニューから「このMacについて」を開けば、「チップ」または「プロセッサ」の項目を確認できます。ターミナルで次のコマンドを実行する方法もあります。

uname -m

• arm64 と表示された場合：macOS ARM64またはApple Silicon版を選択します。
• x86_64 と表示された場合：macOS x64またはIntel版を選択します。
• Apple SiliconではRosetta 2を使ってIntelアプリを動かせる場合もありますが、長期利用には通常、ネイティブのARM64版が適しています。

ダウンロードページでは、アプリのインストーラーと単体コアも区別してください。一般的な .dmg ファイルはディスクイメージを開き、アプリを「アプリケーション」へドラッグして使います。.pkg ファイルはシステムインストーラーで実行します。圧縮ファイルを展開して得られる単体の実行ファイルは通常コアであり、GUIクライアントの手順でメニューバーのアイコンを探すものではありません。

アプリケーションへ移してから初回起動する

1. ダウンロードした .dmg を開きます。
2. クライアントのアイコンを「アプリケーション」フォルダへドラッグし、ディスクイメージや「ダウンロード」フォルダから長期間起動しないでください。
3. ディスクイメージを取り出し、Finderの「アプリケーション」からクライアントを起動します。
4. 初回起動後、メニューバー、Dock、またはメインウィンドウにクライアントの入口が表示されることを確認します。

「アプリケーション」フォルダに固定しておけば、アップデート後のパス変更を避けられます。また、ログイン項目、補助ツール、ネットワーク拡張がどのホストアプリに属するかもシステムが認識しやすくなります。読み取り専用のディスクイメージから直接実行すると、クライアントが更新ファイルを書き込めないことがあります。ランダムな展開先から起動すると、同じ名前でバージョンの異なるコピーが複数残る場合もあります。

「開けない」や開発元に関する安全確認を処理する

macOSのインストール時に表示される安全確認は、Gatekeeper、アプリの署名、公証の状態、ダウンロード時の隔離属性などによって発生します。表示内容によって対処も異なります。「開発元を確認できない」「アプリが壊れている」「アプリをアップデートする必要がある」は、同じ障害として扱わないでください。

「開発元を確認できない」と表示された場合は一度だけ許可する

インストーラーが、選択したクライアントの上流プロジェクトの正式な配布元から入手したものだと確認できる場合は、Finderでアプリを選び、Controlキーを押しながらクリックして「開く」を選択し、確認ダイアログでもう一度「開く」をクリックします。別の方法として、macOS 13以降では「システム設定」→「プライバシーとセキュリティ」を開き、安全確認の項目から直前にブロックされたアプリを探して「このまま開く」を選択できます。これはそのアプリだけに対する一度限りの確認であり、Mac全体の安全レベルを変更する必要はありません。

macOS 12以前では通常、「システム環境設定」→「セキュリティとプライバシー」→「一般」を使います。メニュー名は異なりますが、原則は同じです。まずアプリを一度起動してシステムにブロック履歴を記録させ、その後セキュリティ設定でアプリ名と入手元を確認します。

「アプリが壊れている」は通常の未確認アプリとは異なる

「壊れているため開けません」という表示は、ダウンロードの不完全さ、署名状態の異常、アプリの改変、古いビルドと現在のmacOSの非互換などが原因で発生します。まず現在のコピーを削除し、チップのアーキテクチャに合うビルドを再ダウンロードして、アプリが「アプリケーション」に完全にコピーされていることを確認します。上流のリリースノートに最低システム要件が記載されている場合は、現在のシステムが条件を満たすかも確認してください。

さらに確認する必要がある場合は、ターミナルでアプリの署名とシステム評価結果を確認できます。次の例では、標準フォルダにインストールしたClash Verge Revを対象にしています。コマンドは状態を読み取るだけです。

codesign -dv --verbose=4 "/Applications/Clash Verge Rev.app" 2>&1
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge Rev.app"

codesign の出力では識別子、署名機関、ランタイム設定を確認できます。spctl は、システムがそのアプリを受け入れるかどうかの評価結果を返します。アプリ名が異なる場合は、Finderから実際のアプリをターミナルへドラッグして正確なパスを取得してください。フォーラムにある古いコマンドを使って、すべてのアプリの安全属性を一括削除しないでください。

ネットワーク拡張、VPN構成、システムプロキシの違い

Clashクライアントでよく使われる通信の取り込み方式には、システムプロキシとTUNがあります。システムプロキシは主に、現在のmacOSネットワークサービスのHTTP、HTTPS、SOCKSプロキシ設定を変更します。TUNは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を取り込みます。クライアントがネットワーク拡張、VPN構成、管理者権限を要求するかどうかは、TUNをどのように実装しているかで決まり、「ルールモード」や「グローバルモード」といったプロキシ戦略で決まるものではありません。

システムプロキシだけを使う場合、通常はVPN構成は不要

クライアントで「システムプロキシ」を有効にすると、プロキシサーバーが現在のネットワークサービスに書き込まれます。ローカルアドレスは 127.0.0.1、mixedの待ち受けポートは 7890 が一般的です。古い設定ではHTTPポートに 7890、SOCKSポートに 7891 を使う場合もあります。これらは全クライアント共通の固定値ではないため、クライアントの「設定」→「ポート設定」、実行ログ、現在の設定にある mixed-port、port、socks-port を確認してください。

システムプロキシは、macOSのネットワークプロキシ設定に従うアプリに適しています。一方、ターミナルの curl、パッケージマネージャー、開発ツール、一部のクロスプラットフォームアプリは設定を無視することがあります。この場合、ブラウザーは接続できるのにターミナルだけ失敗しても、ネットワーク拡張が壊れているとは限りません。アプリ独自のプロキシ設定を確認するか、現在のターミナルセッションに HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を明示的に設定してください。

TUNを有効にするとVPNやネットワークコンテンツフィルタの確認が表示されることがある

クライアントがApple Network ExtensionでTUNを構築すると、macOSからVPN構成の追加やネットワーク拡張の許可を求められることがあります。確認ダイアログのアプリ名が、直前に操作したクライアントと一致することを確認してから許可してください。許可後、macOS 13〜15では「システム設定」→「ネットワーク」→「VPNとフィルタ」を開くと、通常はそのクライアントが管理する項目を確認できます。

別のクライアントでは、特権ヘルパーツールを使って仮想インターフェースを作成したり、ルーティングテーブルを維持したりします。サービスの初回インストール時には、管理者アカウントのパスワード入力またはTouch IDが求められます。この確認はシステムレベルの許可であり、サブスクリプションアカウントへのログインではありません。入力するのは現在のMacの管理者資格情報で、macOSの認証ウィンドウが処理します。サブスクリプションURL、プロキシノードのパスワード、サイトのアカウント情報は入力しないでください。

キーチェーンの確認が信頼できるか判断する

macOSには、混同しやすいパスワードダイアログが2種類あります。1つ目はシステム管理者の認証で、通常はユーザー名、パスワード入力欄、またはTouch IDが表示され、補助ツールのインストール、ネットワーク設定の変更、特権サービスの起動に使われます。2つ目はキーチェーンアクセスのダイアログで、通常は特定のアプリがキーチェーン内のどの項目へアクセスしようとしているかが表示され、「拒否」「許可」「常に許可」などを選べます。

要求元、キーチェーン項目、操作のきっかけを確認する

1. サービスのインストール、TUNの有効化、ログイン時の起動設定、認証情報の保存などの操作直後に表示されたものか確認します。
2. アクセスを要求しているアプリ名が、現在起動したクライアントと一致するか確認します。
3. キーチェーン項目の名前が、クライアント、補助ツール、設定済みの認証情報に対応しているか確認します。
4. クライアントを起動していないときにも繰り返し表示される場合は、まず「拒否」を選び、ログイン項目、旧バージョンの残留物、キーチェーン項目を確認します。

「常に許可」を選ぶと、同じ署名IDのアプリが今後その項目へアクセスする際の確認回数を減らせます。用途を確認済みで、クライアントの正常動作にその項目が実際に必要な場合に適しています。用途を判断できない場合は、まず一度だけ「許可」を選び、クライアントの機能が戻るか確認してください。長期的なアクセスをすぐに与えるより、問題を切り分けやすくなります。

アップデート後に繰り返し確認される場合は署名や旧項目が原因かもしれない

クライアントのアップデート、アプリ名の変更、署名IDの変更、異なる配布元からの上書きインストール後は、キーチェーンが新バージョンを別の要求元として扱うことがあります。まず同名のクライアントをすべて終了し、「アプリケーション」には使用する1つだけを残してから再起動します。その後「キーチェーンアクセス」を開き、「ログイン」キーチェーンでクライアント名を検索し、項目の作成日時と「アクセス制御」リストを確認します。

ログインキーチェーン全体を一度に削除しないでください。ある項目がアンインストール済みの旧クライアント専用だと確認できた場合は、名前を控えてからその項目だけを削除し、現在のクライアントに再作成させます。削除後にクライアントがプロキシ認証情報の再入力や補助サービスの再インストールを求めた場合は、現在のバージョンの設定手順に従ってください。

初回設定と許可を順番に進める

複数のスイッチを同時に有効にすると、原因を特定しにくくなります。まずクライアントとコアが起動できることを確認し、次に設定を取り込み、ローカルポートを確認してから、最後にシステムプロキシまたはTUNを順番に有効にするのが安全です。

手順1：クライアントを起動してコアの状態を確認

クライアントを開いたら、まず「設定」または「設定」→「コア設定」でコアが準備完了になっているか確認します。クライアントによっては、状態がホーム、ログ、サービス管理のページに表示されます。ログに設定の解析エラーが出続ける場合は、まず設定を修正し、許可操作を繰り返して解決しようとしないでください。よくある原因は、YAMLのインデント不備、存在しないプロキシを参照するプロキシグループ、未定義の PROXY プロキシグループを指定したルール、他のプロセスによるポートの使用です。

ターミナルで、よく使われるポートがすでに待ち受け状態か確認できます。

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:7891 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

7890 と 7891 はプロキシの待ち受けに、9090 は外部コントロールインターフェースに使われることが多いポートです。ただし、実際のポートは現在の設定を確認してください。同じポートを旧クライアントが使用している場合は、複数の設定ファイルを不用意に変更せず、まず旧クライアントを完全に終了します。

手順2：サブスクリプションを取り込み、現在の設定を選択

1. クライアントの「設定」または「サブスクリプション」ページを開きます。
2. サブスクリプションサービスから提供されたURLを使って設定を取り込みます。
3. ダウンロードが完了するまで待ち、更新日時と設定名を確認します。
4. 新しく取り込んだ設定を現在の設定に指定します。
5. 「プロキシ」または「プロキシグループ」を開き、手動選択が必要なグループに利用可能なノードを指定します。

取り込みが成功したということは、クライアントが設定ファイルを取得できたことを示すだけで、システム通信がすでにClashへ入ったことを意味しません。コアの読み込み成功、プロキシグループに選択肢があること、システムプロキシまたはTUNの少なくとも一方が有効であることも確認が必要です。サブスクリプション更新で、サブスクリプション内に直接加えた変更が上書きされる場合もあります。長期的なカスタムルールには、クライアントが対応するオーバーライド、マージ、スクリプト機能を使ってください。

手順3：まずシステムプロキシをテストし、必要ならTUNを有効にする

クライアントの「システムプロキシ」を有効にした後、scutil --proxy を実行すると、macOSの現在のプロキシ状態を確認できます。出力されるHTTP、HTTPS、SOCKSのスイッチがクライアントの設定と一致するか確認してください。クライアントでは有効と表示されるのにシステム側の出力が変わらない場合は、現在のネットワークサービスが切り替わっているか、ネットワーク設定の変更に必要な許可をクライアントが得ているか、別のプロキシツールが設定を上書きしていないかを確認します。

scutil --proxy
curl --proxy http://127.0.0.1:7890 https://example.org/

2つ目のコマンドは、リクエストをローカルの 7890 ポートへ明示的に送ります。「コアとノードが利用可能か」と「システムプロキシがターミナルで使われていないか」を切り分けるのに適しています。明示的なプロキシでは成功するのに、curl https://example.org/ を直接実行すると失敗する場合は、ネットワーク拡張を再インストールするのではなく、ターミナルのプロキシ環境を確認します。

システムプロキシに従わないアプリ、UDP通信、より広範なアプリ通信を取り込む必要がある場合に、TUNを検討します。有効化後にVPN構成や管理者認証の確認が表示されたら、前述の手順でアプリ名と操作のきっかけを確認してください。TUNが正常に構築されると、ログに仮想インターフェース、ルート、DNSモジュールの起動情報が表示されることがあります。具体的なインターフェース名はクライアントとコアの実装によって異なります。

許可後も接続できない場合の段階的な切り分け

システムプロキシは有効だがブラウザーに通信がない

• 「システム設定」→「ネットワーク」→現在使用中のWi-FiまたはEthernet→「詳細」→「プロキシ」を開き、サーバーが 127.0.0.1 になっているか、ポートがクライアントと一致しているか確認します。
• メニューバーに画面が常駐しているだけでなく、クライアントのコアが実行中であることを確認します。
• ブラウザーに独立したプロキシ管理拡張機能が入っていないか、独自のプロキシ設定を使っていないか確認します。
• ルールのマッチログを確認し、リクエストが REJECT へ送られていないこと、対象のプロキシグループに利用可能なノードがあることを確認します。
• システムプロキシを変更する他のネットワークツールを一時的に終了し、複数のプログラムが設定を交互に書き換えないようにします。

TUNを有効にするとすぐにネットワークが切れる

まずTUNを無効にして基本的なネットワークを復旧し、クライアントログの最初のエラーを確認します。よくある原因は、仮想インターフェースの作成失敗、ルートの競合、DNS待ち受けポートの競合、補助サービスの未起動です。システム設定に旧クライアントが残したVPN構成が複数ある場合は、使っていない構成を無効にできますが、所属を確認せずに会社のVPN、リモートワーク用VPN、その他のネットワーク拡張を一括削除しないでください。

設定のDNS部分が現在のコアバージョンに対応しているかも確認してください。mihomoがサポートするDNSオプションはバージョンによって変化するため、古いClash設定をそのまま移行できるとは限りません。「フィールドが存在しない」「型が正しくない」「待ち受けアドレスが競合している」といったエラーが出た場合は、macOSのVPN許可が原因だと決めつけず、現在のクライアントに組み込まれたコアのドキュメントに従って設定を調整します。

再起動後にプロキシのスイッチが無効になる

「システム設定」→「一般」→「ログイン項目と機能拡張」を開き、クライアントのログイン時起動が許可されているか、関連するバックグラウンド項目が有効か確認します。クライアントによっては「ログイン時に起動」「サイレント起動」「起動後にシステムプロキシを設定」が別々の項目です。最初の項目だけを有効にしても画面が起動するだけで、通信が自動的に取り込まれるとは限りません。

クライアントが特権サービスを必要とする場合は、「設定」→「サービスモード」または「TUN設定」でサービスの状態も確認します。アップデート後にサービスとクライアントのバージョンが一致しない場合は、クライアントに用意された「サービスを再インストール」または「サービスを修復」機能を優先して使い、その後に表示されるシステム管理者の認証画面にも注意してください。

クライアント終了後もシステムにプロキシが残る

異常終了すると、システムプロキシを元に戻す処理が間に合わないことがあります。同じクライアントを再度開き、システムプロキシを一度有効にしてから無効にすると、通常は完全なクリーンアップが実行されます。「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」でHTTP、HTTPS、SOCKSの項目を確認し、不要なスイッチがオフになっていることを確認する方法もあります。

アップデート、クライアント変更、アンインストール時に権限を整理する

同じクライアントを上書きアップデートする前に旧バージョンを終了し、メニューバーのアイコンが消えたことを確認します。インストール後は、バージョン番号、コアのバージョン、現在の設定、システムプロキシの状態を確認します。新バージョンの初回起動でネットワーク拡張や補助サービスの許可を再び求められた場合は、アプリの署名と入手元を確認したうえで必要に応じて許可してください。システムが権限を再確認しても、サブスクリプション設定が失われたとは限りません。

クライアントを変更するときはシステムネットワークを同時に取り込ませない

ClashX Meta、Clash Verge Rev、FlClashなどのクライアントを切り替える場合は、残したい設定を先にエクスポートするか、サブスクリプションの入口を記録します。その後、旧クライアントでシステムプロキシを無効にし、TUNを無効にして、アプリを終了します。新しいクライアントを起動してローカルポートを確認してから、取り込み方式を1つだけ有効にしてください。2つのクライアントが同時に 7890 を待ち受けたり、システムプロキシを同時に変更したりすると、ポート競合や表示状態と実際の設定の不一致が起こります。

アンインストールはアプリをゴミ箱へ入れるだけでは不十分

1. クライアント内でシステムプロキシとTUNを無効にします。
2. クライアントに「サービスをアンインストール」や「補助ツールを削除」の機能がある場合は、まず設定ページから実行します。
3. クライアントを終了し、アクティビティモニタに同名のプロセスが残っていないことを確認します。
4. 「システム設定」→「ネットワーク」→「VPNとフィルタ」で、そのクライアントが作成した構成を確認します。
5. 「システム設定」→「一般」→「ログイン項目と機能拡張」で、ログイン項目とバックグラウンド項目を確認します。
6. ローカル設定が不要になったことを確認してから、アプリと専用の設定フォルダを削除します。

アップデートや一時的なトラブル調査が目的なら、最初からすべての設定を削除することはおすすめしません。利用可能な設定と最近のログを残しておけば、問題がアプリのアップデート、コアの読み込み、システム権限、サブスクリプション内容のどこで発生したか判断できます。インストール後の最小限の確認項目は、アプリが起動すること、コアに設定エラーがないこと、ローカルポートが待ち受けていること、明示的なプロキシリクエストが成功すること、システムプロキシまたはTUNを想定した一方だけ有効にすること、終了後にシステムネットワークが復旧することです。