Clash 用戶端停止更新後如何遷移：匯出設定、替代方案與訂閱無縫切換

先確認需要遷移的不是一個安裝包

Clash 用戶端停止維護後，真正需要轉移的是訂閱入口、本機設定、策略選擇與系統代理狀態。舊程式本身通常沒有繼續複製的價值。以 Clash for Windows 為例，專案停止更新後，既有版本仍可能暫時運作，但核心、協定實作、系統相容性與安全性修正都不會再跟進。系統升級、訂閱格式變更或憑證策略調整，都可能讓原本正常的設定突然失效。

遷移前先區分「用戶端」與「核心」。用戶端負責設定管理、系統匣選單、系統代理、記錄與介面；核心負責監聽連接埠、解析規則、建立代理連線。較新的用戶端通常採用 mihomo 核心，承襲 Clash Meta 的能力，支援更多代理協定、規則集、流量嗅探與較完整的 TUN 設定。舊用戶端使用的經典 Clash 設定大多可以匯入 mihomo，但反方向不一定相容。

遷移原則

先儲存訂閱網址與目前的 YAML，再安裝新用戶端並完成離線檢查。確認新用戶端可以接管系統代理或 TUN 後，最後退出舊用戶端。不要同時讓兩個核心監聽相同連接埠。

需要儲存的四類內容

訂閱 URL：優先儲存原始訂閱連結，而不是只複製訂閱轉換後產生的 YAML。原始連結通常包含存取權杖，應當作敏感資訊保管。
本機設定：包括手動撰寫的規則、代理群組、DNS、TUN、規則集網址與區域網路存取設定。
策略狀態：記錄常用代理群組目前的選擇，例如「節點選擇」「串流媒體」「下載」分別使用哪個節點或子策略群組。
網路參數：記錄混合連接埠、控制連接埠、系統代理開關、繞過清單與區域網路監聽範圍。

只複製節點名稱並不完整。節點可以由訂閱重新產生，但手動撰寫的規則、覆寫腳本、代理群組選擇與 DNS 排除項通常儲存在用戶端本機。遷移後出現「節點測速正常但網頁無法開啟」，往往就是這些本機設定沒有同步。

匯出訂閱與設定：舊用戶端仍能開啟時的處理順序

第一步：記錄訂閱來源與更新時間

開啟舊用戶端的設定或 Profiles 頁面，逐一記錄設定名稱、訂閱網址、最後更新時間與自動更新間隔。若介面提供「複製訂閱連結」「編輯設定」或「在資料夾中顯示」，優先使用這些入口。不要從記錄中截取連結，因為記錄可能截斷權杖，也可能顯示重新導向後的臨時網址。

建議將遷移記錄整理成一個本機文字檔，至少包含以下欄位。權杖部分不要上傳到雲端硬碟公開資料夾、程式碼儲存庫或截圖分享平台。

設定名稱：日常規則
訂閱來源：https://example.invalid/api/v1/client/subscribe?token=已隱藏
舊用戶端更新間隔：1440 分鐘
模式：rule
混合連接埠：7890
外部控制連接埠：9090
常用策略：節點選擇 → 自動選擇
本機覆寫：dns.yaml、rules.yaml

第二步：匯出正在生效的 YAML

在舊用戶端中找到「編輯設定」「檢視設定檔」或「開啟設定目錄」，複製目前生效的 YAML。Windows 上部分舊版 Clash 用戶端會將資料儲存在使用者目錄下的 .config/clash，macOS 與 Linux 的舊工具也常使用 ~/.config/clash。不同分支可能改用應用程式資料目錄，因此應以介面的「開啟目錄」結果為準，不要只依固定路徑搜尋。

備份時不只要儲存主要設定，也要查看主檔案引用的其他資源。以下欄位代表設定依賴外部檔案或遠端內容：

proxy-providers：代理提供者，可能引用本機檔案或遠端訂閱。
rule-providers：規則集提供者，可能使用 YAML、文字或 MRS 行為格式。
script：舊設定中的腳本規則，遷移前需要確認新核心是否仍支援相同寫法。
dns.nameserver-policy：依網域指定 DNS 的策略，遺漏後會改變解析路徑。
tun：虛擬網卡、自動路由、DNS 劫持與嚴格路由參數。

第三步：儲存覆寫內容，而不是複製執行快取

