Windows Server 2022にClash Verge Revを導入：遠隔デスクトップとグラフィカル環境で分ける手順

1. この記事が想定する「検索意図」と前提

検索で「Windows Server 2022」「Clash Verge Rev」「インストール」「遠隔デスクトップ」「图形界面／グラフィカル環境」といった語が一緒に並ぶ場合、多くは無番号のクライアントOS向け記事では足りないという判断まで来ています。具体的には、(1) サーバーエディションでデスクトップ体験が本当に有効か、(2) セッションがRDP越しでもGUIアプリが破綻しないか、(3) 購読URLを取り込んでプロファイルが生成されるか、(4) システム全体へプロキシ設定を及ぼすかどうか、までを一気通貫で確認したい意図です。本稿はそのサーバー特有の分岐に寄せ、ユーザー家中のPC向けの一般的な「Windowsでクリック」紹介に逃げません。

Clash Verge RevはMihomo系コアを同梱しがちなグラフィカル・フロントエンドの一つで、購読URLの取り込み、プロファイル切り替え、ルールモードの選択といった日常操作を視覚化します。一方で中身はあくまでローカルで動くプロキシ・ルータなので、サーバー上で常時稼働させること自体が業務ポリシーと両立するかは別問題です。まずは検証用／限定された管理バスットのマシンで手順を固める想定で読んでください。

2. 始める前に：Editionと「デスクトップ体験」

Windows Server 2022にはDesktop Experienceを含むフルGUI構成と、コマンド主体のServer Coreなど異なるインストール選択肢があります。Server CoreのみでGraphical Shellが利用できない場合、本記事で述べるClash Verge Revのような通常のWindows用GUIクライアントは対象外です。その場合はコアバイナリをWindowsサービスとして動かす、あるいは別ホストにGUIを置くといったアーキテクチャへ切り替えてください。

すでに「サーバーマネージャー」や「設定」アプリが開ける運用状態なら、GUIレイヤーは揃っています。もし役割だけ追加された最小構成で不安なら、Get-WindowsFeatureや「役割と機能の追加ウィザード」でグラフィカル管理ツール周りの不足が無いか確認すると安心です。ここでの論点は、単に「インストーラーを走らせる」ことより画面が描けるかです。Electron系・WebView2依存のUIは、ランタイム欠如だと真っ白なウィンドウで止まることがあります。

3. 遠隔デスクトップ（RDP）で操作する場合の心構え

クラウドやIDCのサーバーにコンソール接続せずRDPだけで触る運用は普通にあります。手順自体はクライアント版Windowsのリモートデスクトップと同型ですが、セキュリティグループやNSG、オンプレなら境界ファイアウォールでTCP 3389が塞がれていないか先に確認してください。公開インターネットに素通しさせるのは避け、社内VPNや踏み台ホスト越しに閉じるのが無難です。

マルチセッションやライセンスの話題は製品ライセンス条項に依存するため本記事では深追いしませんが、管理者セッションでの検証作業という位置づけなら、とにかく「GUIが描画されること」「クリップボード経由でURLを貼れること」の2点が実務上の最低ラインです。URLは機密になりがちなので、チャットではなくパスワードマネージャや短命の社内メモに載せ替える運用を推奨します。

4. WebView2ランタイムを先に入れる理由

Clash Verge Revのような近代的なWindowsフロントエンドは、内部でMicrosoft Edge WebView2を使って設定画面やログビューを描くことがよくあります。サーバー向けの金型イメージではブラウザ機能が削られており、WebView2が未導入のままだとインストール後に何も表示されない、という「壊れているように見える」状態に陥る例があります。公式のWebView2 Evergreenランタイムを先に入れてからクライアント本体へ進むと、無用な切り分け時間を減らせます。

5. Clash Verge Rev本体の入手と初回起動

Windows用ビルドは開発リリースの更新頻度が高いので、入手は常に公式配布元の最新リリースノートを起点にしてください。アーキテクチャは通常x64を選べば足ります。インストーラー版はスタートメニュー登録やアンインストール情報が明瞭、ポータブル版は特定フォルダへ解凍して持ち運べる一方、アップデート検知のされ方が異なる場合があります。サーバーではProgram Files配下へ入れると権限の壁に当たりやすいので、管理者昇格の要否を初回だけ確認するとよいです。

初回起動時にWindows Defender SmartScreenやSmart App Controlがブロックするケースがあります。オープンソースアプリはコード署名が無い・薄いことがあり得るため、公開されているハッシュやチェックサムをリリースページと照合し、ダウンロード経路が改ざんされていないことを確認したうえで許可するのが筋です。「とりあえず警告を黙って通す」だけでは後追いができません。

6. 購読のインポートとプロファイル生成

GUIの「プロファイル」「購読」「Subscription」などのラベルは版によって微妙に違いますが、やることは共通で、HTTPSで配られる購読URLを貼り付け、更新ボタンでプルします。失敗するときの典型は、(1) サーバーから購読ドメインへのTLSが中間機器で改ざんされている、(2) システム時刻が大きくずれていて署名検証に失敗する、(3) 企業プロキシが自前URL以外を遮断している、の三つです。切り分けはブラウザで同じURLを開けるかから始めると早いです。

インポートに成功するとノード一覧やプロキシグループが埋まります。ここで重要なのは、どのプロファイルを「現在有効」にするかを明示することです。複数購読を持っていると、古いプロファイルを見たまま疎通試験して時間を溶かしがちです。名称ルールを決め、検証用と本番用を混ぜない運用にしておくとサーバー作業でもミスが減ります。

7. 「システムプロキシ」「TUN」「ポート番号」の選び方（サーバー視点）

