macOSでv2rayNを開けない・開発元を検証できない場合の対処法｜Gatekeeperとネットワーク権限

この記事の概要

macOS版v2rayNをダウンロードしたものの開けない方や、メイン画面は起動するのにネットワークへ接続できない方に向けた手順です。まずチップの種類とインストール先を確認し、「システム設定」でGatekeeperのブロックを解除します。隔離属性の確認は、ファイルの入手元が明確で通常の許可でも解決しない場合に限ります。最後に、コアの起動、ローカルポートの待ち受け、システムプロキシ、必要に応じた権限を個別に確認し、接続問題をすべて「権限不足」と決めつけないようにしましょう。

まず切り分ける：起動ブロック・コアの起動・プロキシの適用

「開発元を検証できない」と「Webページが開けない」では、問題が起きる段階が異なります。前者は通常、ダウンロードしたアプリに対するmacOSの信頼性チェックです。後者は、コアが起動していない、プロキシポートが一致しない、ノード設定に問題がある、またはネットワーク自体に問題がある可能性があります。v2rayNはGUIクライアントです。ウィンドウが表示されても、利用するコアが正常に起動して待ち受けているとは限りません。

まず警告ダイアログの文面を控え、表示されたタイミングに応じて対処方法を選びましょう。接続に失敗したからといって、ターミナルにフルディスクアクセスを許可したり、アプリを開くためだけにMac全体のセキュリティチェックを無効にしたりしないでください。

表示された症状	まず確認する項目	次に行うこと
開発元を検証できない／悪質なソフトウェアが含まれているか確認できない	Gatekeeperによるアプリの信頼性判定	「プライバシーとセキュリティ」で許可の記録を確認
アプリが破損しているという警告が出る	ダウンロードの完全性、アプリの改変、署名の状態	まず再ダウンロードし、隔離属性の問題と決めつけない
ウィンドウは表示されるが、ログにコアの起動失敗と出る	コアのアーキテクチャ、実行権限、ローカルポート	最初に発生した起動エラーと、エラー対象のファイルパスを確認
コアは正常だが、ブラウザーがプロキシを使わない／プロキシエラーが出る	システムプロキシの設定と実際の待ち受け先が一致しているか	ネットワーク設定とローカルプロキシポートを確認

インストール前にチップとアプリの保存場所を確認

Appleメニューから「このMacについて」を開きます。「Appleチップ」と表示されたMacにはARM64版、「Intelプロセッサ」と表示されたMacにはx64版を選んでください。アーキテクチャが合わないとアプリが動作しなかったり、画面は起動しても同梱コアが起動しなかったりすることがあります。ネットワーク権限を有効にしても解決しません。

macOS版をダウンロード：ダウンロードセンターでチップに合ったDMGを選択します。Windows用のプログラムファイルをmacOSアプリとして実行しないでください。
「アプリケーション」にコピー：DMGを開き、アプリをFinderの「アプリケーション」フォルダにドラッグします。コピーが完了したらディスクイメージを取り出し、「アプリケーション」から起動してください。
古いコピーとの混在を避ける：Dockに登録した古いアイコンは、ダウンロードフォルダやディスクイメージ内のアプリを指している場合があります。最初のトラブルシューティングでは、Finderから対象のアプリを直接ダブルクリックしてください。
アップデート前にバックアップ：クライアントが対応する方法で設定をバックアップしてください。サブスクリプションURL、認証情報、資格情報を含む設定を公開の掲示板に投稿しないでください。

以下のコマンドでは、アプリが実際に /Applications/v2rayN.app にあるものとして説明します。Finder上のファイル名が異なる場合は、Finderから実際のアプリをターミナルにドラッグしてパスを入力してください。パスにスペースが含まれる場合は、引用符またはターミナルが自動生成したエスケープを残します。

開発元を検証できない場合：まず「システム設定」から許可

Gatekeeperは、アプリの署名、公証、ダウンロード元などをもとに判定します。「開発元を検証できない」という表示だけでファイルが危険だとは限りませんが、リスクを無視してよいという意味でもありません。ダウンロード元と選択したインストーラーを確認したうえで、このアプリに限って明示的に許可してください。macOSのバージョンによってボタンの表示が異なる場合があります。以下では「システム設定」の画面に沿って説明します。

警告を表示させる

「アプリケーション」からv2rayNをダブルクリックし、ブロックの警告を読んで閉じます。まず一度起動を試すと、「セキュリティ」設定に対象アプリの記録が表示される場合があります。
セキュリティ項目を探す

Appleメニューから「システム設定」→「プライバシーとセキュリティ」を開き、下へスクロールして「セキュリティ」欄を確認します。表示された記録が、先ほど起動したアプリのものか確かめてください。
今回の起動を許可する

「このまま開く」または同等のボタンをクリックし、案内に従ってアカウントのパスワードまたはTouch IDで認証します。確認ダイアログが表示されたら「開く」を選択してください。
起動を確認する

