Clash for Windows 停止更新後如何遷移：Clash 用戶端替代方案與設定轉移指南

Clash for Windows 停止維護後，繼續保留舊版本並不代表現有設定會立即失效。訂閱網址、代理節點、策略群組和分流規則通常仍由設定檔提供，用戶端主要負責設定管理、核心啟動、系統代理、TUN 接管和介面操作。因此，遷移的重點不是尋找外觀完全相同的軟體，而是確認新用戶端能否執行相應核心、讀取現有設定語法，並正確接管作業系統的網路設定。

較穩妥的遷移方式，是先備份舊資料，再選擇仍持續維護的桌面用戶端，透過訂閱網址或原始 YAML 重新匯入，最後逐項檢查規則模式、策略群組、DNS、系統代理和 TUN。不要在舊用戶端仍接管流量時直接啟用新用戶端，否則兩個程式可能同時修改系統代理、虛擬網卡或服務狀態，讓問題來源難以判斷。

先判斷需要遷移的是訂閱、設定還是執行環境

Clash for Windows 中看到的「設定」可能來自不同來源。最常見的是遠端訂閱：用戶端儲存訂閱 URL，更新後下載一份 YAML，再從中讀取節點、策略群組和規則。第二類是手動匯入的本機 YAML，例如自行編寫的分流檔案。第三類則是用戶端本身的設定，包括開機啟動、系統代理連接埠、介面偏好、設定覆寫、腳本處理和 TUN 服務。這三類資料的可遷移程度並不相同。

如果原本只是匯入服務商提供的訂閱，沒有手動修改 YAML，那麼遷移通常很簡單：記下訂閱 URL 和常用的策略群組選擇，在新用戶端重新匯入即可。如果長期維護自訂規則、代理提供者或 DNS 參數，就應一併整理原始 YAML、外部規則檔案和相關路徑，而不是只複製舊用戶端目前產生的執行設定。

如何選擇替代用戶端：核心、平台與設定能力

選擇桌面替代方案時，應先看維護狀態，再看作業系統支援與核心能力。Clash Verge Rev 是支援 Windows、macOS 和 Linux 的桌面用戶端，採用 mihomo 核心，適合需要規則分流、設定管理、系統代理和 TUN 的使用者。mihomo 延續 Clash 設定體系，並擴充規則集、協定、DNS 和流量接管能力，因此大量常見的 Clash YAML 仍可繼續使用。

其他仍持續維護的 mihomo 圖形化用戶端也可列入考慮，但選擇時不要只比較介面。更重要的是發佈頻率、採用的核心版本、設定檔儲存方式、系統代理恢復機制、TUN 服務安裝方式，以及能否查看連線、日誌和規則命中結果。維護狀況可能隨時間變化，應以專案目前的發佈記錄和說明文件為準。

選擇替代用戶端時檢查六個項目

1. 平台支援：確認用戶端明確支援目前的 Windows、macOS 或 Linux 版本，並選擇對應的處理器架構。
2. 核心類型：優先確認是否使用 mihomo，以及用戶端是否允許查看或更新核心版本。
3. 設定相容性：檢查是否支援訂閱、本機 YAML、代理提供者、規則提供者和自訂 DNS。
4. 接管方式：確認系統代理和 TUN 是否分開控制，退出程式時能否恢復系統設定。
5. 診斷能力：連線清單、即時日誌、規則比對和 DNS 日誌有助於找出遷移問題。
6. 設定維護：確認訂閱更新、覆寫或合併機制，避免每次更新都覆蓋本機調整。

舊版 Clash for Windows 的部分設定可能依賴當時的 Clash Premium 行為，也可能透過用戶端專屬的 parser 功能改寫訂閱。mihomo 對常見節點、策略群組和規則語法的相容性較高，但用戶端專屬腳本、JavaScript 解析邏輯和介面設定並不屬於通用 YAML 標準，通常需要重新建立。選擇前可先查看用戶端比較，再依據平台和設定複雜度決定。

如何在遷移前備份 Clash for Windows 資料

備份的目標是保留可復原的資訊，而不是把整個舊目錄原封不動覆蓋到新用戶端目錄。開始前先開啟 Clash for Windows，記下目前啟用的設定名稱、代理模式、常用策略群組選擇、系統代理狀態和 TUN 狀態。如果能在設定管理介面查看訂閱 URL，應另外儲存；若訂閱網址包含存取權杖，請將備份放在受控位置，不要貼到公開截圖、日誌或論壇。

