遷移選型 預計閱讀 12 分鐘

Clash 用戶端停止更新後：轉移至 mihomo 用戶端的替代方案

整理 Clash 原版核心停止更新後的生態變化，分別介紹仍在維護的 Android 與桌面版 mihomo 用戶端，並說明設定檔轉移時需調整的欄位與注意事項。

先分清停止更新的是用戶端還是核心

開啟舊用戶端的「關於」頁面，先記下應用程式名稱、應用程式版本與核心版本，再決定要替換哪個部分。用戶端負責匯入訂閱、顯示節點及啟動服務；核心則負責讀取設定、比對規則及建立代理連線。兩者並非同一個專案，更新狀態也不一定相同。

原版 Clash 相關專案於 2023 年停止公開維護後，舊安裝檔不會因此自動失效。現有節點可能仍可連線，但無法據此保證支援新協定、修正系統相容性問題或處理後續問題。Clash for Windows、原版 Clash for Android 與 mihomo 也不能只因名稱相似，就視為同一條更新路線。

mihomo 是由 Clash.Meta 專案延續而來的代理核心。舊教學中的「Meta 核心」通常指這條技術路線，並不是另一種訂閱服務。轉移的重點是選擇仍持續更新且能執行 mihomo 的用戶端，再分開轉移訂閱與本機設定。

Android 與桌面版分別該選哪種方案

先依作業系統篩選，再查看專案的正式發布紀錄、支援架構與核心說明。以下列出 mihomo 生態中的轉移選項，並不代表任何舊安裝檔會持續獲得維護。專案狀態可能變動，安裝當天仍應確認近期發布與問題處理情況，不要只憑下載檔案的修改日期判斷。

裝置平台 轉移選項 安裝前檢查
Android Clash Meta for Android、FlClash Android 最低版本、ARM 架構、核心版本與 VPN 授權
Windows Clash Verge Rev、Clash Nyanpasu、FlClash 系統架構、實際使用的核心、TUN 服務安裝需求
macOS Clash Verge Rev、FlClash、ClashX Meta Apple Silicon 或 Intel 安裝檔、網路權限與輔助服務
Linux Clash Verge Rev、FlClash 發行版套件格式、桌面環境、TUN 權限與服務執行方式

Android：先轉移設定，再接管流量

如果習慣原版 Clash for Android 的設定、代理與記錄頁面，可以先評估 Clash Meta for Android；若希望手機與電腦使用相近的介面，則可考慮 FlClash。兩者的選單、備份格式與內建設定不盡相同，請勿直接互換整個應用程式資料夾。

多數較新的 Android 手機採用 ARM64，但不能只看手機上市年份。請先在下載說明中確認裝置支援的 ABI，也就是應用程式二進位介面；確認支援 arm64-v8a 後，再選擇 ARM64 套件。Android 版本需求也應以相應發行版的說明為準。

桌面版：先用系統代理測試，再考慮 TUN

Windows 與 macOS 使用者可以先匯入訂閱、選擇節點，只啟用系統代理來測試瀏覽器。Clash Nyanpasu 等支援多種核心選項的用戶端，還要在核心管理頁面確認執行的是 mihomo。請勿把用戶端版本號當成核心版本號。

TUN 是接收裝置網路流量的虛擬網路介面，涵蓋範圍通常比只修改系統代理更廣，但會涉及路由、DNS 與系統權限。舊用戶端若透過系統代理正常運作，轉移的第一輪也應用相同方式測試，避免同時引入多個變因。

先從舊用戶端備份這四類資料

  1. 訂閱來源：保存原始訂閱 URL、更新間隔與服務提供者的說明。訂閱 URL 通常含有帳號權杖，請勿貼在公開筆記、截圖或線上轉換頁面中。
  2. 設定副本：匯出目前可用的 YAML 檔案。YAML 是以縮排表示層級的文字設定格式，編輯時請保留空格縮排，勿混用定位字元。
  3. 本機變更：記下自訂規則、覆寫、指令碼與 DNS 設定。用戶端可能在啟動時才將這些內容合併至執行設定，若只複製訂閱檔案就會漏掉這些資料。
  4. 系統設定：記下代理連接埠、區域網路分享開關、應用程式分流與自動啟動設定。Android 的應用程式排除清單，以及桌面版的系統代理開關，通常都不屬於通用訂閱的一部分。

