Clash for Windows 停止維護後如何遷移：訂閱、覆寫腳本與常用設定搬遷指南

先釐清需要遷移的四類內容

Clash for Windows（以下簡稱 CFW）停止維護後，遷移重點不是把舊程式資料夾整份複製到新客戶端，而是分別處理訂閱來源、設定加工邏輯、代理設定與 Windows 整合。本文以遷移至 Clash Verge Rev 為主軸。其他採用 mihomo 核心的客戶端也可依照相同順序檢查，但選單名稱、腳本入口與資料目錄不能直接照搬。

客戶端與核心是兩個不同層次的軟體。介面負責下載訂閱、開機啟動與切換系統代理；mihomo 核心則負責讀取最終設定、監聽連接埠並執行分流。舊客戶端的介面設定檔，不等於新核心可直接讀取的 YAML 檔案。

如何挑選替代客戶端

• 想保留桌面版訂閱管理與覆寫工作流程：可優先考慮 Clash Verge Rev，並確認目前版本的腳本、合併設定與服務模式說明。
• 更重視不同裝置上的操作一致性：可比較 FlClash 等客戶端，但別預設其覆寫腳本與 CFW Parsers 相容。
• 只需要一般訂閱與規則模式：先從匯入訂閱、選擇策略組與設定系統代理開始，不必為了遷移而立刻啟用 TUN。

各客戶端的下載入口請見客戶端比較。安裝前先確認 Windows 架構與版本說明，安裝後在「關於」頁面記下客戶端版本與核心版本。遇到問題時，提供這兩項資訊會比只寫「最新版」更有幫助。

備份舊設定，保留可還原的連線方式

先確認 CFW 仍可正常使用，再進行備份。一般安裝方式的資料位於使用者目錄下的 .config/clash，但可攜式模式或自訂啟動參數可能會改變路徑。請從舊客戶端的設定目錄入口確認實際資料夾，不要只依照網路上的路徑自行搜尋。

1. 保存原始訂閱網址，並記下訂閱名稱、更新時間與更新間隔。網址通常包含存取憑證，請只保存在可信任的本機位置。
2. 備份本機 YAML、Parsers 內容與相關腳本。記下每段加工邏輯的用途，例如「將開發網站加入指定策略組」，不要只保存程式碼。
3. 記下目前模式、選取的策略組、HTTP/SOCKS 連接埠、是否允許區域網路連線，以及 TUN 和 DNS 的自訂項目。
4. 記下開機啟動、服務模式與系統代理狀態。先截圖，再結束舊客戶端，避免讀取尚未寫入磁碟的設定。
5. 將備份複製到獨立資料夾。不要讓新客戶端直接使用舊客戶端的資料目錄，也不要在首次測試前解除安裝舊程式。

開始測試新客戶端前，先關閉 CFW 的系統代理與自動啟動，並確認其核心程序已結束。即使兩個客戶端使用不同連接埠，也可能輪流改寫 Windows 系統代理；同時執行兩個 TUN 執行個體，還可能讓路由與 DNS 行為難以判斷。

先匯入原始訂閱，再檢查產生的設定

在 Clash Verge Rev 的「訂閱」頁面使用匯入功能，貼上原始訂閱網址，再選取匯入的設定。不同版本的按鈕可能標示為「匯入」或「新增」，請以目前版本為準。此時先不要加入舊腳本，目的是確認新客戶端能下載訂閱，且 mihomo 能接受其內容。

不要混淆這三種網址

• 訂閱網址：回傳節點或完整設定，通常含有權杖，可作為更新來源。
• 服務商會員中心：開啟的是登入頁面，複製到訂閱欄位後通常會出現 HTML 解析錯誤。
• 本機匯出的 YAML：可用於離線排查，但通常不會自動恢復原訂閱的更新關係。

匯入後檢查節點數量、策略組與規則是否存在。節點數不同不一定代表資料遺失：回傳內容可能受訂閱參數、User-Agent 或服務商範本影響。先比對原始回應，再考慮調整要求標頭；不要將含有憑證的網址交給不明的線上轉換服務。

