Clash Verge Rev：Windows サービスの安全性チェック失敗

Windowsで「サービスのコアが安全チェックを通らず、通常モード（Sidecar）に切り替えた」と表示されたときの実行ユーザーを記録してください。Clash Verge Revは現在のユーザーでコアを起動するため、接続は使えてもシステムサービスの高権限は得られません。一般ユーザーのSidecarではTUNを使えません。

サービスはシステム権限でコアを起動するため、プロジェクトはコアのファイル、インストール先、親ディレクトリの所有者とアクセス権限を確認します。通常のアカウントがこれらのファイルやディレクトリを差し替えられるなら、サービスはその高権限での起動を拒否する必要があります。

プロジェクトの issue #8073 には、Windows 11 の v2.5.5 と v2.5.6 での事例が記録されています。通常ユーザーが TUN を有効にすると拒否され、元のエラーは C ドライブのルートを指しました。一方、管理者として起動すると TUN を有効にできました。これは一件の報告であり、すべての Windows 環境で原因が同じとは言えません。

エラーが C ドライブのルートの DELETE 権限だけを示している場合は、後述の v2.5.7 の手順に進みます。別のパス、所有者、ACL の読み取り失敗がある場合は、該当するファイルとディレクトリを調べる必要があります。

公式の Windows FAQ によると、ポップアップには簡略化された説明しか表示されません。まずアプリ内で通知を右クリックし、元のエラーをコピーしてメモ帳に貼り付けます。「Sidecar」という表示だけで、サービスの未インストール、設定エラー、C ドライブ全体の権限問題のいずれかを決めつけないでください。

エラー中の core path、ファイル名、その後に続く理由を確認します。二つのコアファイルがともに拒否されても、同じ親ディレクトリに問題があるだけかもしれません。まずパスを記録し、すぐに ACL を変更しないでください。

core path が C ドライブのルートを指していても、アプリが C ドライブ直下にインストールされているという意味ではありません。#8073 では既定の Program Files にインストールした状態でも、そのパスが示されています。

クライアントの実際のバージョン、インストール先、現在の実行ユーザー、サービスモードの状態、最初の拒否ログを保存します。ログや設定にはサブスクリプションの認証情報やローカルユーザー名が含まれる場合があります。公開前に機密情報を伏せたコピーを作成してください。

TUN を無効にして Windows の通常の通信を確認します。Sidecar のシステムプロキシで実際のウェブページが開き、接続記録にもそのリクエストが出るなら、一時的に使えます。拒否されたパスを確認する前に、サービスのインストールを繰り返さないでください。

一時的に TUN がどうしても必要な場合、プロジェクトの FAQ は管理者として起動する方法を案内しています。トレイからアプリを完全に終了し、ショートカットまたは clash-verge.exe を右クリックして「管理者として実行」を選びます。サービスの修復を求められたら「Sidecar の使用を続ける」を選び、必要なときだけ TUN を有効にします。

管理者としての起動は一時的な利用方法であり、サービスやディレクトリの権限は修復しません。以後もこの方法を使うたびに管理者として起動する必要があります。TUN が不要になったら、通常ユーザーと動作確認済みのシステムプロキシに戻してください。

元のエラーがデスクトップ、ダウンロード、ユーザーディレクトリ、または手動で展開した場所を指す場合、先に「設定 → Verge 詳細設定 → 設定のバックアップ」で設定を保存し、トレイからアプリを完全に終了します。その後、プロジェクトの公式インストーラーで既定の C:\Program Files\Clash Verge にインストールしてください。

古いディレクトリの独自の権限を新しいインストール先に引き継がないでください。通常ユーザーに「変更」や「フル コントロール」も追加しません。新しい場所でも拒否される場合、エラーがコアファイル、インストール先、それより上位のディレクトリのどれを指すかを先に確認します。

既定の場所にインストール済みなら、公式 FAQ に従い、エクスプローラーでエラーが示すパスの「プロパティ → セキュリティ → 詳細設定」を開いて所有者と権限の項目を確認します。コアファイルと関連ディレクトリの所有者は SYSTEM、Administrators、TrustedInstaller のいずれかである必要があります。通常アカウントには、コアの変更、ディレクトリの差し替え、権限の変更を許可しないでください。

