Clash for Windows 停止維護後如何遷移：替代用戶端與設定轉移步驟

停止維護的影響與遷移範圍

Clash for Windows 停止維護後，既有安裝不會立即失效。本機設定、已下載的訂閱與代理規則仍可能繼續運作，但用戶端不再持續適配作業系統變化，也不會跟進新的 mihomo 核心欄位、TUN 實作與安全性修正。繼續使用舊版本時，常見問題不是「節點突然全部失效」，而是訂閱格式更新後無法完整讀取、系統代理狀態未正確還原、TUN 服務與新版作業系統發生衝突，或新的規則欄位被舊核心忽略。

遷移時需要區分三類資料。第一類是訂閱入口，包括訂閱網址、遠端設定更新時間與設定名稱；第二類是使用者修改，例如自訂規則、覆寫欄位、腳本處理與策略組選擇；第三類是裝置接管狀態，包括系統代理、開機啟動、區域網路存取、TUN 服務與 DNS 設定。只複製一個 YAML 檔案，通常無法涵蓋這三類資料。

如果日常設定完全來自訂閱，遷移重點是重新匯入訂閱，並在新用戶端中還原策略組選擇。若曾在 Clash for Windows 中使用 Mixin、Parsers、Script 或手動編輯設定，則要另外記錄這些修改。不同圖形化用戶端對覆寫功能的名稱與格式並不一致，舊用戶端中的 JavaScript 解析器也不能直接視為通用設定。

遷移前備份訂閱與本機修改

記錄訂閱入口

開啟 Clash for Windows 的 Profiles 頁面，確認目前使用的是遠端訂閱還是本機設定。遠端訂閱應儲存原始訂閱網址，而不是只保留由用戶端快取產生的 YAML。原始網址可讓新用戶端重新擷取最新節點、策略組與規則；快取檔案只能反映某次更新時間的內容，之後也可能因遠端規則集路徑變更而載入失敗。

訂閱網址通常包含用於識別帳戶的參數，應依密碼資訊的標準處理。不要將網址放入公開截圖、問題回報或公開程式碼儲存庫。若服務提供者允許重設訂閱連結，網址已外洩時應先重設，再將新網址匯入新用戶端。

匯出本機設定

對於手動維護的 YAML，可從用戶端開啟設定所在目錄，將目前使用的主要設定及其引用檔案複製到獨立目錄。需要一併檢查的檔案包括代理提供器、規則提供器、本機規則集與憑證相關檔案。主要設定中的相對路徑依賴原有目錄結構，移動檔案後要維持層級一致，或在新用戶端中重新指定路徑。

設定中最值得單獨記錄的欄位如下：

mode：目前使用規則模式、全域模式還是直連模式。
proxies 與 proxy-providers：手動節點與遠端節點提供器。
proxy-groups：策略組名稱、類型、引用關係及健康檢查網址。
rules 與 rule-providers：自訂規則順序與外部規則集。
dns：DNS 是否啟用、運作模式、上游伺服器及排除範圍。
tun：虛擬網卡、自動路由、DNS 劫持與介面選擇。

如果只是從訂閱匯入設定，不建議長期直接修改訂閱產生的 YAML。下一次更新可能會覆蓋這些內容。遷移到新用戶端後，應優先使用用戶端提供的覆寫、擴充腳本或設定合併功能儲存使用者修改，並確認該功能會在每次訂閱更新後重新執行。

製作遷移紀錄

關閉舊用戶端前，記錄目前選取的策略組節點、系統代理連接埠、是否允許區域網路連線、TUN 是否啟用，以及哪些應用程式依賴代理。策略組選擇一般儲存在用戶端自己的資料庫或快取中，不一定會寫回訂閱 YAML。即使組名與節點名稱完全相同，新用戶端首次載入時也可能回到組內第一個項目，需要手動重新選擇。

如何選擇替代用戶端

選擇替代用戶端時，不應只比較介面。更重要的是核心、平台支援、設定相容性與接管方式。目前持續更新的用戶端多以 mihomo 作為核心。mihomo 延續 Clash 設定體系，並增加規則集、DNS、流量嗅探與 TUN 等能力。用戶端負責設定管理與系統整合，核心負責解析設定、建立連線及執行規則。

用戶端方向	適用環境	遷移重點
Clash Verge Rev	Windows、macOS、Linux 桌面裝置	適合訂閱管理、系統代理與 mihomo TUN；舊版 Mixin 需要改寫為新用戶端支援的覆寫方式。
Mihomo Party	需要桌面圖形介面與設定管理的裝置	先確認安裝套件架構，再依照其設定擴充機制遷移本機修改。
Clash Nyanpasu	需要跨平台桌面用戶端的使用者	檢查目前版本使用的核心、訂閱更新方式與 TUN 權限提示。
FlClash	桌面及部分行動裝置環境	適合希望維持相近操作流程的使用者；匯入後仍需核對規則模式與 DNS。
命令列 mihomo	伺服器、路由器或自行管理服務的環境	需要手動維護設定路徑、啟動參數、記錄檔、更新與系統服務。