如果舊介面提供「檢視執行設定」，可以另外保存一份作為比對，但不要直接覆蓋新用戶端的整個工作目錄。執行設定可能包含暫存路徑、控制介面金鑰及已展開的節點密碼，不但不適合跨裝置重複使用，也不宜公開求助時分享。

設定轉移：逐項檢查欄位與名稱引用

在新用戶端的訂閱或設定頁面，優先使用原始 URL 新增設定，再手動更新一次。若只有本機檔案，請使用「從檔案匯入」之類的功能。名稱會因用戶端而異，重點是分清「訂閱來源檔案」與「應用程式設定備份」，兩者不可混用。

逐一檢查代理、策略群組與規則的關聯

  • proxies 儲存直接寫入設定的節點；proxy-providers 儲存外部節點提供者。使用後者時，也要確認下載網址可連線，且本機快取路徑可寫入。
  • proxy-groups 定義策略群組，例如手動選擇群組。群組引用的節點名稱、其他群組名稱與提供者名稱都必須存在，大小寫與空格也要完全一致。
  • rules 依序比對連線。排在前面的規則會先比對，不要將範圍廣泛的 MATCH 規則放在仍需繼續比對的規則之前。
  • rule-providers 用來引用外部規則集。請檢查其 type、behavior、format 是否與實際檔案內容相符；網域清單不能直接當成完整的 classical 規則集。

遇到「策略群組不存在」時，先核對錯誤訊息中的名稱，不要立刻更換節點。用戶端覆寫將「代理」改成「節點選擇」，但自訂規則仍引用舊名稱，也會造成設定載入失敗。

連接埠與控制介面不要整段照搬

mixed-port 是同時接受 HTTP 與 SOCKS 代理連線的本機連接埠；external-controller 則是供介面或管理工具呼叫的控制介面，不是代理連接埠。以下僅為本機設定片段，不能直接當成完整訂閱執行：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

這段範例使用 7890，不代表所有用戶端的預設值都是這個連接埠。如果終端原本連線至 127.0.0.1:7890，但新用戶端實際監聽 7897，就必須同步修改終端設定，或透過用戶端支援的設定入口調整連接埠。

不要將舊檔案中的 external-controller、secret、external-ui 與絕對路徑直接搬到手機。新用戶端可能會自行管理控制介面與資源目錄；將監聽位址改為 0.0.0.0，也可能擴大介面的可存取範圍。若無明確需求，請保留由應用程式管理的本機設定。

DNS、TUN 與舊指令碼分開處理

DNS：先使用新用戶端提供的預設方案

DNS 是將網域名稱轉換為 IP 位址的過程。轉移後若出現「節點延遲正常，網頁卻無法開啟」，未必是節點協定不相容，也可能是網域解析路徑改變。請先保留新用戶端建議的 DNS 設定，確認可用後再逐項轉移原有的自訂解析伺服器。

fake-ip 是透過分配合成 IP 協助分流的模式。如果舊設定使用 198.18.0.1/16 這類位址範圍，請勿誤認為節點的真實 IP。切換 DNS 模式後，應重新建立測試連線；必要時重新啟動應用程式或清除系統 DNS 快取，避免舊結果影響判斷。

TUN：手機與電腦的路由參數不要照搬

Android 用戶端通常透過 Android 的 VpnService 介面接收流量，首次連線時會出現系統 VPN 授權對話框。桌面版則可能需要安裝輔助服務或授予管理員權限。兩者都能接管流量，但系統授權方式、路由實作與可用選項各不相同。

