macOS版Clashのインストール方法｜ネットワーク拡張の許可・キーチェーンの警告・「壊れているため開けません」の対処法

インストールのブロック・ネットワーク権限・認証情報へのアクセスを切り分ける

macOSでは、Clashを含む名前のクライアントでも、インストール方法や許可の仕組みは同じとは限りません。GUI、プロキシコア、特権ヘルパー、ネットワーク拡張がそれぞれ別のコンポーネントで構成されている場合があります。Clash Metaは現在mihomoという名称です。mihomoコアを使っていても、クライアントがAppleのネットワーク拡張でTUNを実現しているとは限りません。警告に対処する前に、クライアント名、バージョン、macOSのバージョン、表示されたメッセージ全文を記録してください。すべてのパスワード入力画面を同じ権限要求だと考えないことが大切です。

インストール前にCPUアーキテクチャとアプリの配置場所を確認する

Appleシリコン搭載Macはarm64、Intel搭載Macはx64を選ぶ

Appleメニューから「このMacについて」を開きます。Apple Mシリーズチップと表示される場合は、macOS arm64またはApple Silicon版を優先してください。Intelプロセッサと表示される場合は、x64またはx86_64版を選びます。Universal版には両方のアーキテクチャが含まれる場合があります。詳しくはリリースノートを確認してください。Appleシリコン搭載MacでRosettaを使ってIntelアプリを実行できても、付属のヘルパーまで互換性があるとは限りません。

1. ローカルプロキシポートが古いプロセスに占有されないよう、起動中の同名クライアントを終了します。
2. DMGを開き、アプリを「アプリケーション」フォルダにドラッグします。ディスクイメージや「ダウンロード」フォルダから常時実行するのは避けてください。
3. DMGを取り出してから、「アプリケーション」フォルダ内のクライアントを起動します。以降の許可操作は、この場所にあるアプリを対象にしてください。
4. 最初に設定を読み込んでシステムプロキシをテストし、基本的な接続を確認してからTUNを有効にします。

同じ名前のアプリを複数残すと、ログイン項目やキーチェーンのアクセス記録と、実際に起動したアプリの場所が食い違うことがあります。更新時はアプリを終了してから、「アプリケーション」フォルダ内の既存アプリを置き換えてください。古いバージョンを起動したまま、新たにダウンロードしたアプリで許可操作を行わないでください。

「壊れているため開けません」と表示されたら、確認してから許可する

「壊れている」という警告は、ダウンロードファイルの欠損だけが原因とは限りません。署名の無効化、アプリ内容の変更、システムによる検証の失敗なども考えられます。「開発元を検証できません」と表示される場合もありますが、両者は同じ意味ではありません。警告が出たからといって、システムのセキュリティ機能をすぐに無効化しないでください。

まずはシステム標準の、アプリごとの許可機能を使う

1. インストーラーが選択したプロジェクトの正式な配布元から入手したものか確認し、システム要件とCPUアーキテクチャを照合します。
2. インストーラーを再ダウンロードし、古いアプリを完全に置き換えてから、もう一度起動します。
3. 「システム設定」→「プライバシーとセキュリティ」を開き、「セキュリティ」欄に対象アプリのブロック記録が表示されていないか確認します。
4. アプリの身元を確認してから、「このまま開く」などシステムが提示する操作を選び、画面の指示に従って認証します。

macOS 15では、正しく署名または公証されていない一部のアプリを許可する方法が変更されています。以前のガイドにある「右クリック→開く」で必ず回避できるとは限りません。悪意のあるソフトウェア、またはコンピュータに損害を与える可能性があるとシステムに明示された場合は、実行を中止して配布元を再確認してください。通常のアプリを許可する手順を、この種の警告に適用しないでください。

ターミナルでの確認は、対象アプリを特定してから行う

以下では、実際のインストール先が /Applications/Clash Verge.app のクライアントを例に説明します。アプリ名が異なる場合は、Finderに表示される実際のパスを使ってください。アプリをターミナルにドラッグすると、パスを入力できます。次の3つのコマンドは、隔離属性の確認、コード署名の整合性検証、システムによる実行評価を行います。ネットワーク権限を付与するものではありません。

xattr -p com.apple.quarantine "/Applications/Clash Verge.app"
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Verge.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Verge.app"

最初のコマンドで「No such xattr」と表示された場合、その属性が存在しないという意味であり、インストール失敗ではありません。署名検証に成功しても、配布元が信頼できることを単独で証明するものではありません。配布元と署名者の情報も確認してください。署名検証に失敗した場合は、再ダウンロードするか開発者に報告してください。失敗の原因を隠すために再署名しないでください。

