Clash for Windows 停止維護後轉移至 Clash Verge Rev：訂閱、規則與快捷設定搬遷指南

遷移範圍：分開處理用戶端設定與核心設定

Clash for Windows（以下簡稱 CFW）已停止維護。轉移至 Clash Verge Rev，不只是換個視窗：介面、設定管理方式和背景服務都會改變，負責解析訂閱、比對規則與建立連線的核心也需要重新確認。Clash Verge Rev 使用 mihomo，不能直接覆蓋 CFW 的整個使用者目錄，再期待所有設定都能原樣生效。

遷移前，先記下 CFW「General」顯示的版本、連接埠、執行模式，以及「Profiles」目前選取的設定檔名稱。若舊環境使用 CFW 0.20.39，這只是用戶端版本，不代表訂閱使用哪些通訊協定，也不代表所有欄位都與目前的 mihomo 相容。新用戶端與核心的實際版本，應分別從目前安裝的介面和啟動記錄確認。

步驟一：備份訂閱、規則與本機設定

保留原始來源，不要只存目前的節點清單

前往 CFW「Profiles」，記下目前使用的遠端訂閱網址。若選單提供複製 URL 或編輯功能，可從對應入口取得網址；若使用本機檔案，則複製該 YAML 檔案。訂閱連結通常包含存取權杖，請存放在本機受限目錄，不要上傳至公開儲存庫，也不要將含權杖的截圖貼到公開討論區。

使用者目錄通常位於 %USERPROFILE%\.config\clash，但可攜模式和自訂目錄可能不同。建議優先透過 CFW「General」中的「Home Directory」入口，確認實際目錄。結束用戶端後，複製整個目錄並保留原始檔名；遷移時只從副本取出所需資料，不要將該目錄設為新用戶端的資料目錄。

• 訂閱來源：保存遠端網址、更新頻率、設定檔名稱，以及是否依賴本機檔案。
• 規則修改：找出手動新增的 rules、rule-providers 和自訂策略群組。
• 預處理邏輯：備份 Parsers、腳本及其比對條件，並記下它們實際修改的內容。
• 本機設定：記下 HTTP、SOCKS 或混合連接埠、區域網路存取開關、代理繞過清單與 TUN 狀態。
• 介面狀態：記下規則模式、目前選取的策略群組、快捷鍵與開機啟動選項。

區分原始訂閱與最終執行設定

原始訂閱可能只有節點和策略群組，最終執行設定則還包含用戶端注入的連接埠、DNS、TUN 與腳本執行結果。只保存原始訂閱，自訂規則可能會遺失；只保存最終設定，則可能把舊電腦的路徑和連接埠帶進新環境。建議兩份都保存，並在檔名標明用途，比只留一張介面截圖可靠。

最終設定也可能包含代理密碼、控制介面金鑰等敏感資訊。備份應限制存取；分享排障資訊時，只摘錄相關欄位。不要為了讀取遠端訂閱，就把連結交給來路不明的訂閱轉換網站。

步驟二：匯入訂閱並確認 mihomo 設定相容性

1. 前往用戶端下載頁，選擇符合系統架構的 Clash Verge Rev 安裝檔。安裝完成後，先不要啟用系統代理與 TUN。
2. 在新用戶端的「訂閱」頁面匯入原始訂閱 URL，或透過本機檔案匯入功能加入 YAML。不同版本的按鈕名稱可能略有差異，請以畫面顯示為準。
3. 選取新設定檔，檢查設定驗證結果與核心記錄。先修正解析錯誤，再處理連線問題。
4. 在「代理」頁面確認策略群組和節點都已顯示，選取已知可用的節點，再啟用規則模式。

mihomo 能讀取許多 Clash 格式的設定，但「可以解析」不代表「行為完全相同」。舊訂閱中的通訊協定參數、規則集格式和用戶端專用擴充功能仍須檢查。尤其舊設定中的 script: 分流，不應視為 CFW Parsers 的 JavaScript，也不能假設會在 mihomo 上原樣執行；請依目前核心文件改寫為支援的規則或邏輯規則。

依錯誤位置修正，不要批次刪除未知欄位