GeoIP 資料庫、規則集快取、訂閱快取與執行記錄都可以由新用戶端重新下載。真正需要儲存的是使用者主動編輯的覆寫檔案。若舊用戶端具有「全域擴充設定」「Mixin」「預處理」「覆寫」或「腳本」功能，應逐項複製其原文，並記錄它是在主要設定之前還是之後執行。執行順序不同，最終的 dns、rules 與 proxy-groups 結果也會不同。

依平台選擇仍在維護的用戶端

選擇替代用戶端時，不要只比較介面。先確認系統版本、核心類型、設定匯入方式、TUN 權限流程與更新管道。對已有 Clash 設定的使用者而言，採用 mihomo 核心、允許匯入 URL 與本機 YAML、且能檢視實際執行設定的用戶端，通常遷移成本較低。

平台	遷移重點	選擇時核對
Windows	系統代理、服務模式、TUN 驅動程式	是否能清除舊代理、是否支援 mihomo、是否提供執行記錄
macOS	網路擴充功能、管理員授權、鑰匙圈提示	系統版本要求、TUN 授權路徑、退出時是否還原代理
Android	VPN 權限、電池最佳化、背景常駐	是否支援本機設定、依應用程式分流、永遠開啟 VPN
Linux	桌面代理、權限、透明代理	發行版架構、核心權限、系統匣與自動啟動方式

FlClash 可作為 Windows、macOS、Linux 與 Android 上的遷移目標。它提供訂閱設定、本機設定、系統代理與 TUN 相關入口，適合將舊 Clash 設定遷移到 mihomo 執行環境。安裝前應先核對下載頁標示的系統與架構，例如 Windows 的 x64、Linux 的 x64 或 arm64，避免將架構不相容誤判為設定錯誤。

不要讓兩個用戶端同時接管網路

舊用戶端與新用戶端同時啟動時，最常見的衝突是連接埠被占用。許多 Clash 設定使用 7890 作為 HTTP、SOCKS 或混合連接埠，外部控制器常用 9090。如果舊核心仍在監聽，新核心記錄會出現 address already in use 或繫結失敗。

在舊用戶端關閉系統代理與 TUN。
完全退出舊用戶端，確認系統匣圖示消失。
Windows 可在終端機執行 netstat -ano | findstr :7890 檢查連接埠。
macOS 與 Linux 可執行 lsof -i :7890 查看占用中的程序。
確認連接埠已釋放後，再啟動新用戶端。

若必須短時間並行比較設定，可將新用戶端的混合連接埠暫時改為 7891，但不要同時開啟兩個系統代理或兩個 TUN。測試結束後再統一連接埠，避免瀏覽器、終端機與開發工具分別指向不同核心。

在 FlClash 中匯入：訂閱優先，本機 YAML 備用

使用訂閱 URL 匯入

啟動 FlClash 後進入「設定」頁面，選擇從 URL 新增設定，貼上儲存的訂閱網址並執行更新。匯入完成後先不要立即開啟系統代理，先查看設定是否產生節點、代理群組與規則。正常的訂閱至少應能看到代理節點、一個或多個策略群組，以及規則清單；只有節點而沒有規則的設定，可能是節點訂閱而非完整的 Clash 設定。

自動更新間隔可依訂閱服務的變更頻率設定。日常使用建議設為 1440 分鐘，也就是每天一次；節點變化頻繁時可設為 360 分鐘。間隔過短會增加請求次數，也可能觸發訂閱服務的頻率限制。遷移當天建議先手動更新一次，確認回傳內容有效後，再啟用自動更新。

匯入本機 YAML

如果原訂閱網址已失效，但舊用戶端仍能顯示目前設定，可以先匯入備份的 YAML。需要注意的是，本機 YAML 儲存的是匯出時的節點與規則快照，無法自動取得服務端後續變更。恢復網路後應盡快替換為有效訂閱，或將節點與規則遷入自行管理的設定。

匯入前可使用 mihomo 的設定檢查指令驗證語法。若系統中有獨立的 mihomo 可執行檔，可在終端機執行：

mihomo -t -f ./config.yaml

檢查通過只代表 YAML 可以解析，不代表每個遠端規則集、節點網址與 DNS 伺服器都能存取。若提示縮排錯誤，應確認 YAML 使用空格而非 Tab；若提示重複鍵值，應檢查合併設定時是否出現兩個同層級的 dns 或 rules 欄位。