分三個層面驗證

1. 下載層：訂閱更新成功，回應內容不是登入頁面、過期提示或空白內容。
2. 設定層：核心成功啟動，記錄中沒有未知欄位、策略組參照不存在或 YAML 型別錯誤。
3. 連線層：選取一個可用節點，實際發出請求測試。延遲測試成功只代表測試目標可連線，不能取代瀏覽器存取與分流驗證。

如果原訂閱必須透過 CFW 的 Parsers 才能正常使用，請先區分「格式轉換」與「追加規則」。一般追加規則可以在下一步重新建立；若回傳格式根本不適用 mihomo，應向訂閱提供者索取相容格式，而不是靠複製舊資料夾解決。

遷移 Parsers：保留邏輯，不照搬入口語法

CFW 的 Parsers 可依訂閱 URL 比對，再修改 YAML 或執行 JavaScript。Clash Verge Rev 的合併設定與腳本設定，使用各自的呼叫慣例與作用範圍。舊程式碼中的 parsers、reg、yaml 等外層結構，不能當成一般 mihomo 欄位貼進最終設定。

建議先將舊邏輯分成三類：新增或刪除規則、修改 DNS 等頂層欄位、改寫節點或策略組。每次只遷移一類，套用後查看客戶端提供的最終設定或執行設定，再處理下一類。需要精確的欄位說明時，請參閱規則語法與DNS 設定。

範例：將 GitHub 網域加入現有策略組

以下範例適用於使用 function main(config) 作為入口的 Clash Verge Rev JavaScript 腳本設定，並非 CFW Parsers 的完整替代檔案。範例假設訂閱中已有名為「節點選擇」的策略組；使用前請核對實際名稱，大小寫與空格都必須完全一致。

function main(config) {
  const groups = Array.isArray(config["proxy-groups"])
    ? config["proxy-groups"]
    : [];

  if (!groups.some(group => group.name === "節點選擇")) {
    throw new Error("找不到策略組：節點選擇");
  }

  if (!Array.isArray(config.rules)) {
    throw new Error("目前設定缺少 rules 清單");
  }

  const customRule = "DOMAIN-SUFFIX,github.com,節點選擇";
  config.rules = [
    customRule,
    ...config.rules.filter(rule => rule !== customRule)
  ];

  return config;
}

這段腳本會將規則放在最前面，並避免重複加入完全相同的項目。它只處理 github.com 及其子網域；GitHub 使用的其他資源網域不會因此自動納入。遷移時請保留明確的比對範圍，不要把單一範例擴大成未經驗證的完整網站規則集。

規則順序與合併方式是關鍵

• 規則通常依序比對：自訂規則若放在最終兜底的 MATCH 後面，通常不會被執行。
• 陣列不一定會自動追加：不同合併入口可能會取代整個 rules 陣列。修改後請確認原訂閱規則仍然存在。
• 訂閱層級與全域覆寫的範圍不同：只適用於特定訂閱的策略組規則，應綁定該訂閱，避免切換後參照到不存在的群組。
• 每次更新都會重新產生設定：直接修改快取或產生的檔案，更新後很容易遺失；請透過客戶端支援的持續性覆寫入口保存變更。

重新設定系統代理與連接埠，確認只有一個核心在監聽

不要因為舊介面的設定，就認定新客戶端也會使用 7890。以下以 127.0.0.1:7890 作為混合代理連接埠範例，實際操作請以新客戶端顯示的數值為準。mihomo 的 mixed-port 可在同一個連接埠接收 HTTP 與 SOCKS 代理要求；分開設定的 HTTP、SOCKS 監聽則可能使用不同連接埠。

先確認監聽正常，再啟用系統代理

在 PowerShell 中執行以下命令，查看範例連接埠的監聽程序。若新客戶端提示連接埠已被占用，請先用程序 ID 找出對應程式，不要直接結束不明的系統程序。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Name "*clash*", "*mihomo*" -ErrorAction SilentlyContinue |
  Select-Object Id, ProcessName, Path