メイン画面が表示されるまで待ち、ログにコアの起動エラーがないか確認します。画面の起動だけを許可したあと、別の実行ファイルを指す警告が表示された場合は、それが現在のインストールパッケージに含まれるものか確認してください。
許可する項目が見つからない場合

アプリの起動をもう一度試してから、「プライバシーとセキュリティ」を確認してください。組織の管理下にあるデバイスで実行がポリシーにより禁止されている場合は、管理者に相談してください。管理ポリシーを回避しないでください。

隔離属性：まず確認し、削除するか判断

ブラウザーでダウンロードしたアプリや圧縮ファイルには、com.apple.quarantine 拡張属性が付いていることがあります。展開・コピー後のアプリにも属性が残る場合があります。これはダウンロード元のチェックに使われるもので、ファイルの破損を示す印ではありません。入手元、インストール先、アプリの実体を確認し、通常の許可でも解決しない場合に限り、個別のアプリに対する処理を検討してください。

「システム設定」から許可

隔離属性を個別に処理

ターミナルで属性を確認し、対象のアプリパッケージであると確認できた場合に限って削除します。アプリパッケージ内のファイルにも影響するため、コマンドのパスを確認してください。

適しているケース：通常の許可後も隔離属性に関連するブロックが残り、ファイルの入手元を確認できている場合。

「アプリケーション」→「ユーティリティ」→「ターミナル」を開き、まず読み取り専用の確認を行います。以下の2つのコマンドは別々に実行してください。削除コマンドを、あらゆるインストール失敗に対する定型手順として使わないでください。

# 対象アプリの隔離属性を確認
xattr -p com.apple.quarantine "/Applications/v2rayN.app"

# 入手元とパスを確認した場合に限り、アプリパッケージの隔離属性を再帰的に削除
xattr -dr com.apple.quarantine "/Applications/v2rayN.app"

確認結果が No such xattr の場合、その対象に該当の属性はありません。ただし、内部のファイル、署名、アーキテクチャが正常であるとは限りません。
No such file と表示された場合は、実際のファイル名とインストール先を確認してください。ディスク全体を検索するコマンドに変更しないでください。
Permission denied または Operation not permitted と表示された場合は、まずファイルの所有者、アプリの保存場所、デバイス管理の制限を確認してください。すぐに管理者権限を追加しないでください。
削除後も破損の警告が出る場合は、再ダウンロードしてインストール手順を確認してください。「アプリケーション」フォルダ全体を再帰的に変更したり、Gatekeeperをシステム全体で無効にしたりしないでください。

初回接続：システムプロキシとTUNの権限を切り分ける

通常のシステムプロキシモードとTUNモードでは、通信を取り込む方法が異なります。システムプロキシは、システムプロキシ設定に対応したアプリの通信をローカルのプロキシ入口へ向けます。TUNは仮想ネットワークインターフェースを使って対象の通信を取り込み、通常はより高い権限や補助コンポーネントが関係します。必要な許可はクライアントのビルドや実装によって異なり、インストールのたびに同じシステムダイアログが表示されるわけではありません。

確認する順序：まずシステムプロキシ、次にTUN

システムプロキシモード

まず、信頼できるサブスクリプションまたは既存の設定を読み込み、利用可能なサーバーを選んでコアを起動します。
v2rayNのシステムプロキシ操作で「システムプロキシを設定」を選び、ローカルの待ち受けアドレスとポートを確認します。
「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を開き、設定を確認します。
システムプロキシに従わないアプリは、引き続き直接接続する場合があります。個別に設定するか、適切な通信制御方法を選んでください。

TUNモード

まず通常のプロキシが動作することを確認し、ノードと仮想インターフェースを同時に調べるのは避けます。
使用中のクライアントの説明に従ってTUNを有効にし、管理者認証や補助コンポーネントのインストール要求を確認します。
VPN構成またはネットワーク拡張の要求が実際に表示された場合に限り、要求元を確認してから許可してください。
ほかの通信制御ソフトと競合する場合は、まずどちらか一方を停止してから再テストします。

実際に表示された要求に応じて許可してください。通常のローカルプロキシを使うために、ネットワーク、セキュリティ、ディスクのすべての権限を有効にする必要はありません。

「ローカルネットワーク」の権限一覧があるmacOSでは、「システム設定」→「プライバシーとセキュリティ」→「ローカルネットワーク」でアプリの許可状況を確認できます。この権限は主にLAN内のデバイスやサービスへのアクセスに関係し、すべてのインターネット接続を制御するスイッチではありません。LAN内のプロキシやDNSサービスを使う場合や、ほかのデバイスにプロキシを提供する場合に確認してください。

「システム設定」→「ネットワーク」→「ファイアウォール」は、主に受信接続を管理します。Mac上でプロキシを使うだけなら、送信接続のタイムアウトを解決するためにファイアウォールを無効にしないでください。LAN内のデバイスからMacのプロキシへ接続させる場合は、待ち受けアドレス、クライアントのLANアクセス設定、ファイアウォールルールをあわせて確認し、アクセス範囲を制限してください。

再インストールを繰り返さず、ポートとコマンドで確認