核對參數路徑

匯入後進入「設定」→「參數設定」，核對執行模式、混合連接埠、區域網路存取與外部控制設定。設定頁面負責訂閱內容，參數設定負責用戶端的執行方式，兩者不要混在一起。若設定檔明確寫有 mixed-port: 7890，介面又設定了不同連接埠，應以用戶端最終產生的執行設定與記錄為準。

第一次啟動建議

先使用規則模式，關閉 TUN，僅開啟系統代理完成基本連線測試。確認 HTTP 與 HTTPS 流量正常後，再設定 TUN、依應用程式代理或區域網路存取。如此可以將訂閱問題與虛擬網卡問題分開排查。

遷移後必須核對的規則、DNS 與 TUN

規則順序是否保留

Clash 規則會由上到下比對，命中後便停止繼續搜尋。遷移時即使所有規則都存在，順序改變也會產生不同結果。檢查最終規則中是否先處理區域網路與直連網域，再處理業務規則與代理規則，最後保留兜底項目。典型結構如下：

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-KEYWORD,streaming,媒體策略
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

MATCH 應位於最後。若它被提前放置，後面的規則永遠不會生效。遷移後還要檢查代理群組名稱是否與規則第三項完全一致，包括空格、大小寫與中文字元。規則指向「節點選擇」，但代理群組改名為「代理選擇」時，核心會回報找不到策略。

DNS 是否延續原本的運作模式

mihomo 常見的 DNS 增強模式包括 fake-ip 與 redir-host。舊用戶端使用 fake-ip 時，新用戶端不應在未評估的情況下切換模式。典型 Fake IP 位址池為 198.18.0.1/16，該網段用於基準測試，不應視為真實公網位址。看到網域解析為 198.18.x.x，不代表 DNS 發生故障。

重點檢查以下欄位：

dns.enable 是否為 true。
enhanced-mode 是否與舊設定一致。
nameserver 與 proxy-server-nameserver 是否能在目前網路中存取。
fake-ip-filter 是否保留區域網路裝置、時間同步、遊戲平台與印表機網域。
nameserver-policy 是否仍依預期處理中國大陸與海外網域。

如果遷移後只有代理節點的網域解析失敗，應優先檢查 proxy-server-nameserver。這個欄位用於解析代理伺服器本身的網域，不能依賴尚未建立的代理連線，否則可能形成解析迴圈。測試時可在記錄中搜尋 DNS、lookup、timeout 與節點網域。

分階段啟用 TUN 模式

TUN 會接管比系統代理更多的流量，包括不讀取作業系統代理設定的應用程式。Windows 首次啟用可能需要管理員權限與虛擬網卡元件；macOS 需要核准網路擴充功能；Android 會顯示 VPN 連線授權。遷移時應先確認一般系統代理可用，再開啟 TUN。

開啟後檢查 auto-route、strict-route、DNS 劫持與介面選擇。若區域網路裝置無法存取，可先檢查私有網段是否被錯誤送入代理。常見私有位址包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16。企業 VPN 與 TUN 同時執行時還可能爭用預設路由，需要依單位網路要求為目標網段保留直連。

無縫切換驗證清單

「匯入成功」只代表用戶端接受了設定。要真正完成遷移，還需要驗證系統代理、規則命中、DNS、訂閱更新與退出後的還原。建議依照以下順序執行，每一步通過後再進行下一步。

核心啟動：記錄中沒有連接埠占用、YAML 解析失敗或規則群組缺失。
節點測試：選擇一個延遲穩定的節點，進行 TCP 或 URL 測試。延遲數值只能表示測試目標可達，不代表所有網站都能存取。
系統代理：開啟系統代理，確認瀏覽器流量出現在連線記錄中。
規則命中：分別存取應直連與應使用代理的目標，查看記錄中的策略群組名稱是否符合預期。
DNS 檢查：確認沒有持續發生解析逾時，區域網路網域與常用網站都能解析。
訂閱更新：手動更新一次，記錄耗時與回傳狀態，確認設定不會被空內容覆蓋。
TUN 測試：系統代理通過後開啟 TUN，測試不讀取系統代理的應用程式。
退出還原：退出新用戶端，確認作業系統代理設定已還原，瀏覽器不再指向已關閉的 127.0.0.1:7890。

切換期間避免流量繞過