接著退出 Clash for Windows，並確認系統匣程序已經結束。Windows 上的舊資料通常位於使用者目錄下的設定目錄，但具體位置會因安裝方式和版本而異。與其假設固定路徑，更可靠的做法是從用戶端設定或設定管理介面開啟資料目錄，再複製整個目錄作為唯讀備份。

建議保留的內容

• 訂閱 URL、訂閱名稱以及上次成功更新的時間；
• 自行編寫的 YAML 檔案及其中引用的本機規則檔案；
• 目前的執行設定，用於遷移後逐段比對；
• 策略群組的常用選擇，例如自動選擇、故障轉移或指定節點；
• 自訂連接埠、區域網路存取、DNS 監聽和控制器設定；
• 覆寫、合併或 parser 腳本的原始檔案與處理邏輯說明。

備份完成後，在舊用戶端中關閉系統代理和 TUN，再正常退出。可以開啟作業系統的代理設定，確認手動代理沒有繼續指向舊的本機連接埠。如果舊 TUN 服務仍在執行，應先透過舊用戶端提供的服務管理入口停止或解除安裝，再安裝新用戶端的對應服務。

訂閱與 YAML 設定轉移步驟

方案一：重新匯入訂閱 URL

對大多數使用者而言，重新新增訂閱是首選方案。安裝新用戶端後，先保持系統代理和 TUN 關閉，進入設定或訂閱頁面，貼上原訂閱 URL，等待用戶端下載並解析設定。匯入完成後，檢查節點數量、策略群組名稱和規則數量是否符合預期，再手動選擇常用策略。

訂閱匯入成功只代表 YAML 可以讀取，不代表流量已經正常。還需查看設定是否包含最終兜底規則，例如 MATCH，以及主要策略群組是否引用了有效節點。有些訂閱會根據用戶端請求標頭回傳不同格式；如果新用戶端收到空設定或格式錯誤，應先在訂閱服務提供商的管理頁面重新取得適用於 Clash 或 mihomo 的訂閱網址。

方案二：匯入本機 YAML

本機設定應透過新用戶端的檔案匯入功能新增。匯入前可以使用文字編輯器檢查主要段落，包括 proxies、proxy-providers、proxy-groups、rule-providers、rules 和 dns。策略群組引用的節點或提供者名稱必須確實存在，規則中引用的策略群組也必須與定義名稱完全一致。

mode: rule
mixed-port: 7890

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上面的結構展示了最基本的引用關係：規則將流量交給 PROXY，而 PROXY 策略群組必須已經定義。實際遷移時不應機械式照抄範例連接埠或規則，而應保留原有設定需求，並根據新用戶端的使用狀況調整。如果設定引用相對路徑檔案，應確認新用戶端的工作目錄；更換應用程式後，相同的相對路徑可能會指向不同位置。

方案三：重建覆寫與合併邏輯

部分 Clash for Windows 使用者會透過 parser 為訂閱追加規則、刪除策略群組或改寫節點名稱。這類邏輯通常無法作為普通 YAML 匯入。遷移時應先取得訂閱產生的基礎設定，再使用新用戶端支援的覆寫、合併或腳本機制，重新建立相同的處理目標。

重建時宜將操作拆細：先追加一個策略群組，再加入對應規則，確認設定能夠載入後再繼續。一次遷移大量腳本，會讓語法錯誤、名稱引用錯誤和規則順序問題混在一起。規則具有由上而下、命中即停止的特性，新增規則應放在適當位置，不能只確認規則內容存在。

TUN、DNS 與系統代理無法直接照搬

系統代理只會影響遵循作業系統代理設定的應用程式，常見瀏覽器和部分桌面軟體會連到本機 HTTP 或 SOCKS 連接埠。TUN 則透過虛擬網路介面和路由接管更多流量，包括不讀取系統代理的程式。兩者屬於執行環境設定，不是訂閱中的節點資料，因此更換用戶端後必須重新設定。

建議先使用系統代理完成基礎驗證。選擇一個可用節點，啟用規則模式和系統代理，確認網頁存取、規則命中和 DNS 解析正常。基礎連線穩定後再啟用 TUN，並依照新用戶端提示安裝服務或授予管理員權限。如此一來，發生問題時就能明確區分是設定檔錯誤，還是虛擬網卡、權限和路由造成的。

DNS 設定尤其需要謹慎。mihomo 常見的增強模式包括 fake-ip 和 redir-host，具體可用項目取決於核心版本和設定。遷移後如果網頁可以開啟，但某些區域網路網域、遊戲或企業軟體異常，應檢查 DNS 監聽位址、增強模式、排除清單、上游伺服器和規則模式，而不是立即更換節點。