以下では、説明用のパラメーターとしてローカルSOCKS入口に 127.0.0.1:10808、リモートサーバーのポートに 443 を使用します。これらはすべての環境で共通する既定値ではありません。テスト前に現在の設定値へ置き換えてください。リモートポートはサーバー設定で決まり、ローカルポートはクライアントの待ち受け設定とシステムプロキシに合わせます。

127.0.0.1

LANには公開しないループバックアドレス

10808

この記事の例で使用するローカルSOCKSポート

443

リモート側のポート例。実際の値はノード設定に従う

# macOSの現在のプロキシ設定を確認
scutil --proxy

# 例のローカルポートでプロセスが待ち受けているか確認
lsof -nP -iTCP:10808 -sTCP:LISTEN

# ローカル入口へのTCP接続のみをテスト
nc -vz 127.0.0.1 10808

# SOCKS入口を明示してテスト用サイトへリクエスト
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

scutil --proxy に表示される有効状態、アドレス、ポートが、クライアントの実際の設定と一致している必要があります。HTTPプロキシとSOCKSプロキシは別の入口です。ポート番号が同じというだけで、設定が正しいとは判断できません。コマンドラインツールがGUIのシステムプロキシを自動的に使うとは限らないため、上のcurlではプロキシを明示しています。

待ち受けがない：クライアントのログに戻り、コアの起動失敗、ポートの競合、設定の解析エラーを確認します。この状態でシステムプロキシを何度も切り替えても意味はありません。
ローカル接続は成功するが、curlがタイムアウトする：サーバーアドレス、ポート、プロトコル、トランスポート設定を続けて確認してください。ローカルのTCP接続が成功しても、入口が存在することしか確認できません。
curlは応答するが、ブラウザーは失敗する：ブラウザー独自のプロキシ設定や拡張機能を確認し、ほかのプログラムがシステムプロキシ設定を上書きしていないか調べてください。
証明書エラーが出る：「システム設定」→「一般」→「日付と時刻」を確認し、ノードのサーバー名とTLS設定も確認してください。証明書検証を無効にして対処しないでください。

テストで使う socks5h は、接続先のドメイン名をプロキシ側で処理します。ただし、システム上のすべてのアプリでDNSが同じ経路を通ることを証明するものではありません。一部のアプリだけで問題が起きる場合は、テスト結果をシステム全体の結論とせず、そのアプリの接続方法を確認してください。

よくある質問：警告、ポート、終了後の設定

起動を許可したのに、コアがブロックされるのはなぜですか？

画面を表示するプログラムとコアは別の実行ファイルです。まずログや警告に表示されたファイルパスを読み、現在のアプリパッケージに含まれるファイルか確認してください。あわせて、正しいアーキテクチャの版をダウンロードしたか確認します。通常の信頼性チェックによるブロックなら、「プライバシーとセキュリティ」で該当する記録を確認してください。正体のわからないプログラムを一律に許可しないでください。

アップデート後にまた開発元を検証できないと表示されます。再度対処が必要ですか？

新たにダウンロードしたアプリには、隔離属性が再び付いている場合があります。アプリの識別情報や署名が変わることもあります。新しいパッケージの入手元とアプリの場所を確認し、「システム設定」の手順に沿って確認してください。以前許可した記録があるからといって、その後に入手したすべてのファイルを自動的に信頼してよいわけではありません。

ログに address already in use と表示される場合は？

上記のlsofコマンドで実際のポートを調べ、使用中のプロセスを特定してください。重複して起動したクライアントがあれば、まず通常の方法で終了します。v2rayNのパラメーター設定でローカルの待ち受けポートを変更し、保存してコアを再起動する方法もあります。その後、システムプロキシを設定し直し、古いポート設定が残らないようにしてください。

v2rayNを終了したあと、すべてのWebページが開けなくなるのはなぜですか？

システムプロキシが停止済みのローカル入口を参照したままになっている可能性があります。まずクライアントでシステムプロキシを解除してから終了してください。アプリを開けない場合は、「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を開き、今回設定したプロキシをオフにします。組織が一括設定したプロキシは、許可なく変更しないでください。

フルディスクアクセスの許可は必須ですか？

通常のインストール、サブスクリプションの読み込み、Mac上でのシステムプロキシの使用に、この権限は通常必要ありません。ファイルの書き込みに失敗する場合は、対象フォルダとファイルのアクセス権を確認してください。TUNを使う場合は、必要な管理者権限やネットワーク権限を個別に設定します。権限をまとめて有効にするより、具体的なエラーに応じて必要な権限だけを付与するほうが、原因を特定しやすくなります。

トラブルシューティングが終わったら、アプリのインストール先、使用中のプロキシモード、ローカル入口のポート、ログで最初に発生した有効なエラーを記録しておくと便利です。相談する際は、警告の文面と実施した手順を共有してください。サブスクリプションURL、ノードのパスワード、UUIDなどの認証情報は、必ず隠してから共有します。起動時の信頼性、コアの動作、通信の取り込みを段階的に確認するほうが、アプリを何度も削除するより効果的です。