配布元とアプリの完全性を確認し、隔離を解除するリスクを理解している場合に限り、そのアプリ自身の隔離属性を削除する方法を検討してください。

xattr -d com.apple.quarantine "/Applications/Clash Verge.app"

このコマンドで、破損したプログラムの修復、署名の補完、公証の取得はできません。起動失敗が解消されるとも限りません。対象を「アプリケーション」フォルダ全体に変更したり、習慣的に再帰オプションや管理者権限を追加したりしないでください。Gatekeeperをシステム全体で無効にするのも避けてください。それでも起動できない場合は、エラーを記録し、プロジェクトのインストール手順を確認してください。

TUNを初めて有効にする：ネットワーク拡張とヘルパーサービスを区別する

TUNは仮想ネットワークインターフェースとルーティングによって通信を制御します。システムプロキシに従わない一部のアプリも対象にできますが、実際の範囲はルート設定、除外設定、プロトコルの対応状況に左右されます。一方、システムプロキシは主にHTTP、HTTPS、SOCKSの設定をアプリに提供するもので、通常はネットワーク拡張のインストールを必要としません。片方のモードに必要な許可から、もう片方の許可要件を推測することはできません。

まずクライアントが採用している方式を確認する

• 特権ヘルパーまたはサービスモード：コアがTUNインターフェースを作成し、ルートやDNSを変更できるよう、ヘルパーツールのインストールを求める場合があります。この方式では、ネットワーク拡張の一覧に表示されないこともあります。
• Network Extension：Appleのネットワーク拡張を使うクライアントは、VPN構成の追加、トンネルプロバイダの実行、または該当する拡張の承認を求めることがあります。現在インストールしているアプリに対応する項目だけを許可してください。
• コンテンツフィルタ：ネットワークコンテンツのフィルタリングに関する別の警告が表示された場合は、プロジェクトのドキュメントで本当に必要か確認してください。これは、すべてのClashクライアントでTUNを有効にするために必要なものではありません。

macOSのバージョン別に許可設定を確認する

macOS 13および14では、まず「システム設定」→「プライバシーとセキュリティ」の下部に、ブロックされたシステムソフトウェアや拡張に関する表示がないか確認します。「ネットワーク」にあるVPNやフィルタの項目も確認してください。macOS 15では、「システム設定」→「一般」→「ログイン項目と機能拡張」→「ネットワーク機能拡張」を確認できます。VPN構成はシステム設定の「VPN」ページに表示されます。項目が表示されるかどうかは、クライアントの方式やインストールの進行状況によって異なります。

1. ほかのVPN、別のプロキシクライアントのTUN、ルートを変更する可能性のあるテストツールを、先に終了します。
2. 現在使用しているクライアントで、ドキュメントに記載されたヘルパーサービスをインストールし、システム認証画面に表示されたプログラム名を確認します。
3. TUNを有効にして、この操作によって直接表示されたVPN構成や拡張の要求に対応します。システムから再起動を求められた場合にのみ、再起動してください。
4. クライアントのログを確認し、権限不足、インターフェースの作成失敗、ルートの競合を切り分けます。スイッチがオンになったかどうかだけで判断しないでください。

組織管理下のMacでは、デバイス管理ポリシーによって拡張やVPN構成が制限されていることがあります。その場合は管理者に相談してください。起動時のセキュリティを下げたり、システム整合性保護を無効にしたりしないでください。この種のクライアントを通常どおりインストールするために、こうしたシステム保護を無効化する必要はありません。

キーチェーンの警告が繰り返し表示される場合：パスワード、アプリの識別情報、項目のアクセス権を確認する

キーチェーンの警告には通常、「アプリケーションがキーチェーンに保存されている機密情報を使用しようとしています」といったメッセージと、具体的な項目名が表示されます。これは、ヘルパーツールのインストール時に表示される「この操作を許可しますか」という認証画面とは異なります。要求内容をよく読んでから、「一度だけ許可」「常に許可」または拒否を選んでください。

ログインキーチェーンのパスワードは、現在のログインパスワードと異なる場合がある

通常、ログインキーチェーンはアカウントへのログイン時に自動でロック解除されます。アカウントの復旧手続きなどで別の管理者がログインパスワードをリセットすると、キーチェーンには以前のパスワードが設定されたままの場合があります。その場合、新しいログインパスワードを何度入力しても失敗することがあります。「Spotlight検索」から「キーチェーンアクセス」を開き、「ログイン」キーチェーンがロックされているか確認してから、以前のパスワードでロック解除する必要があるか判断してください。