権限が親ディレクトリから継承されている場合や組織管理の端末では、システム管理者に元のポリシーに沿った修復を依頼します。安全性チェックを通すために権限を広げてはいけません。パスの安全性を確認できたら、「設定 → サービスモード」でサービスを再インストールします。必要に応じて古いサービスを先にアンインストールし、ホーム画面の状態を確認してください。

元のエラーで core path が C ドライブのルートを指し、dangerous=0x00010000 だけが表示される場合、公式 FAQ はボリュームのルートにある「削除」権限の特例として扱っています。まず C ドライブのルート権限を変更しないでください。

サービスのリポジトリのコミット e8f5279 では、ボリュームのルートは通常のフォルダーのように削除または名前変更できないため、ルートに限ってこの DELETE 権限を無視するようチェックを変更しました。ほかの危険な書き込み権限のチェックは維持されています。

v2.5.7 の正式版リリースノートには、Windows のシステムドライブのルートに対する「削除」権限の誤判定でサービスモードと TUN が使用できない問題の修正が明記されています。#8073 が記録しているのは v2.5.5 と v2.5.6 の障害です。このことから v2.5.7 がすべてのディレクトリ権限や所有者の問題に効くとは言えません。

エラーがボリュームのルートに対する DELETE 権限だけを指している場合は、設定をバックアップしてアプリを完全終了し、プロジェクトの公式 v2.5.7 Release から OS とアーキテクチャに合う正式なインストーラーを入手します。更新後、「設定 → サービスモード」でサービスを一度再インストールし、新しい元のエラーをコピーして、通常ユーザーで TUN を確認してください。まだ拒否される場合は再インストールを繰り返したり、ドライブ全体の権限を変更したりせず、前述の通信方法を使いながら新しいエラーを調べてください。

新しいエラーにほかの危険な権限、所有者の問題、または ACL を読み取れない状態が示された場合、「DELETE だけ」という対処は適用できません。管理者に新しいエラーが示す具体的なパスを確認してもらい、通常の読み取り権限やルートにフォルダーを作成する正当な権限まで削除しないでください。

復旧の確認は、もともと失敗していた通常ユーザーの権限で行う必要があります。管理者として起動したアプリを完全に終了してから通常ユーザーで起動し、ホーム画面に「サービスモード」と表示され、コアの安全性チェックによる拒否が再表示されないことを確認します。管理者のウィンドウだけで TUN を使えても復旧とは言えません。

続けて、元の Profile とノードで TUN を有効にし、同じ実際の HTTPS サイトへアクセスします。接続履歴とログでリクエストがコアに入っていることを確認した後、TUN を無効にして通常のネットワークがすぐに戻ることも確かめます。

最後にアプリを完全に終了して再起動し、一般ユーザー、サービスモード、TUN、Webリクエストの確認を繰り返します。再起動後にSidecarへ戻る場合は、再起動後も問題が続いています。新たなエラーメッセージを原文のまま保存して調査を続けてください。

更新またはサービスの再インストール後も拒否される場合は、まず TUN を無効にし、アプリを完全に終了して、変更前に使えていたシステムプロキシか Windows の直接接続に戻します。インストール先の変更で Profile が見えなくなったら、事前のバックアップから設定を復元してください。警告を消すためにコアファイルの書き込み権限を広げてはいけません。

古いサービスに戻すことを標準の解決策にはできません。現在の資料では、古い版がこの拒否を解消する証拠がありません。一時的に TUN が必要な場合はプロジェクトの FAQ にある管理者起動だけを使い、TUN が不要なら通常ユーザーと検証済みの通信方法を維持してください。

プロジェクトの issue に報告する際は、クライアントのバージョン、インストール先、通常ユーザーと管理者での比較、元の core path と dangerous フィールド、サービス再インストール後の新しい通知、実際のリクエストの結果を添えます。サブスクリプションの token、ノードのパスワード、個人情報を含むパスなどは事前に削除してください。

新しいエラーが is owned by、権限の読み取り失敗、別の書き込み ACE に変わった場合は、その具体的なパスを調べます。ボリュームルートの DELETE への対処を流用しないでください。通常ユーザーでの新しいエラーと実際のリクエスト結果から復旧を判断します。