tun.stack、auto-route 與 dns-hijack 應依目標用戶端與作業系統逐一檢查。不要因為舊電腦設定寫了某個虛擬網卡名稱，就把該名稱寫入手機設定。Android 也要檢查「設定」→「網路和網際網路」→「VPN」中的舊應用程式設定；部分廠牌會將入口放在「連線與分享」中。

指令碼：先確認由哪一層執行

舊設定中的 script:、舊介面裡的 JavaScript 覆寫，以及第三方訂閱轉換範本，屬於不同機制。不要假設 mihomo 會執行舊版 Clash Premium 指令碼，也不要將桌面用戶端的覆寫指令碼直接匯入 Android。請先停用指令碼，以標準規則建立可用的基準設定，再將必要邏輯改寫為目標用戶端明確支援的規則或覆寫。

用五個步驟確認轉移結果

  1. 檢查設定載入：開啟記錄，確認沒有 YAML 縮排錯誤、未知代理類型或找不到策略群組的提示。載入失敗時，先處理第一個錯誤；後續錯誤可能只是連帶結果。
  2. 檢查訂閱更新：手動更新一次，核對節點數量與帳號有效期限。HTTP 401 或 403 應先檢查權杖與存取權限，不要將這類回應誤認為代理連接埠衝突。
  3. 檢查單一節點：在策略群組中手動選擇一個節點並執行連線測試。延遲測試只表示指定測試請求的結果，不代表所有網站或所有協定都能正常使用。
  4. 檢查實際分流：保持 Rule 規則模式，分別前往預期直連與預期代理的目標，並在連線清單中確認命中的規則、策略群組與最終節點。
  5. 檢查系統接管：桌面版分別測試瀏覽器與終端；Android 則分別測試瀏覽器、目標應用程式，以及鎖定螢幕後重新喚醒時的連線狀態。

例如，確認桌面版本機 HTTP 代理連接埠為 7890 時，可使用下列命令單獨測試代理請求。這只會影響該次請求，不會替你啟用系統代理，也無法證明 TUN 路由運作正常。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

此處的連線逾時為 10 秒，總耗時上限為 20 秒，這些是疑難排解參數，不是實測速度。如果記錄出現 address already in use，先確認舊服務是否仍占用連接埠；若出現 no such host，優先檢查相關網域的解析過程；若出現 context deadline exceeded，還需搭配目標位址與連線階段判斷，不能直接認定訂閱已失效。

保留還原方式，避免訂閱更新覆蓋修正

完成第一輪測試後，再恢復自動啟動、背景執行與自訂規則。Android 可至「設定」→「應用程式」→目標用戶端→「電池」檢查背景限制；各系統的選項名稱可能不同。若已啟用「一律開啟 VPN」或「封鎖未使用 VPN 的連線」，請確認綁定的是新用戶端，否則停用舊應用程式後，整台裝置可能無法連線。

訂閱下次更新後，再確認一次自訂規則是否仍存在。直接編輯訂閱下載產生的 YAML，通常會在更新時被覆蓋。長期修改應放入用戶端支援的覆寫、合併設定或獨立規則提供者中，並確認最終執行設定中的規則順序。

  • 分別保存舊設定與新設定，並在檔名加上日期，以免混淆。
  • 記下用戶端版本、mihomo 核心版本與問題重現步驟，方便找出相容性問題。
  • 尋求協助時只分享已去除敏感資料的記錄，並移除訂閱權杖、節點密碼與控制介面金鑰。
  • 需要還原時，先關閉新用戶端的系統代理或 VPN，再恢復舊服務，避免殘留路由。

判斷轉移是否完成，不能只看新介面能否開啟；訂閱必須能更新、規則能命中、目標應用程式能連線，而且重新啟動或解除鎖定後仍符合預期。先完成這條最短驗證流程，再調整 DNS、TUN 與複雜覆寫，疑難排解的範圍會更明確。

下載用戶端