以前のパスワードがわからなくても、警告を消すためだけにキーチェーンをリセットしないでください。リセットすると、古いキーチェーンに保存されているパスワード、証明書、トークンにアクセスできなくなることがあります。まずシステムの説明を読み、バックアップとアカウント復旧の方法を確認してから対処を決めてください。

アップデート後にアプリの識別情報が変わると、再確認を求められることがある

配布元の変更、別ブランチへの移行、異なる署名のビルドの使用、複数の場所から同名アプリを起動することなどにより、以前のアクセス許可が適用されなくなる場合があります。見た目や名前が同じでも、システムが認識するコードの識別情報が同じとは限りません。

1. 同種のクライアントをすべて終了し、「アプリケーション」フォルダ内の1つだけを起動します。
2. 「キーチェーンアクセス」で警告に表示された項目名全体を検索してください。Clashを含む名前の項目をまとめて削除しないでください。
3. 該当項目の詳細を開き、「アクセス制御」が表示されるパスワード項目では、アクセスを許可されたアプリが古いアプリを指していないか確認します。
4. 現在のアプリと該当の認証情報に関連があることを確認してから、システムの警告画面でアクセスを許可してください。すべてのアプリにアクセスを許可する設定には変更しないでください。

許可後もWebページを開けない場合：ポート、プロキシ、TUNのログを確認する

アプリが起動し、キーチェーンの警告が表示されなくなっても、解決したのはインストールまたは認証情報の問題だけです。プロキシ経路が使えるとは限りません。コアの待ち受け状態、ローカルプロキシの入口、ノードへの接続、システム側の通信制御を分けて確認してください。

ポートを指定してローカル接続をテストする

クライアントの設定に mixed-port: 7890 と明記されている場合は、次のコマンドを使用できます。7890はここでの例であり、すべてのクライアントで共通の固定ポートではありません。実際のポートは、現在有効な設定で確認してください。

lsof -nP -iTCP:7890 -sTCP:LISTEN
scutil --proxy
curl -I --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 https://example.com/

• 待ち受けの記録がない：コアが起動しているか、設定の読み込みに成功しているか、ポート番号が変更されていないか確認します。
• 待ち受けプロセスが古いクライアントのもの：古いプロセスを通常の方法で終了してから、現在のクライアントを起動します。正体のわからないシステムプロセスを強制終了しないでください。
• プロキシを指定したテストでHTTP応答がある：今回のリクエストがローカルの入口を経由できたことを示しますが、すべてのWebサイトやルールが正常とは限りません。
• プロキシを指定したテストは成功するのに、ブラウザでは失敗する：現在のネットワークサービスのシステムプロキシ、ブラウザ独自のプロキシ設定、DNS設定を確認します。

scutil --proxyでシステムプロキシの状態を確認できます。TUNだけを使っている場合、HTTPプロキシの項目がなくても正常なことがあります。TUNをテストするときは、ログでインターフェース、ルート、DNSのエラーを確認し、--proxyを付けないリクエストを実行してください。utunインターフェースが存在しても、Clashが通信を制御している証拠にはなりません。システムサービスやほかのVPNも同種のインターフェースを作成します。

終了と復旧：ネットワークを戻してから原因を調べる

ネットワークにつながらなくなった場合は、「TUNをオフ→システムプロキシをオフ→クライアントを通常終了」の順に操作します。クライアントがクラッシュした場合は、「システム設定」→「ネットワーク」→現在のWi-FiまたはEthernetサービス→「詳細」→「プロキシ」を開き、127.0.0.1を参照する設定が残っていないか確認してください。今回のクライアントが追加した項目だけを削除します。

続けて、システム設定の「VPN」ページに、今回のクライアントが有効にした接続が残っていないか確認します。組織の構成、別のVPNのネットワーク拡張、自分でインストールした証明書は削除しないでください。ネットワークが復旧したらクライアントを再起動し、まずシステムプロキシを確認してからTUNを個別にテストします。複数の条件を同時に変えて、原因を特定しにくくしないようにしてください。

問題を報告するときは、macOSのバージョン、CPUアーキテクチャ、クライアントとコアのバージョン、エラーが発生した時刻、機密情報を伏せたログを添えてください。「初回起動の失敗」「ヘルパーサービスのインストール失敗」「キーチェーンへのアクセス拒否」「TUNのルート設定失敗」を明確に分けると、再インストールを繰り返すより原因を特定しやすくなります。