• 找不到策略：檢查規則最後一項引用的策略群組是否存在，並確認名稱、空格與大小寫一致。
• 規則集載入失敗：檢查 rule-providers 的 URL、本機路徑、格式與 behavior；不要將規則集檔案當成完整訂閱匯入。
• 節點參數錯誤：確認通訊協定類型與必要欄位；有些服務供應商會分別提供 Clash 和 mihomo 訂閱，請選擇符合核心的版本。
• 檔案路徑失效：舊設定中的相對路徑會以新執行環境為基準解析，不能假設仍指向原本的目錄。

若要直接測試 YAML，可使用與用戶端相同版本的 mihomo 檢查設定。以下為 Windows PowerShell 範例，執行前請確認目前目錄已有該核心檔案和測試用設定；檢查通過只代表設定可載入，不代表遠端節點能連線。

.\mihomo.exe -t -f .\migration-test.yaml

步驟三：重建規則覆寫，避免訂閱更新後遺失

不要把需要長期維護的自訂規則直接寫進遠端訂閱快取，否則下次更新可能會覆蓋修改。請分開管理「遠端節點與策略群組」和「本機長期設定」：前者由訂閱更新，後者則透過 Clash Verge Rev 提供的合併設定或腳本機制處理，並確認已套用至目前的設定檔。

先遷移靜態規則，再處理腳本

CFW Parsers 描述的是用戶端端的預處理流程，不是通用核心設定。將包含比對條件和處理步驟的 Parsers 檔案直接貼進新用戶端的合併編輯器，通常不會得到相同結果。建議先列出每段邏輯的用途，例如「將某個網域設為直連」、「刪除過期節點」或「為策略群組新增篩選條件」，再透過靜態規則、合併設定或腳本逐項重建。

以下兩條是可用於本機覆寫的規則片段，不是完整訂閱。example.com 是文件範例網域，請依實際用途替換；此處使用內建策略 DIRECT，因此不依賴訂閱中的策略群組名稱。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

需要動態處理時，先確認腳本入口

若目前版本的腳本編輯器使用 main(config) 作為入口，可依下列形式將一條規則加在前面。若編輯器提供不同範本，請依照目前範本操作。腳本必須回傳設定物件；這段程式碼只能放在腳本編輯器中，不能當作 YAML 匯入。

function main(config) {
  const localRule = "DOMAIN-SUFFIX,example.com,DIRECT";
  const existingRules = Array.isArray(config.rules) ? config.rules : [];
  config.rules = [
    localRule,
    ...existingRules.filter((rule) => rule !== localRule)
  ];
  return config;
}

腳本會保留原有規則的相對順序，同時避免範例規則重複出現。實際使用時也應檢查前面是否有涵蓋範圍更廣的規則、是否依賴規則提供者，以及後續合併步驟是否會再次覆蓋結果。遷移時每次只啟用一項覆寫，查看最終設定後再繼續，排查問題會更容易。

步驟四：切換系統代理，重新設定連接埠與快捷選項

停止舊核心，再交由新用戶端接管

1. 在 CFW「General」中關閉「System Proxy」。若已啟用 TUN，也先將其關閉，再從系統匣結束 CFW。
2. 開啟工作管理員，確認舊核心程序已結束。若連接埠仍遭占用，先確認是哪個程序在使用，不要直接結束不明的系統程序。
3. 在 Clash Verge Rev「設定」中確認連接埠和系統代理選項。相關項目可能位於連接埠設定、系統設定或進階設定，實際分類會因版本而異。
4. 啟用新用戶端的系統代理，重新開啟測試用應用程式，並在「連線」頁面確認請求是否進入核心。

例如，舊軟體手動設定為連線至 127.0.0.1:7890，但新用戶端監聽的是 7897，該軟體不會因為切換系統代理而自動變更連接埠。可選擇讓新用戶端沿用舊連接埠，或逐一修改瀏覽器擴充功能、終端機環境變數和開發工具中的手動代理設定。此處的 7890 和 7897 僅為排查範例，不能據此判定任何版本的預設值。

netstat -ano | findstr ":7890"
netstat -ano | findstr ":7897"