Windows 使用者通常需要確認安裝套件對應 x64、ARM64 等裝置架構。macOS 還要區分 Apple 晶片與 Intel 處理器。Linux 使用者除了架構外，也應檢查桌面環境、套件格式與系統服務權限。用戶端能否啟動只是第一步，系統代理開關、TUN 驅動程式或服務能否正確安裝，才決定流量是否能穩定接管。

如果原設定包含 mihomo 專用欄位，應選擇明確使用 mihomo 核心並持續更新的用戶端。若設定只包含基本連接埠、一般節點、策略組與規則，大多數相容 Clash 設定的用戶端都能讀取。圖形化用戶端自己的覆寫資料庫、介面偏好與快速設定則不屬於 YAML 標準，通常無法直接跨用戶端複製。

從 Clash for Windows 轉移至新用戶端

第一步：解除舊用戶端的流量接管

在 Clash for Windows 中關閉 System Proxy。
若已開啟 TUN Mode，先關閉 TUN，再等待網路介面恢復。
退出用戶端，確認背景程序已經結束。
檢查作業系統代理設定，確認沒有殘留指向舊連接埠的手動代理。

這一步是為了避免連接埠衝突與重複路由。兩個用戶端同時啟用系統代理時，最後寫入系統設定的一方通常會成為入口，但另一個用戶端仍可能佔用連接埠。兩個 TUN 同時執行則可能造成預設路由競爭、DNS 查詢繞路或區域網路存取異常。

第二步：安裝並首次啟動新用戶端

從用戶端專案提供的發布管道取得與作業系統及處理器架構相符的安裝套件。首次啟動後先不要立即開啟系統代理或 TUN，先查看核心狀態與設定目錄是否正常。部分用戶端會單獨更新 mihomo 核心；如果介面顯示核心尚未就緒，應先依照用戶端提示完成核心安裝或切換。

第三步：重新匯入訂閱

在新用戶端的訂閱或設定入口貼上原始訂閱網址，執行下載並設為目前設定。載入成功後檢查節點數量、策略組名稱與規則數量是否與舊用戶端大致一致。數量不必逐項完全相同，因為訂閱服務可能在遷移期間更新內容，但不應出現設定為空、只有少量節點或所有策略組遺失的情況。

如果訂閱回傳「格式錯誤」，先確認複製的網址沒有多餘空格與換行，再嘗試透過瀏覽器或服務提供者控制台重新取得連結。若訂閱內容由舊版 Clash 格式產生，而新用戶端使用 mihomo，通常可以讀取基本欄位；真正容易出錯的是縮排不正確、引用檔案無法存取、策略組引用了不存在的節點，或訂閱回應實際回傳的是登入頁面。

第四步：遷移自訂規則與覆寫

將舊設定中的個人規則依照原有順序加入新用戶端支援的覆寫位置。Clash 規則會由上到下比對，第一個命中的規則決定流量去向，因此順序比規則數量更重要。區域網路直連、指定網域代理、應用程式程序規則與最後的兜底規則不能任意交換。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

上例僅說明順序結構。實際使用時，Proxy 必須與設定中的策略組名稱完全一致。組名包含空格或中文時也要逐字對應。若訂閱每次更新都會重建策略組，應將自訂規則指向穩定存在的組名，避免更新後出現「找不到策略組」的載入錯誤。

Clash for Windows 的 Parsers 可能使用 JavaScript 修改訂閱結果，這類邏輯不能直接貼到所有新用戶端。應先了解腳本修改了哪些欄位，再改寫為目標用戶端支援的覆寫、合併設定或擴充腳本。不要在不了解執行階段的情況下同時啟用多套覆寫，否則可能出現連接埠被重複修改、DNS 欄位被後執行的設定覆蓋等問題。

第五步：還原策略選擇與更新週期

逐一開啟策略組，還原常用節點或自動選擇方式。對於 url-test、fallback 等自動組，確認健康檢查可以執行；對於 select 手動組，確認目前選項不是失效節點。接著設定訂閱更新間隔，並手動更新一次，觀察覆寫內容是否仍然存在。

如何還原系統代理與 TUN 設定

訂閱載入完成不代表裝置流量已經進入 Clash。新用戶端仍需要建立流量入口。系統代理與 TUN 是兩種不同的接管方式，應先從系統代理開始驗證，再根據應用程式相容性決定是否開啟 TUN。