如果工作環境要求所有外部流量都必須經過代理，遷移時不要依賴「快速切換」碰運氣。可以先中斷需要保護的業務應用程式或暫時關閉網路，在新用戶端載入設定並開啟系統代理或 TUN 後，再恢復連線。瀏覽器既有的長連線、下載工作與即時通訊連線不一定會因代理切換而重新建立，應主動重新啟動相關應用程式。

Android 上可在系統 VPN 設定中檢查「永遠開啟的 VPN」與「封鎖未使用 VPN 的連線」；具體選項名稱會因系統廠商而異。Windows 與 macOS 則應檢查舊用戶端退出後是否留下手動代理。系統代理位址若仍指向 127.0.0.1，但對應連接埠沒有程序監聽，通常會表現為所有瀏覽器頁面都無法開啟。

常見遷移故障與處理方式

訂閱更新成功，但節點清單為空

先查看訂閱回應是否為完整的 Clash YAML。有些服務會根據 User-Agent 回傳不同格式，也可能回傳登入頁面、錯誤 JSON，或只包含節點連結的文字。嘗試在新用戶端的訂閱設定中選擇相容的請求方式；若服務明確要求專用 User-Agent，應依服務說明設定。不要把網頁中的帳戶中心網址當作訂閱 URL。

節點可用，但所有流量都走直連

確認執行模式不是 direct，並在「設定」→「參數設定」中檢查模式是否為規則模式。接著查看規則末尾是否存在 MATCH，以及該規則指向的代理群組目前是否選擇了 DIRECT。部分設定會記住策略群組狀態，而新用戶端第一次匯入時則使用群組內第一個選項，兩者可能不同。

網頁能開啟，但命令列工具不走代理

系統代理主要影響遵循作業系統設定的程式。命令列工具可能需要明確設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也可以透過 TUN 接管。若混合連接埠為 7890，暫時測試可將代理位址設為 http://127.0.0.1:7890。測試完成後記得清除終端機環境變數，避免用戶端退出後命令仍指向失效連接埠。

開啟 TUN 後區域網路裝置失去連線

先關閉 TUN，確認問題是否由路由接管所引起，再查看連線記錄中印表機、NAS 或路由器位址所使用的策略。私有網段通常應直連，但企業網路可能使用其他位址範圍。不要簡單刪除所有 TUN 設定；應依實際網段補充直連規則，並檢查嚴格路由是否與其他 VPN 衝突。

遷移後可以刪除舊用戶端嗎？

完成至少一次訂閱更新、一次系統重新啟動與一次 TUN 測試後，再解除安裝舊用戶端會更穩妥。解除安裝前保留 YAML 與訂閱記錄，但不要繼續保留舊用戶端自動啟動。Windows 可在「設定」→「應用程式」→「啟動」檢查啟動項目；macOS 可在「系統設定」→「一般」→「登入項目與延伸功能」檢查舊程式是否仍獲准在背景執行。

可執行的遷移順序

設定較簡單時，整個遷移約可在 20 至 40 分鐘內完成；包含自訂規則集、企業 VPN 與 TUN 的環境，應預留額外測試時間。依照以下順序操作，可以降低回復成本：

在舊用戶端複製訂閱 URL，匯出目前的 YAML 與所有覆寫檔案。
記錄模式、連接埠、策略群組選擇、DNS 模式與 TUN 開關。
下載與系統架構相符的新用戶端，暫時不要啟用自動啟動。
關閉舊用戶端的系統代理與 TUN，然後完全退出舊程序。
向 FlClash 匯入訂閱 URL；網址失效時再匯入本機 YAML。
檢查代理群組、規則數量、DNS 欄位與遠端規則集狀態。
先開啟系統代理，驗證瀏覽器與規則命中情況，再開啟 TUN。
手動更新訂閱，重新啟動系統並再次測試。
關閉舊用戶端的自動啟動，確認新用戶端穩定後再解除安裝舊程式。

遷移的核心不是把舊目錄搬到新目錄，而是重建一條可驗證的設定鏈：訂閱能夠更新，YAML 能由 mihomo 解析，規則指向存在的策略群組，DNS 可以解析節點與目標網域，系統代理與 TUN 只由一個用戶端接管。逐項確認後，用戶端停止更新不會迫使使用者重做所有規則，也不會中斷原有訂閱的使用。