Clash 客戶端停止更新後如何遷移：保留設定與替代軟體選擇
說明舊客戶端遷移前的準備工作、設定轉移方式，以及各平台的替代客戶端選擇。
先釐清客戶端、核心與設定檔
Clash 客戶端停止維護，不代表現有訂閱與 YAML 設定會同時失效。遷移前最重要的一步，是分開理解圖形介面、代理核心、設定檔與訂閱服務。圖形客戶端負責下載設定、切換策略群組、控制系統代理並顯示連線記錄；核心負責解析規則、建立代理連線，以及執行 DNS 與 TUN 等網路功能；設定檔則保存連接埠、節點、策略群組與規則之間的關係。
部分舊版桌面客戶端使用早期 Clash 核心，另一些客戶端則已轉向 Clash Meta，也就是目前常見的 Mihomo 核心。Mihomo 延續 Clash 設定體系，並增加更多協定、規則集、DNS 與流量接管能力。遷移到 Mihomo 客戶端時，常見的 proxies、proxy-groups、rules 與 proxy-providers 通常可以繼續使用，但舊客戶端專屬的介面設定、指令碼、資料庫與服務安裝狀態，不能視為通用設定直接複製。
因此，遷移的目標不是把舊程式目錄完整搬到新程式，而是保留可跨客戶端重複使用的資料，再由新客戶端重新建立執行環境。如此可避開舊版快取、失效資料庫、連接埠鎖定與驅動程式殘留所造成的問題。
遷移前需要備份哪些內容
不要等到解除安裝舊客戶端後才尋找設定。部分程式會把設定放在使用者資料目錄，解除安裝也可能一併清除應用程式資料。建議先讓舊客戶端維持可執行狀態，完成以下備份後，再處理新舊程式的切換。
訂閱網址與設定檔
如果設定來自訂閱，請先記下原始訂閱網址，並確認仍可正常更新。客戶端清單中顯示的設定名稱只是本機標籤，不能取代訂閱 URL。若服務商提供專用轉換連結，也應記錄原始訂閱與轉換規則之間的關係，避免遷移後取得不同格式的設定。
對於手動維護的設定，應匯出完整 YAML，而不是只複製節點區段。策略群組會透過節點名稱或 Provider 名稱建立引用，規則又會引用策略群組；只保留 proxies 區段會使這條引用鏈中斷。若設定引用本機規則集、指令碼或覆寫檔案，也要一併複製相應檔案。
本機覆寫與自訂規則
許多客戶端除了訂閱設定外，還提供覆寫功能，例如強制修改 DNS、追加規則、變更監聽連接埠或啟用區域網路存取。這些內容可能儲存在客戶端資料庫中，不會寫回訂閱 YAML。遷移前應逐項檢查「覆寫」、「全域擴充」、「合併設定」或類似頁面，記錄實際生效的設定。
規則順序必須保留。Clash 規則通常由上而下比對，連線命中第一條規則後就會停止繼續檢查。如果把自訂直連規則加在 MATCH 之後，它將永遠不會生效。遷移時即使規則文字完全相同，只要合併位置改變，也可能導致不同的路由結果。
連接埠、區域網路與控制介面
記錄舊客戶端使用的 mixed-port、HTTP 連接埠、SOCKS 連接埠、是否允許區域網路連線，以及外部控制器位址。瀏覽器擴充功能、終端機環境變數、下載工具與其他應用程式可能仍指向舊連接埠。如果新客戶端隨機分配連接埠，而外部程式仍連線到舊連接埠，就會出現「客戶端正常，但部分軟體無法連網」的情況。
external-controller 與控制金鑰主要供圖形介面或外部面板呼叫，不應直接複製到已佔用相同連接埠的並行執行個體。新舊客戶端同時執行時，也不能讓兩者監聽同一個代理連接埠。
敏感資訊的保存方式
訂閱 URL 往往包含用於辨識帳戶的存取參數，完整 YAML 也可能包含伺服器位址、驗證資訊與控制金鑰。備份檔案應儲存在受控目錄，不要把完整內容貼到公開提問區、截圖或公開程式碼儲存庫。需要展示錯誤時，可以保留欄位結構並刪除驗證值。
Clash 設定遷移建議步驟
- 更新並匯出舊設定。在舊客戶端中執行一次訂閱更新，確認策略群組與節點清單可以正常載入，然後保存訂閱網址、YAML 與自訂規則。
- 記錄目前的網路設定。保存代理連接埠、系統代理狀態、TUN 狀態、DNS 模式與區域網路開關。若終端機另行設定代理環境變數，也應記下變數使用的連接埠。
- 關閉舊客戶端的接管功能。先關閉系統代理與 TUN，再完全退出舊客戶端。只關閉視窗不一定會停止背景核心，應在工作管理員或系統活動監視器中確認程序已經結束。
- 安裝並啟動新客戶端。首次啟動時先使用預設設定，不要立即複製舊客戶端的整個資料目錄。確認新客戶端的核心可以正常執行後，再匯入設定。
- 優先重新加入訂閱。訂閱仍有效時，在新客戶端中重新加入 URL，通常比複製快取檔案更可靠。手動設定則透過本機檔案匯入，並維持關聯檔案的相對路徑。
- 重新套用覆寫設定。依照新客戶端支援的格式設定 DNS、連接埠、自訂規則與 Provider。不同客戶端的覆寫語法不一定相容，不能只憑檔案副檔名判斷。
- 先驗證一般代理，再啟用 TUN。先使用系統代理測試網頁與連線記錄，確認節點、策略群組與規則正常後，再單獨開啟 TUN。分階段驗證更容易判斷錯誤來自設定還是流量接管。
- 穩定後再移除舊客戶端。保留舊設定備份一段時間，但不要讓兩個客戶端同時修改系統代理或接管預設路由。
可遷移的基礎設定通常具有清楚的引用關係。以下範例省略具體節點，使用 Provider 提供節點，再由策略群組與規則繼續引用：
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-providers:
provider-main:
type: http
url: "https://example.com/profile.yaml"
path: ./providers/main.yaml
interval: 86400
health-check:
enable: true
url: "https://www.gstatic.com/generate_204"
interval: 600
proxy-groups:
- name: PROXY
type: select
use:
- provider-main
rules:
- DOMAIN-SUFFIX,example.net,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY匯入後若出現「Provider 不存在」或策略群組為空，應依序檢查 Provider 名稱、下載狀態，以及策略群組中的 use 引用。當檔案路徑以設定檔所在位置為基準時，若只移動 YAML，卻沒有一併移動規則集或 Provider 快取，也會導致載入失敗。對於遠端 Provider，快取可由新客戶端重新下載，不必從舊資料庫強行複製。
各平台如何選擇替代客戶端
選擇替代軟體不應只看介面是否相似。更實用的評估面向包括：是否持續維護、採用哪種核心、能否匯入現有設定、是否支援系統代理與 TUN、記錄是否便於排除故障，以及安裝包是否符合系統與處理器架構。遷移到採用 Mihomo 核心的客戶端時，通常可以繼續使用主流 Clash 規則結構，但圖形介面的操作路徑會有所不同。
Windows
Windows 使用者應優先選擇持續維護、明確標示 Mihomo 核心，並支援服務模式或 TUN 管理的桌面客戶端。一般網頁與多數桌面軟體只需要系統代理；遊戲、命令列程式或不讀取系統代理的應用程式，才可能需要 TUN。啟用 TUN 往往涉及系統管理員權限、網路介面卡與系統服務，因此應先完成一般代理測試。
還要確認安裝包架構。多數現代電腦使用 x64，Windows on ARM 裝置可能需要 arm64 版本。遷移期間若系統代理開關無法恢復，可以先退出所有代理客戶端，再到 Windows 代理設定中檢查手動代理是否仍指向舊連接埠。
macOS
macOS 替代客戶端應符合 Apple 晶片或 Intel 處理器。Apple 晶片通常選擇 arm64 或 universal 版本，Intel 裝置則選擇 x64 版本。系統首次執行時可能要求確認網路延伸功能、輔助服務或 VPN 設定，這些授權屬於 TUN 接管流程，不是 YAML 設定的一部分。
從舊客戶端遷移後，如果選單列顯示代理已啟用，但應用程式仍直接連線，應檢查目前網路服務的系統代理是否正確寫入。macOS 可能同時存在 Wi-Fi、有線網路與其他網路服務；當客戶端修改的服務與目前實際使用的服務不一致時，也會造成代理狀態看似開啟，但流量未經過核心。
Android
Android 上的 Clash 類客戶端通常透過系統 VPN 介面接管流量，而不是使用桌面系統代理。遷移重點是重新匯入訂閱、允許建立 VPN 連線，並檢查應用程式分流、繞過設定與電池背景限制。舊客戶端匯出的應用程式分流清單不一定能被新客戶端辨識，需要重新選擇哪些應用程式經過代理。
如果裝置上已有其他 VPN、廣告過濾器或工作設定檔網路，系統通常無法同時讓多個一般 VPN 介面生效。測試新客戶端時，應先停止其他 VPN 服務。Android 安裝包也要符合 arm64-v8a 等處理器架構；不確定時可選擇客戶端正式提供的通用版本，但檔案體積通常較大。
Linux
Linux 使用者可以選擇圖形客戶端，也可以直接執行 Mihomo 核心並搭配 systemd 管理。桌面環境的系統代理只會影響遵循該設定的程式，終端機工具仍可能需要 http_proxy、https_proxy 與 all_proxy 環境變數。使用 TUN 時，還要檢查核心權限、路由表與 DNS 管理方式。
從圖形客戶端遷移到命令列核心時，尤其要保留設定引用的相對目錄，並明確指定工作目錄。同一份 YAML 在不同啟動目錄下執行，外部規則檔案與 Provider 路徑可能會解析到不同位置。建議將設定、Provider 與規則集放入固定目錄，再由服務參數明確指定設定路徑。
iPhone 與 iPad
iOS 與 iPadOS 不能直接安裝桌面版或 Android 版 Clash 客戶端。應選擇平台允許安裝、支援所需協定與規則格式的網路工具，並依其匯入能力轉換設定。Clash YAML 不一定能被所有 iOS 客戶端原樣讀取，策略群組、指令碼、規則集與 DNS 欄位可能需要依目標應用程式的文件調整。遷移前先確認訂閱服務是否提供對應格式，比手動複製節點更穩妥。
訂閱、規則與 DNS 相容性檢查
設定可以匯入，只代表 YAML 語法通過，不代表所有連線都會依預期路由。遷移後應檢查訂閱更新、節點連線、策略群組引用、規則命中與 DNS 解析五個層面。
訂閱更新失敗
先確認錯誤發生在下載階段還是解析階段。下載逾時通常與網路、訂閱網址或代理迴圈有關；解析失敗則可能是回傳內容不是 YAML、訂閱轉換格式錯誤，或設定包含目前核心無法識別的欄位。如果客戶端支援「透過代理更新訂閱」，首次啟動時應謹慎使用，因為此時尚未有可用節點，容易形成更新依賴。
規則集無法載入
舊設定可能透過 rule-providers 引用遠端規則集。遷移後要檢查行為類型、格式、URL、儲存路徑與規則中的引用名稱。規則 Provider 的名稱與策略名稱是兩套概念，不能互換。使用 GEOIP、GEOSITE 等規則時，也應確認客戶端能下載並載入相應的地理資料庫。
DNS 行為變化
舊客戶端與新客戶端可能使用不同的預設 DNS 設定。啟用 fake-ip 後，核心會向應用程式回傳保留位址，再根據內部對應處理實際連線；redir-host 的解析路徑則不同。遷移時不要在尚未了解舊設定的情況下直接複製整段 DNS 設定，尤其要檢查監聽位址、上游伺服器、回退規則與 Fake IP 排除清單。
如果出現網頁偶爾無法開啟、區域網路裝置網域名稱失效或某些應用程式登入異常，可以暫時關閉自訂 DNS 覆寫，使用新客戶端的預設值重新測試。若預設設定正常，再逐項恢復舊設定。一次修改多個 DNS 欄位會使故障排查失去比較基準。
TUN 模式遷移與常見故障
TUN 模式會建立虛擬網路介面，並透過路由或系統網路延伸功能，將更多流量交由核心處理。它能涵蓋不遵循系統代理的應用程式，但也比一般系統代理更依賴作業系統權限。舊客戶端的 TUN 驅動程式、服務註冊資訊與路由狀態不應複製到新客戶端。
正確順序是先在舊客戶端關閉 TUN，完全退出並確認虛擬介面已停止運作，然後讓新客戶端依自身流程安裝服務或申請權限。新舊客戶端同時啟用 TUN，可能出現預設路由競爭、DNS 反覆被改寫、網路迴圈或斷網。
啟用 TUN 後完全斷網
- 檢查目前策略群組是否選用了可用節點，以及最終規則是否指向存在的策略群組。
- 檢查系統中是否還有其他 VPN、代理工具或網路過濾程式佔用路由。
- 確認客戶端服務具備所需權限，且虛擬介面建立過程沒有報錯。
- 暫時關閉自訂 DNS 與複雜路由設定，使用客戶端的預設 TUN 設定進行測試。
- 關閉 TUN 後，確認一般系統代理仍能運作，以區分節點問題與流量接管問題。
瀏覽器正常但終端機失敗
這通常表示瀏覽器使用了系統代理，而終端機程式沒有讀取系統代理。可以讓終端機工具明確連線到新客戶端的 HTTP 或 SOCKS 連接埠，或啟用設定正確的 TUN。遷移後要同步更新環境變數中的舊連接埠；只在圖形客戶端中變更監聽連接埠，不會自動修改 shell 設定檔。
關閉客戶端後仍顯示代理
客戶端異常退出時，系統代理可能沒有恢復。此時應先在作業系統的網路設定中關閉手動代理，再重新啟動新客戶端。不要透過反覆啟動多個舊客戶端來爭奪系統代理狀態，這會讓目前的設定更難判斷。若 TUN 服務仍在背景執行，也應透過新客戶端提供的服務管理功能將其停止，必要時重新啟動系統以清除暫存路由。
遷移完成後的驗證清單
遷移完成後，不應只用「網頁能開啟」作為判斷標準。完整的驗證流程至少應包括以下項目：
- 訂閱可以手動更新，更新後設定不會遺失自訂規則。
- 策略群組中可以看到預期節點，且自動測速或健康檢查可以執行。
- 瀏覽不同類型的網站時，連線記錄會命中預期的規則與策略。
- 關閉系統代理後流量恢復直接連線，重新開啟後連接埠與客戶端設定一致。
- TUN 開啟與關閉後都不會留下異常路由，區域網路存取符合設定。
- 終端機、瀏覽器與需要代理的獨立應用程式都使用正確連接埠。
- 重新啟動作業系統後，客戶端能依預期啟動，設定與權限仍然有效。
- 舊客戶端已退出，不會再自動啟動或修改系統代理。
確認運作穩定後，可以解除安裝舊客戶端，並保留一份整理好的設定備份。備份中應註明建立日期、適用核心與相依檔案，避免數個月後無法判斷檔案來源。訂閱設定仍應透過客戶端定期更新，本機自訂規則則建議獨立保存，降低訂閱覆寫造成遺失的風險。
客戶端遷移的關鍵不是複製更多檔案，而是釐清哪些資料屬於通用 Clash 設定，哪些狀態屬於舊程式。先備份訂閱與規則，再分階段驗證系統代理、DNS 與 TUN，就能將停止更新客戶端帶來的切換風險控制在可定位的範圍內。