デスクトップ版Windowsでよく案内される「システムプロキシをオン」は、ユーザーセッションに影響を与える範囲が読みにくい環境では注意が必要です。サーバーで複数ユーザーがログインする場合、誰のレジストリ／プロファイルに書き込むのかがズレると、想定外のセッションだけ挙動が変になることがあります。当面は明示的にアプリだけが参照するローカルポート（mixed-portなど）を知り、ブラウザだけ手動プロキシで試すほうが切り分けが楽です。

TUNモードは仮想アダプタを経由してトラフィックを回収するため、クライアントOSでは万能に見えますが、サーバーではルーティングテーブルや既存のVPNスタックと衝突しやすいです。まずはTUNをオンにせず、ブラウザとcurl相当の検証で十分なケースがほとんどです。どうしてもTUNが必要なら、メンテナンスウィンドウを取り、ロールバック手順をメモしたうえで実施してください。

8. Windowsファイアウォールと受信ルールの考え方

サーバーでは「外向き接続は許されるが、あるポートへの着信だけ拒否」といったデフォルトの堅さがクライアントOSより強いです。Clash系はローカルループバックで待ち受けることが多いので通常は受信を広げなくてよい一方、LANへプロキシを公開する（allow-lan）構成にすると別の穴が開きます。業務で不要ならallow-lanは無効のまま維持し、必要なら限定サブネットだけに絞ったうえでWindows Defenderファイアウォールのスコープを調整してください。

9. 疎通確認の現実的な順番

成功の定義を曖昧にすると永遠に終わりません。おすすめの順は、(1) アプリ内でコアがエラーなく起動している、(2) 購読更新が完了しノード遅延が表示される、(3) ブラウザで意図した出口のIP確認サイトにヒットする、(4) 仕事で使う特定ドメインだけサンプリングする、です。サーバーではGUIブラウザが入っていない場合もあるので、Edgeの有無を最初に確認し、なければ一時的にポータブルブラウザを持ち込むか、Invoke-WebRequestでヘッダだけ見る方法に退避します。

DNSだけ別系統に流していると、ルールでDOMAINやDOMAIN-SUFFIXを細かく刻んでも、名前解決の時点で期待と違うアドレスへ行ってしまいます。サーバーでカスタムDNSを固定している場合は、そのキャッシュをClear-DnsClientCache相当の操作で一度空にしてから再試験すると、切り分けが早くなります。また、プロキシ非対応の古いネイティブツールを試す前に、まずはプロキシ設定を尊重するアプリケーションで勝ち筋を作ってください。

10. セキュリティと運用：本番で抱えないために

インストール手順が通ることと、サーバーとして常時その構成を維持してよいことは別問題です。購読URLは長期トークンを含みがちで、画面共有やスクリーンショットの一枚で漏えいします。RDP越しに作業するときは、URLをチャットに貼らず、使い捨ての安全な保管庫へ一回だけ置く、作業後にクリアする、といった作法が効きます。複数人が同じサーバーを触るなら、誰がどのプロファイルを有効化したのかをチケットに残すとロールバックが速いです。

監査の観点では、プロキシ経由の通信ログをどこまで残すか、保存期間と閲覧権限を決めておくと安心です。OSSクライアントでもログ出力の粒度は設定次第で変わるため、「とりあえずverbose」を本番で永続化しないよう、検証環境での試行錯誤と切り替えを分離してください。アップデートはセキュリティ修正の観点でも重要ですが、サーバー向けメンテナンス枠に合わせ、バージョン固定ポリシーがあるならテスト系で一回一周してから本番へ載せるのが安全です。

よくある質問

Server CoreだけでもClash Verge Revは動きますか？

GUIが存在しないServer Coreでは、本稿の手順は前提から外れます。同じブランド名のソフトウェアでも、サーバー向けはバイナリとサービス単位で組むのが筋で、Windows向けGUIでは代替になりません。まずハイパーバイザや別インスタンスにデスクトップ体験付きOSを用意するか、公式に推奨されるコア導入パスを選んでください。

ドメイン参加済みサーバーで注意すべき点は？

グループポリシーがプロキシやTLS検査を強制していると、GUIのトグルとEnterpriseポリシーが衝突します。試行はメンテ用OUへ移す、あるいはローカル管理者で一時的に上書きできる範囲を文書化する、のどちらかに寄せると混乱が減ります。作業が終わったら元のOUへ戻せるよう、変更記録を残してください。

Windows Defender SmartScreenが警告した場合は？

署名の有無は配布形態次第です。公式のチェックサムとファイルサイズ、ダウンロード元のHTTPS証明書を確認し、社内ルールで許容できる根拠を残してから実行してください。SmartScreenを恒久的に無効化するのは最後の手段にとどめます。

本番サーバーで常時プロキシを有効にしてよいですか？

可用性と責任分界の話になります。アプリ更新のたびに再起動要件が変わるクライアント型プロキシは、ミッションクリティカルなバッチ基盤に常駐させないという判断も合理的です。必要なら踏み台や検証VPCに閉じ、本番とはネットワーク分離されたところで購読を検証してから、本番へ持ち込むデータだけを絞り込む運用が安全です。

単一サーバーに「常時オン型のVPNアプリ」を入れて全トラフィックを一枚岩にしてしまう構成は、設定がブラックボックスになりがちで、切り分けも苦しくなります。一方でClash／Mihomo系はルールがテキストとして展開できるため、社内ドメインは直通しつつ、検証が必要な外向きだけ別経路に寄せる、といった折衷が現実的です。商用の閉じたクライアントにありがちな「画面のスイッチは見えるが中身が読めない」状態に比べ、障害時に観測できるレイヤが多いのが利点です。もしルール駆動のプロキシという考え方自体に共感できるなら、下の導線から各OS向けクライアントを一度揃え、自チームの運用に合う組み合わせを探ってみてください。