如果原設定啟用了區域網路存取，還應重新核對 allow-lan、監聽位址和作業系統防火牆。監聽回送位址只供本機使用，監聽所有介面則可能允許同一網路中的裝置連線。遷移時應依實際共享需求設定，不要因為舊設定存在就直接複製。

遷移完成後如何確認流量走向

遷移驗證應從設定載入、節點連線、規則比對到系統恢復逐層進行。只測試一個網頁很容易掩蓋問題，因為瀏覽器快取、連線重用和應用程式本身的 DNS 都可能影響結果。可以依照以下順序檢查：

1. 啟動新用戶端，確認日誌中沒有 YAML 解析、策略群組引用或連接埠佔用錯誤。
2. 更新訂閱，確認更新時間、節點數量與策略群組結構合理。
3. 在規則模式下選擇明確的策略群組出口，並測試一般網頁連線。
4. 開啟連線或日誌頁面，查看目標網域命中了哪條規則以及最終策略。
5. 分別測試應直連和應代理的網域，確認 DIRECT 與代理策略符合預期。
6. 啟用 TUN 後測試不讀取系統代理的應用程式，並觀察對應連線是否進入核心。
7. 退出用戶端，確認系統代理已恢復，網路不會繼續指向已停止的本機連接埠。

如果規則命中結果與舊用戶端不同，先比較兩邊實際載入的最終設定，而不是只比較訂閱名稱。訂閱更新、用戶端覆寫、規則集下載失敗和核心功能差異，都可能改變最終內容。mihomo 的連線詳情通常會顯示規則類型、策略鏈和出口節點，這些資訊比單純觀察連線速度更適合判斷分流是否正確。

遷移後的常見問題與處理順序

訂閱可以匯入，但沒有節點

先確認訂閱網址是否仍在有效期內，以及回傳內容是否為 Clash 或 mihomo 設定。有些網址需要在服務管理頁面轉換格式。如果在瀏覽器開啟後得到登入頁面、錯誤文字或其他用戶端格式，新用戶端自然無法產生節點清單。

設定提示策略群組不存在

檢查 rules 中使用的策略名稱是否與 proxy-groups 完全一致，包括大小寫、空格和符號。如果策略群組引用 use，還要確認對應的 proxy-providers 已定義且下載成功。手動刪除策略群組後，引用它的規則也需要同步調整。

啟動時提示連接埠已被佔用

舊用戶端或舊核心程序可能仍在背景監聽連接埠。先完全退出兩個用戶端，在工作管理員或系統監視工具中確認相關程序已結束，再重新啟動新用戶端。也可以暫時修改新用戶端的混合連接埠，但系統代理必須同步指向新連接埠。

啟用 TUN 後無法連線

先關閉 TUN，確認系統代理模式是否正常。如果系統代理可用，應重點檢查 TUN 服務、權限、虛擬網卡、路由和 DNS。曾安裝過多個用戶端時，也應確認舊服務沒有繼續執行。處理服務衝突後再重新啟動系統，避免殘留路由影響判斷。

訂閱更新後自訂規則消失

這通常表示修改內容直接寫入了訂閱快取。遠端更新會重新下載設定並覆蓋快取內容。應使用新用戶端的覆寫或合併機制維護本機規則，或建立獨立的 YAML，並讓遠端節點透過代理提供者方式更新。具體欄位與操作方式可參考技術參考。

舊用戶端是否應該立即刪除

完成備份後，可以先保留安裝檔案和資料目錄，但不要讓舊用戶端開機啟動，也不要與新用戶端同時接管系統代理或 TUN。使用幾天後，確認訂閱更新、規則分流、休眠恢復和退出恢復都正常，再清理舊程式及其服務會更穩妥。

遷移結論：保留設定來源，重新建立執行環境

Clash for Windows 停止更新後的遷移重點可概括為兩部分：可重複使用的是訂閱、節點、策略群組和通用規則；需要重新建立的是用戶端設定、覆寫邏輯、系統代理、TUN 服務和部分 DNS 行為。對一般訂閱使用者而言，重新匯入訂閱並核對策略群組通常已經足夠。對維護自訂 YAML 的使用者而言，則需要重點檢查名稱引用、規則順序、外部檔案路徑和核心語法。

選擇替代用戶端時，持續維護、mihomo 核心支援、診斷能力和系統接管穩定性，比介面相似度更重要。遷移完成後，保留一份原始設定備份，並記錄新用戶端中的關鍵設定。日後更換裝置或用戶端時，就能從明確的資料來源復原，不必依賴某個程式產生的臨時快取。