Windows Server 2022 で Clash Verge Rev を導入：RDP（リモートデスクトップ）からの購読取り込みと Windows ファイアウォールの実測手順
「Windows Server 2022 のように画面が無い／常時 RDP だけ触る環境で、Clash Verge Rev を一度入れて 購読を取り込み、必要なら Windows ファイアウォール まで済ませたい」という検索意図向けの実測ガイドです。デスクトップ版 Windows と違い、役割と機能の入れ方、IE の強化セキュリティ、リモート管理との共存といった論点が前面に出ます。ここでは「サーバーにデスクトップ体験があり、リモートデスクトップで操作できる」前提で、入手から混在ポートの確認、受信規則の追加までを一続きで整理します。
想定環境：Windows Server 2022 と RDP の現実的な前提
本稿の対象は、Windows Server 2022 にデスクトップ機能（いわゆる GUI）があり、管理者が リモートデスクトップ（RDP） でログインして作業できる構成です。Server Core のみの最小構成では、Clash Verge Rev のような Win32 GUI クライアントは基本的に想定外なので、その場合は Linux や別ホストでの Mihomo 運用、あるいはサーバー向けのコマンドライン構成へ切り替える必要があります。まず自分のイメージが「サーバー OS だが操作感はデスクトップに近い」かどうかを確認してください。
すでにデスクトップ向けに書いた Windows 11 での Clash Verge Rev 初回設定 と並べると、インストール後のシステムプロキシと TUN の考え方は共通ですが、サーバーでは「役割と機能」、既定のセキュリティ強化、他サービスとのポート競合、運用ポリシー（アンチウイルスの例外申請など）がより厳しく効きます。用語の整理は チュートリアルページ を併読すると全体像が掴みやすくなります。
Clash Verge Rev をサーバーに置く意味と制約
Clash Verge Rev は Clash Meta（Mihomo）互換 コアを GUI で扱うクライアントです。サーバー上に置く典型例は、(1) そのマシン上のブラウザや更新プログラムだけをルール経由にしたい、(2) 同一サブネットの端末からサーバーのローカル混在ポートを参照したい、(3) CI やデータ連携の外向きを分流で安定させたい、などです。逆に「全クライアントのデフォルトゲートウェイをサーバーに集める」ような構成は、ルーティングと NAT の設計が別レイヤになり、本稿のスコープを超えます。
名称に Rev が付く派生や、配布チャネルが複数ある点はデスクトップ版と同じです。必ず 配布元の信頼性と更新履歴 を確認してから導入してください。パッケージの入口は 公式ダウンロードの整理ページ を第一参照にすると、記事のバージョン感と突き合わせやすくなります。古い Clash for Windows から移る場合は CFW からの移行ガイド も併読ください。
ステップ1：インストール前のサーバー側チェック
RDP でログインしたあと、次を軽く確認しておくと後戻りが減ります。
- 空き容量と権限：ユーザーがソフトウェアを導入できるか。ドメイン参加マシンでは GPO で制限されていることがあります。
- 他の VPN やフィルタ製品：TUN や WFP フィルタが既に動いていると、仮想アダプタ操作が衝突しやすいです。
- ウィルス対策の隔離設定：
mihomo実行ファイルや Verge 本体のパスが隔離対象になっていないか。 - リモートデスクトップ自体のポート：既定の TCP 3389 を変えている場合でも、この記事の手順とは独立に管理されているはずですが、ファイアウォール変更の際に誤って塞がないよう注意します。
ステップ2：Clash Verge Rev のインストール（RDP セッション内）
一般に .exe インストーラー または ポータブル展開 形式で配布されます。初回実行時に SmartScreen が止める場合は、発行元署名と配布ページを確認したうえで進めるか判断します。サーバーでは「管理者として実行」を求められる場面がデスクトップより多く、特に TUN モード を有効化する前後で UAC が再び出る設計のビルドもあります。
起動直後に Mihomo コア のダウンロードや配置を求められる場合は、画面の案内に従います。ここで失敗すると「アプリは立ち上がるが通信が始まらない」状態になりやすいので、プロキシ環境下であればシステムプロキシを一時的に経由できるか、オフライン配布のコアを手動配置できるかも併せて確認してください。ファイアウォールの許可ダイアログが出たら、方針に沿って許可します。ローカルからの接続だけで運用するなら過剰な広い許可範囲は避け、必要最小限に留めるのがよいでしょう。
ステップ3：購読（サブスクリプション）URL の取り込み
プロバイダから受け取った 購読 URL を、Verge のプロファイル／サブスクリプション欄に登録し、手動更新 か定期更新で YAML を取り込みます。User-Agent や更新間隔は業者側の案内に合わせるのが安全です。期限切れ、認証エラー、リダイレクト失敗などは 購読 URL の FAQ に典型パターンをまとめています。
サーバーではブラウザが疎いことがあり、インターネット強化セキュリティ構成（IE ESC） が有効だと購読公開ページの閲覧が面倒になる場合があります。その場合は管理端末で URL をメモして RDP 先に貼り付ける、あるいはポリシーに従い一時的に緩和する、といった運用が現実的です。HTTPS で配布される購読でも、中身はプレーンテキストに近い取り扱いになることが多いので、取り回しには十分注意してください。
複数プロファイルを切り替えるなら、「いまアクティブなのがどれか」を常に画面で確認できる状態にしておくと、あとからの切り分けが楽です。Linux サーバーでの同系 GUI の流れは Debian 12 の Clash Verge 記事 と対照すると、購読までは同じですが Windows では systemd ではなくスタートアップやタスクスケジューラ側の話になります。
ステップ4：システムプロキシと TUN（サーバーでの選び方）
大枠はデスクトップと同じく、(A) システムプロキシ で HTTP／SOCKS のローカルポートにアプリを載せる、(B) TUN で仮想インターフェース側にトラフィックを流す、の二系統です。TUN の仕組み自体は TUN モードの深掘り を参照してください。
サーバーでも まずはシステムプロキシのみ でブラウザや curl 相当の疎通を確認し、問題がなければ TUN を検討するのが切り分けに有利です。TUN は仮想アダプタの作成とルート操作を伴うため、他の VPN 製品やセキュリティスタックと競合しやすく、RDP セッションごとの挙動差も出やすい点に注意します。管理者権限で再起動を求められたら、トレイメニューや設定画面の案内に従ってください。
ルールや proxy-groups が意図しない DIRECT に落ちていると「プロキシは有効だが特定ドメインだけ失敗」が起きます。グループの考え方は proxy-groups 解説 で押さえておくとよいです。
ステップ5：Windows ファイアウォールでの放通（実測の考え方）
既定では 外向きの確立済みセッションからの戻り は通りやすく、ローカルループバック上の混在ポートへの接続も同一マシン内ならそのまま試せることが多いです。障壁になりやすいのは、(1) セキュリティソフトが独自のファイアウォールを持っている、(2) LAN 上の別端末からサーバーの混在ポートへ入れたい、(3) 受信規則が厳格なドメイン GPO になっている、のパターンです。
手順のイメージは、「Windows Defender ファイアウォール（略してもよいがここでは正式名称）の詳細設定」で 受信の規則 を新規作成し、TCP の特定ポート（混在ポート。テンプレや画面に表示される番号に合わせる）を許可し、スコープを必要ならサブネットや単一 IP に絞る、という流れです。GUI の細部はビルドで異なるため、ここでは番号の読み取り方と「外向きではなく受信を開けるのは誰向けか」を意識しておいてください。
同一マシンからの参照ではなく、スマホや別 PC からサーバーのローカルポートを直接使う構成なら、allow-lan 相当の設定とセットで整理するのが一般的です。詳細は Windows 11 の LAN 許可とファイアウォール が近い論点なので流用しやすいです。仮想化ホストと NAT を絡める場合は Hyper-V と Clash の NAT／ファイアウォール も参照ください。
ステップ6：疎通確認の順番（ログで時間を無駄にしない）
次の順で見ると、典型的な詰まりを早く切り分けられます。
- 購読更新が成功しているか：HTTP ステータスやエラーメッセージをそのまま記録する。
- ローカルで混在ポートに届くか：ループバックやツールでポート開放を確認する。
- システムプロキシ／TUN のどちらが有効か：二重有効による混乱を避ける。
- ルールと DNS：名前解決が先に落ちていないか。
dns周りはプロファイルの推奨に寄せる。 - 他製品との競合：別 VPN を終了して比較する。
サーバーは一度設定すると触らなくなる一方、自動更新に依存するため、しばらく後に「購読だけ切れた」ケースが起きやすいです。連絡用のチャネルを別経路に残しておくと復旧が早くなります。
RDP 環境特有の勘どころ
リモートデスクトップで動かす GUI は、基本的に対話ユーザーのセッション上で動きます。常駐はタスクトレイに収まることが多いですが、サーバーをログオフ専用にするとプロセスが止まる設計もあるため、運用ポリシーに合わせて「セッションを維持するか」「タスクで起動するか」を決めます。マルチユーザーで同時 RDP を許可している場合、ポートの取り合いは稀ではありますが、混在ポートをユーザー別に変えていないかは設定画面で確認してください。
また、クラウド業者のイメージでは初期状態で外向きが制限されている例もあります。それは Windows のファイアウォール以前の問題なので、セキュリティグループやプロバイダーコンソール側の outbound を先に確認してください。
よくある質問
Server Core 向けの同手順はありますか
GUI クライアントの手順ではなく、コアバイナリと設定ファイルをサービス化する別構成になります。本稿の対象外です。
購読ページをサーバー内ブラウザで開けない
強化されたセキュリティ設定やアプリ制御が原因のことがあります。管理端末から URL を RDP に持ち込む方法が現実的です。
TUN をオンにすると不安定になる
仮想アダプタやルート操作の失敗、他 VPN との競合を疑い、一度オフへ戻してシステムプロキシのみで再検証します。
まとめ
Windows Server 2022 に Clash Verge Rev を置く流れは、大枠では「入手と権限の確認 → インストールとコア配置 → 購読でプロファイルを用意 → プロキシモードを状況に合わせる → 必要なら受信規則でピンポイントに開ける → ログで順に詰める」に収束します。デスクトップ版の入門記事と骨格は同じでも、サーバーではファイアウォールとポリシー、リモート運用の制約が前面に出る点が決定的に異なります。
全般的なクライアント分布は 2026 年時点の Clash エコシステム で俯瞰できます。安定したパッケージ入口は引き続き ダウンロードページ を第一にすると、ビルド差分の追いかけが楽になります。
従来、サーバー上でプロキシや分流を組むには設定ファイルとタスク起動を手で繋ぐ必要があり、ログの見方もバラバラでした。GUI ではない軽量ツールは確かに導入は早い一方、ルールの可視化や購読更新、システムプロキシと TUN の切り替えまで含めた体験では Clash 系のクライアント の方が試行錯誤のコストを抑えやすい場面が多いです。サーバーでもデスクトップでも、分流と DNS の関係は同じ土台の上に乗ります。まずローカルで一度通してから本番に載せ替えたい方は、手元の環境でパッケージを試すために Clash の入手ページ から入手し、ルールの感触を確認してみてください。