確認監聽正常後，在新客戶端啟用「系統代理」。Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」檢查手動代理位址；Windows 10 的對應路徑為「設定」→「網路和網際網路」→「Proxy」。連接埠應與新客戶端的 HTTP 或混合代理連接埠一致。

如果只在本機使用，通常不需要啟用允許區域網路連線。遷移時不要只為了排除連線錯誤，就將監聽位址改成所有網路介面，也不要將控制介面開放給區域網路。控制介面位址與金鑰屬於另一組設定，並非系統代理連接埠。

使用明確指定代理的要求，隔離問題

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
curl.exe --proxy socks5h://127.0.0.1:7890 --head --max-time 15 https://example.com/

範例設定了 15 秒逾時，並明確指定代理，不受瀏覽器是否讀取系統設定影響。第二條命令中的 socks5h 會讓目標網域交由代理端解析。收到 HTTP 回應表示這條測試路徑已建立，但仍需在連線面板檢查命中的規則、策略組與出口節點。

若瀏覽器可以連線、終端機卻不行，請繼續檢查終端機環境變數與應用程式本身的設定。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 可能仍指向舊連接埠；WinHTTP 代理也與 Windows 使用者層級的系統代理分開管理。不要以為切換一次系統代理，就代表所有應用程式都已完成遷移。

基礎連線正常後，再處理 TUN 與 DNS

系統代理測試通過後，再決定是否需要 TUN。TUN 透過虛擬網卡與路由接管流量，可涵蓋部分不遵循系統代理設定的應用程式，但不代表所有流量都一定會經過遠端代理。最終流向仍取決於規則、路由排除項目與直連策略。

1. 先關閉舊客戶端的 TUN，並確認舊核心與舊服務不會自動重新啟動。
2. 依照新客戶端目前版本的說明安裝或啟用服務模式。舊 CFW 的服務不能直接當成新客戶端的服務使用。
3. 先保留新客戶端產生的 TUN 基本設定，不要同時搬入舊虛擬網卡參數、DNS 劫持規則與自訂路由。
4. 啟用 TUN 後，測試一般網站、區域網路裝置與休眠喚醒。企業 VPN 與其他虛擬網卡也應分別測試，避免同時啟用後難以找出衝突來源。

DNS 需要個別核對 enhanced-mode、fake-ip-filter、上游解析器與客戶端產生的覆寫。舊設定使用 fake-ip，不代表應原封不動複製所有舊 DNS 欄位；支援的欄位應以目前 mihomo 版本為準。若涉及規則化解析，也要檢查網域規則與 DNS 要求路徑之間的關係。

啟用 TUN 後若只有公司內網網域無法連線，請優先檢查企業 DNS 與分流需求；若只有區域網路位址無法連線，則檢查路由與直連規則。不要一開始就把整個內網範圍導向遠端節點。關閉 TUN、改用系統代理重新測試，是區分訂閱問題與虛擬網卡問題的有效方法。

更新驗證、故障排除與舊客戶端清理

不能只以「網頁能開啟」作為遷移完成的標準。至少手動更新一次訂閱、重新啟動一次客戶端，並確認 Windows 登入後能自動啟動。只有更新後自訂規則仍然保留，才表示覆寫已納入持續性流程。

遷移完成前檢查清單

• 訂閱可手動更新，節點與策略組符合預期。
• 自訂規則命中正確，規則中的策略組名稱確實存在。
• 正常結束並重新啟動後，系統代理連接埠沒有被舊程式改回。
• 需要代理的瀏覽器、終端機或其他應用程式都已分別測試。
• 若已啟用 TUN，區域網路、DNS、休眠喚醒與其他 VPN 都已分別檢查。
• 原始訂閱網址、覆寫腳本與設定記錄已保存在獨立備份中。

完成以上檢查後，再解除安裝舊客戶端，並透過舊客戶端提供的管理方式移除不再需要的服務。若需要暫時復原，請先關閉新客戶端的系統代理與 TUN，結束其核心後再啟動舊客戶端；不要讓兩套程式同時接管網路。遷移後的日常設定可參閱連線驗證教學，訂閱維護步驟請見訂閱匯入說明。