輸出中狀態為 LISTENING 的行可用來尋找監聽程序，最後一欄是 PID。接著在工作管理員的「詳細資料」中確認該 PID。控制介面連接埠與代理連接埠用途不同，例如設定中的 external-controller 不能填入瀏覽器的 HTTP 代理欄位。

手動重建快捷鍵與啟動項目

• 開機啟動：確認新環境正常運作後，再關閉舊用戶端的自動啟動，避免登入後又由舊用戶端接管系統代理。
• 快捷鍵：重新設定顯示視窗、切換系統代理等動作，並確認不會與輸入法或其他應用程式衝突。
• 代理繞過：確認區域網路網域、回送位址及公司內網需求，不要未經檢查就整份複製舊清單。
• 區域網路共享：只有確實需要讓其他裝置連線時才啟用，並確認防火牆適用範圍；本機遷移不需要開啟區域網路存取。

步驟五：最後遷移 TUN 與 DNS，分層驗證連線

先確認系統代理正常，再啟用 TUN。系統代理仰賴應用程式遵循代理設定；TUN 則透過虛擬網卡與路由接管流量，涵蓋範圍不同。若同時變更核心、規則、DNS 和 TUN，出問題時便難以判斷故障來源。

在新用戶端的「設定」中安裝或啟用所需服務，依提示完成系統管理員授權，再開啟「TUN 模式」。不要複製舊用戶端的服務目錄或虛擬網卡檔案。遷移期間應避免另一套 VPN 或舊 TUN 服務同時接管預設路由。

DNS 設定要確認最終生效結果

若舊環境使用 fake-ip，先確認新執行設定中的 dns.enable、dns.enhanced-mode 與過濾清單。不要只因為在訂閱檔案中看到這些欄位，就認定用戶端最後會照原樣執行。介面設定、全域覆寫與訂閱都可能參與產生執行設定。

mihomo 的 TUN 設定中，dns-hijack 可用來接管符合條件的傳統 DNS 流量，但不代表會自動接管瀏覽器內建的加密 DNS。瀏覽器的「安全 DNS」、系統加密 DNS，以及其他 VPN 的解析行為也需要分別確認。修改後若仍取得舊的解析結果，可關閉相關應用程式再重試；Windows 的 ipconfig /flushdns 只會清除系統 DNS 快取，不會清除所有應用程式或核心的快取。

常見遷移故障與回復順序

訂閱匯入成功，但瀏覽器無法開啟網頁

先確認核心是否正在執行，再檢查系統代理指向的位址與連接埠。若「連線」頁面完全沒有請求，優先確認應用程式是否使用系統代理，以及手動代理是否仍指向舊連接埠，不要立刻更換節點。若已出現連線記錄，再依命中規則、策略群組選擇和錯誤記錄判斷出口問題。

節點測速有回應，實際瀏覽仍失敗

延遲測試只能表示指定測試目標當時有回應，無法證明所有網站、UDP 或 DNS 都正常。請分別測試一個應直連的目標和一個應走代理的目標，觀察兩筆請求套用的規則與出口。不要以單次延遲數值取代整體遷移驗收。

更新訂閱後規則消失

檢查修改是否寫入遠端設定快取，或覆寫是否只套用到另一個訂閱。重新確認合併順序，確保自訂規則沒有被後續陣列取代，也沒有排在 MATCH 之後。規則會由上而下比對，位置會直接影響結果。

暫時回復至 CFW 的操作順序

1. 在新用戶端關閉系統代理與 TUN，再結束新用戶端。
2. 確認新核心已停止，相關連接埠不再遭占用；不要讓兩個用戶端反覆爭用系統代理。
3. 啟動保留的舊環境，還原原本的設定與接管方式，並記錄新環境失敗的具體記錄。
4. 依據記錄修正新設定，再按相同步驟進行下一輪切換。

回復只是短期排查措施，並不代表舊用戶端已恢復維護。完成訂閱更新、規則命中、DNS、內網存取與重新啟動測試後，再移除舊啟動項目與背景服務。系統代理與 TUN 的基本設定可參閱使用指南；mihomo 欄位的意義則應對照協定手冊確認，不要僅憑介面名稱推斷核心行為。