Windows Server 2022 安裝 Clash Verge Rev：遠端工作階段下訂閱匯入與防火牆放行分步實測（2026）
若你手上的機器是 VPS／實體伺服器／虛擬化虛機，常見卡住點並不是「不會設定節點」，而是資料中心環境：沒鍵鼠、沒控制台瀏覽器、甚至只允許你先透過遠端桌面協定（RDP）登入。Clash Verge Rev 是圖形化客戶端，適合具桌面體驗（Desktop Experience）的 Windows Server 2022；底層多為 Mihomo／Clash Meta 核心。Clash 使用教學 裡許多規則觀念在伺服器上完全通用，但若你的 SKU 根本沒桌面，本篇流程就不適合硬套。Windows 11 上的 Verge Rev 首次安裝文 已細講系統 Proxy 與 TUN；這裡則對齊「第一次登入的只有 RDP」、又想在伺服器環境一次性把Windows 防火牆與對外放行設對的使用者：RDP 前置條件、安裝、訂閱匯入、輸入規則（Inbound）、以及無人值守時容易踩坑的並存問題。
這一篇寫給「誰」？先看清 Windows Server SKU 這條邊界
先講直白些：Clash Verge Rev 需要圖形化桌面工作階段；因此本文預設你安裝或具備伺服器角色的「含桌面」映像／功能，並能以RDP（遠端桌面）登入某位使用者的互動桌面。若你目前是Windows Server Core等非完整 GUI 發行組態，請不要硬裝 Electron 類桌面客戶端當退路——那通常徒增不相容維護成本。請改走「純核心二進位＋YAML」或基礎結構自動化發佈通路（例如對應的服務程式、容器或你熟悉的工作排程管線）；本文仍會在後段提醒「同一台機若是 Core，精神相同但換工具」。另外，許多資料中心對虛擬私人網路／透明轉發有合規規定；請先確認你可以在該環境運行規則型代理並遵守提供者條款，本文只描述通用的技術對齊與網路邊界定義。
第一步：準備 RDP——剪貼簿、解析度與管理員身分
實務上你會先從筆電或辦公分機連進伺服器的會話工作階段。為了避免「看得到訂閱頁但在遠端裡無法順利複製／貼上」這種低級但超花時間的卡關，請在來源電腦的遠端用戶端裡確認剪貼簿轉送已啟用，並先手動將訂閱網址存成伺服器上的小檔或開本機備忘再貼。若你只允許純文字的連線環境（例如跳板機限制），可把訂閱拆成數段對照確認，避免因長字串換行或被截斷而讓伺服器對上游回傳403、404或看似「更新了但列表空白」的假成功。
安裝階段多數環境會需要系統管理者權限（Administrator）；若你是在受限帳號下試圖msiexec或寫檔進Program Files，常見徵兆是ACCESS DENIED或 Defender 對安裝目錄的即時監控告警。對於第一次在該環境落地的 Verge／Mihomo 版本，請以可驗簽或可稽核的官方／開源發布頁來源（含校驗與發行說明）為前提，再配合本站下載頁取得一致入口。先前 Windows 11 的同系列教學已說過 SmartScreen 與 Defender 對未廣簽套件的態度：它不必然代表程式有問題，但一定代表你得先信任來源再上「仍要執行」這一步。
第二步：伺服器側執行緒環境——瀏覽器、時間與驅動層的注意點
Windows Server並不是為了電競與影音消費而預載大量套件；許多環境會關不必要角色，或對 IE／舊相容元件有更嚴謹鎖定。Verge Rev 類客戶端常依賴接近現代的 Web 殼資源載入。若安裝完成後一片空白或反覆崩潰，請先對齊對應的 WebView／Chromium Runtime 相容性資訊並升級伺服器可用的累積更新，而不要第一時間懷疑訂閱壞掉。接下來三件小事對伺服器級診斷異常有用：①系統時間與時區。時間錯會讓 HTTPS 握手與 TLS 鏈結驗證直接失敗。②NTP／DC 對時是否被群組原則干擾。③資料中心對外是否要經過出站 Proxy；若你只允許出站走企業 PAC，請先對齊出站策略，再在 Clash 內處理第二層轉發，否則訂閱更新連線可能被第一層就擋下。
若你希望後續讓其他虛擬機或區網裝置共用這台伺服器上的 Clash 埠，可先閱讀Hyper-V／NAT／防火牆與宿主 Clash 對齊文，它與本篇後段談輸入（Inbound）規則的防火牆語意完全一致，只是把來源 IP 區段語境換成對應的「誰來連伺服器這個埠」。
第三步：於 RDP 內新增訂閱、選定設定檔、啟動核心
登入伺服器使用者桌面後的流程，與你在家用 Windows形式上很像：選擇「新增／匯入訂閱」、貼上上游給你的 HTTPS 連結、命名、儲存、執行立即更新／重新整理訂閱。伺服器側差異往往在「你看得到節點，但對外請求並沒離開機房」**：例如 DNS 在機房側被劫持到內網過濾、或你只允許白名單目的地位址。請把更新失敗的訊息文字完整保存；若控制台顯示握手逾時優先對齊出站路徑，若顯示憑證錯誤請回到時間／根憑證／攔截式安全設備的情境。
訂閱成功並看到節點後，記得確認「目前使用中」那一段設定檔真的已被套用，而不是更新了訂閱但核心仍載入上一份空殼。Mihomo的日誌若顯示已監聽本機mixed-port，請紀錄這個數字並作為接下來輸入規則放行與終端級測試的基準。訂閱連結那些事裡對「連結換發、過期輪替、限速」在伺服器上更棘手：你一週不重登控制台，很容易就默默回到舊狀態，所以自動更新間隔請依你的上游政策來設合理的數值，並避免把大量節點健康檢查打到同一提供者節奏而觸發429。
第四步：為什麼一定要談輸入（Inbound）規則？什麼時候根本不需要？
若你只希望伺服器本機上的瀏覽器／服務對外連線經過 Clash，多數環境對出站（Outbound）預設就足夠，甚至不必新增任何 Inbound：重點是本機程式能透過系統 Proxy，或由 TUN／WFP 把流量送進 Clash 核心。
然而一旦你要對區域網路或管理網段分享 mixed-port／HTTP／SOCKS，或讓來賓虛機把代理指回宿主（見Hyper-V 文與手機 Wi‑Fi 區網與電腦 Clash的比較），就必須同時對齊兩件事情：①allow-lan類語意是否真的打開，並且監聽不只綁在127.0.0.1。②Windows Defender Firewall的Inbound Rules允許對應TCP LocalPort或指定主程式。許多人第一個晚上就卡在「iptables 假想症」而其實是 WinFW 對 Private／Public Profile 沒對上：請在「進階安全性」視圖確認該規則套用在哪個設定檔。
以程式或連接埠建立規則（範例僅為示意）
下列 PowerShell 請以管理者身分執行，並把7890與規則顯示名稱替換為你實際的 mixed／HTTP／SOCKS 監聽；若你是雲端主機並且在供應商控制台另有 Security Group／NSG，請那不是 Windows 規則能取代的 Layer，兩者要一起放行。
New-NetFirewallRule -DisplayName "Clash Verge Mihomo Mixed TCP Example" `
-Direction Inbound -Action Allow -Protocol TCP `
-LocalPort 7890 -Profile Domain,Private若你對來源 IP有把握，應善用-RemoteAddress將範圍收窄到管理區段或對應的 Hyper-V／資料中心區網前綴。不要為了省事把該公開埠對Any全開並放在 Public Profile——那是把資料中心資甊當成公共 HTTP 跳板的高風險模式。若你是在家用實驗環境並仍遇到「手機能上，虛機不能」的情境，請回頭核對 VLAN／訪客隔離與是否誤將伺服器卡在對外來源視角的「Public」這個語意標籤上。
第五步：伺服器側先試系統 Proxy，再評估TUN是否要開
在桌面版 Windows 上，我們常說「先系統代理把路走通，再談 TUN」。在Windows Server上這句話依然成立，而且風險通常更高：因為你可能同時依賴 RDP、管理代理、檔案共享、角色服務；而TUN會改寫路由與虛擬介面，若驅動被安全政策擋、或與其他隧道路由衝突，表現就是整機好像「還活著但路由全亂」，而遠端桌面也可能瞬斷。因此建議策略是：①先在 Verge 內啟用系統 Proxy並用 Edge／Chromium 開一個已知可驗證的外部頁面。②再開啟需要不吃系統 Proxy 的應用時，才評估是否切到TUN或維持混合模式。若你完全不懂如何從 IPMI／Serial 救回路由，就不要在生產機上第一次就嘗試激進的 TUN 覆寫。
更細的透明模式與流量可見度，仍可延伸閱讀Clash TUN 模式深度解析；重點是心智模型先對齊：你在伺服器上做的不是「點外掛就全家飛」，而是用規則語意承接應用程式的實際連線行為，而Server 的應用程式往往比家用桌機更「不鳥系統 Proxy」。
第六步：除錯請照固定順序縮圈，不要同時改三個地方
建議把下面流程當 checklist 用，不要跳步：
- 訂閱與節點本體：延遲測試或健康檢查是否真代表你當下出口；若節點全紅，先疑訂閱／帳戶／上游政策。
- 模式與應用是否匹配：只有瀏覽器異常→看瀏覽器外掛與系統 Proxy 是否被覆寫；只有某服務異常→它是否不吃 Proxy，需 TUN 或程式層設定。
- DNS 與 fake-ip：表現常是「慢、部分網域永遠失敗」；請在日誌比對解析階段與命中規則。
- 防火牆雙層：WinFW 與雲端 Security Group／公司邊界設備；ICMP 與 TCP 埠不是同一件事。
- 並存 VPN／SD-WAN：兩套路由搶表時，先關其中一個做單變因對照。
若你的目標是「讓其他裝置走這台伺服器上的 Clash」，除本文外也要同時讀Wi‑Fi 區網共用 Clash裡關於allow-lan與手機端代理欄位怎麼填，因為心智模型幾乎逐行可對照，只差在「誰是伺服器、誰是客戶端」。
安全、稽核與維運文化：為什麼伺服器版要寫得更「囉嗦」
家用桌機上誤開allow-lan頂多讓室友的裝置意外連進來；在資料中心上則可能是整個管理網段都能把你的 mixed-port 當出口，甚至引發帳務／合規／誤用濫用等連鎖問題。請把「分享代理埠」視為等同於額外開一個對內服務埠：需要變更紀錄、最小權限、定期檢視規則與日誌保存策略。若你只是短暫除錯，請在 tickets 結案前主動刪除臨時輸入規則並關閉不必要的 LAN 開放。
本文僅整理技術路徑與常見工程取捨，不提供繞過法律、供應商政策或侵害他人權益的指引；在你的司法管轄區與租賃合約下，代理行為可能受到額外限制，請自行確認。
常見問題
為什麼很多人說「Server Core」幾乎不能直接照這一篇做？
因為 Core 刻意拿掉完整 GUI 與大量桌面應用情境；Clash Verge Rev 仰賴互動式桌面殼。若堅持在 Core 上硬撐圖形化客戶端，通常成本遠高於改用純核心二進位、容器或你原本就在用的組態管理管線。
RDP 下訂閱貼連結最常卡在哪一步？
多半與剪貼簿轉送、被截斷的長字串、或多重代理層讓訂閱網域在機房出口被擋有關。請先把 URL 落成本機純文字檔比對，再檢查 HTTPS 憑證與時間是否正確。
我明明已放行防火牆，為什麼其它機器連不到伺服器上的 Proxy 埠？
依序檢查：Clash 是否只綁 127.0.0.1、allow-lan 類選項、WinFW 規則是否命中正確 Profile、雲端 NSG、以及路由器是否啟用 AP 隔離。Ping 與 TCP 連線是不同規則，不要用 ping 否定一切。
相較於「只給一個安裝檔、其餘全部丟給你自己猜」的傳統代理軟體，Clash 生態在規則表達、節點群組與透明模式之間的可預期性通常更好：你可以用同一套 YAML 思維在桌機、伺服器與行動裝置之間遷移，而不是每換平台就重新發明一次維運腳本。伺服器場景特別吃可觀測性——哪條規則命中、哪個 DNS 被攔、哪個埠其實沒開，這些透過核心日誌往往比純 GUI 黑箱更容易收斂。若你正在規劃一台需要長期穩定跑分流的工作負載主機，建議先從官方整理的下載入口取得對應平台版本，再回頭把訂閱、防火牆層級與應用連線行為一次對齊；很多人會在試過幾套封閉工具後回到 Clash，原因很務實——規則與自動化終究要能在文字與資料中心流程裡站得住腳。