先測試系統代理

開啟新用戶端的系統代理後，作業系統會將支援系統代理設定的 HTTP 或 SOCKS 流量傳送到本機監聽連接埠。瀏覽器與多數桌面應用程式通常可以直接使用這種方式。開啟用戶端連線記錄，造訪測試網站，確認記錄中出現網域、命中規則與最終策略組。

若開啟後完全無法連線，檢查新用戶端監聽連接埠是否被其他程式佔用、系統代理是否寫入正確的本機位址，以及設定是否處於 Rule 模式。關閉用戶端後系統仍無法連線，則應進入作業系統網路設定，清除殘留的手動代理。

再設定 TUN

遊戲、命令列工具、部分商店應用程式與不讀取系統代理的軟體，可能需要 TUN 接管。TUN 會建立虛擬網路介面，將符合路由條件的 IP 流量交給 mihomo。首次開啟通常需要管理員權限，並可能安裝系統服務或虛擬網卡元件。

遷移 TUN 時不要直接照抄舊用戶端的開關狀態。先使用新用戶端建議的預設設定，確認虛擬介面成功建立，再檢查 auto-route、strict-route、DNS 劫持與介面自動辨識。不同作業系統對這些欄位的實作有所差異，新用戶端也可能透過介面產生對應設定。

如果 TUN 開啟後區域網路印表機、NAS 或路由器管理頁面無法存取，先檢查私有網段是否維持直連，並查看嚴格路由是否改變本機存取路徑。若只有網域存取異常而直接 IP 正常，重點檢查 DNS 模式、Fake-IP 排除清單與上游 DNS 可達性，而不是反覆切換節點。

遷移後檢查清單

完成訂閱匯入與流量接管後，依照以下順序檢查。每完成一項再進入下一項，可以快速判斷問題位於設定、規則還是系統入口。

核心狀態：用戶端顯示 mihomo 正常執行，沒有持續重新啟動或設定解析錯誤。
訂閱更新：手動更新可以完成，更新時間有所變化，節點與策略組正常顯示。
設定模式：確認目前是需要的 Rule、Global 或 Direct 模式，遷移後不要預設沿用介面初始值。
策略組：手動組已還原選擇，自動組可以完成延遲測試，規則引用的組名全部存在。
系統代理：瀏覽器存取會產生連線記錄，關閉系統代理後網路設定能正確還原。
DNS：網域解析穩定，記錄中沒有連續逾時；區域網路網域與特殊網域依預期處理。
TUN：僅在確有需要時開啟，並驗證不讀取系統代理的應用程式能進入連線記錄。
區域網路：路由器、NAS、印表機與共用服務仍可存取，私有位址沒有被錯誤送往代理。
開機啟動：確認啟動項目只保留新用戶端，並檢查系統代理或 TUN 是否會依預期恢復。
舊用戶端處理：穩定使用一段時間後再解除安裝舊用戶端，解除安裝前確認備份目錄不在應用程式資料清理範圍內。

常見遷移故障排查

訂閱匯入成功但沒有節點

先查看訂閱回應是否為有效設定。有些網址需要在服務提供者控制台重新產生，過期連結可能回傳提示文字而不是 YAML。還要確認用戶端沒有啟用錯誤的訂閱轉換範本，以及設定檔中的節點提供器網址可以存取。

設定可以載入但規則全部走兜底

檢查自訂規則是否放在 MATCH 之後。MATCH 是最終規則，後續項目不會再執行。若使用遠端規則提供器，還要確認 rule-providers 下載成功，並且規則中的 RULE-SET 名稱與提供器名稱一致。

開啟系統代理後部分應用程式沒有作用

這通常表示應用程式沒有讀取作業系統代理，而不是訂閱匯入失敗。先在用戶端記錄中確認瀏覽器流量正常，再為目標應用程式設定其自身代理，或在確認權限與路由設定後使用 TUN。不要因為單一應用程式沒有記錄就立即修改整套 DNS 設定。

開啟 TUN 後無法上網

先關閉 TUN，確認系統代理模式仍能運作。接著檢查虛擬網卡服務權限、預設介面辨識、路由衝突與 DNS 上游。裝置中執行的其他網路過濾器、虛擬機網路、企業 VPN 也可能改寫路由。排查時每次只啟用一種接管工具，避免多個變數同時變動。

訂閱更新後自訂規則消失

這表示規則直接寫入訂閱快取檔案，更新時被遠端內容覆蓋。應將規則移至新用戶端提供的持久覆寫位置，並確認覆寫會在訂閱解析後執行。遷移完成後至少手動更新兩次，用來驗證規則、DNS 與策略組修改能持續保留。