先分清用戶端、核心與訂閱
Clash for Windows 通常簡稱 CFW，雖然名稱有 Windows，也曾推出 Linux 與 macOS 版本。它負責管理訂閱、選擇代理群組及切換桌面設定；實際處理連線的是隨用戶端執行的代理核心。CFW 停止維護後，舊版仍可能啟動，但不代表它會持續支援新系統、新協定或安全性修補。
遷移不等於重新購買訂閱，也不是把整個舊資料夾直接覆蓋到新資料夾。應分別處理三類內容：用戶端的操作設定、核心讀取的 YAML 設定，以及服務商提供的訂閱網址。三者彼此相關，但不能互相取代。
- 用戶端設定：開機啟動、系統代理、快速鍵、介面偏好與背景服務，通常都需要在新程式中重新設定。
- 核心設定：節點、代理群組、規則、DNS 與 TUN 欄位，都要確認新核心是否支援。
- 訂閱網址：用來重新取得遠端內容。只保留下載後的 YAML 檔案，不代表仍能自動更新。
依作業系統選擇替代方案
如果原本主要使用 Clash YAML，優先選擇能讀取這類設定的用戶端，通常能降低遷移成本。mihomo 是原 Clash Meta 專案延續使用的名稱，支援更多協定與規則功能；不過用戶端是否提供相關開關、內含哪個核心版本，仍須以實際安裝內容為準。選擇前可先查看用戶端比較，再確認專案近期的發布紀錄與對應作業系統的安裝套件。
| 裝置系統 | 可評估的方案 | 遷移前先確認 |
|---|---|---|
| Linux 桌面 | Clash Verge Rev、FlClashs | CPU 架構、DEB 或 RPM 套件格式、系統匣支援與服務權限 |
| Windows | Clash Verge Rev、Clash Nyanpasu | 系統版本需求、核心類型，以及舊的系統代理是否已停用 |
| macOS | Clash Verge Rev、ClashX Meta | Apple Silicon 或 Intel 架構、系統版本與網路權限 |
| Android | FlClash 等仍持續更新支援的用戶端 | Clash 設定支援、VpnService 權限與背景省電限制 |
| iOS | 支援所需協定與設定匯入功能的 iOS 用戶端 | 當地 App Store 是否提供、訂閱格式與規則語法是否相容 |
Linux 使用者先確認安裝套件格式
Ubuntu、Debian 等發行版通常選擇 DEB；Fedora 等系統通常選擇 RPM。套件格式相同，也不代表相依套件一定符合需求。在終端機執行 uname -m，輸出 x86_64 通常代表 x64，aarch64 通常代表 ARM64。不要把「下載得到」當成「適合目前裝置」。
行動裝置不要直接套用桌面端的流量接管方式
Android 的 VpnService 是系統提供的流量接管介面，不能直接照搬 Linux 的服務模式。iOS 用戶端也可能採用不同的設定格式；支援相同節點協定，不代表能完整匯入 Clash 的代理群組與規則。先用一份設定測試匯入，再決定是否遷移全部設定。
舊版 Clash for Android 同樣屬於需要留意維護狀態的封存方案，不宜只因名稱熟悉就當成長期替代品。上表提供的是選擇方向，不代表未來一定持續維護。
備份訂閱與本機修改
先保留舊用戶端作為回復方案，不必急著解除安裝。在 CFW 的 Profiles 頁面逐一確認設定，記下名稱、來源、目前選取項目與更新間隔。訂閱連結應從原服務商後台或用戶端的複製功能保存；如果只有本機檔案，請註明「本機匯入」，避免誤以為它能自動更新。
- 匯出原始設定：保存目前使用的 YAML，也保留尚未經用戶端處理的原始訂閱內容，並在檔名加上備份日期。
- 另外保存加工邏輯：檢查 CFW 的 Parsers、Mixin，以及手動新增的規則。這些用戶端層級的設定不一定包含在訂閱檔案中。
- 記錄執行參數：記下 HTTP、SOCKS 或混合連接埠、是否允許區域網路連線，以及目前模式與 DNS 設定。
- 保存外部相依檔案：本機規則集、憑證檔案及設定引用的其他檔案都要備份，別只複製主 YAML 而漏掉它們。
- 記錄代理群組選擇：記下常用群組與節點名稱。舊快取可能無法由新用戶端讀取，最好另外準備一份文字清單。
在 Linux 上可先建立只有目前使用者能存取的備份資料夾，再將匯出的檔案放入其中。以下指令只會建立資料夾並限制權限，不會自動尋找或匯出舊設定：
mkdir -p "$HOME/cfw-migration"
chmod 700 "$HOME/cfw-migration"
# 將匯出的設定與遷移紀錄放入此資料夾後，再收緊檔案權限：
find "$HOME/cfw-migration" -type f -exec chmod 600 {} \;匯入設定，不要覆蓋整個舊資料夾
新用戶端首次啟動後，先關閉 TUN 與系統代理，再匯入一份設定並檢查解析結果。如果有訂閱連結，優先重新匯入連結；只有本機 YAML 時，則選擇匯入本機設定。若用戶端提供不同的匯入類型，請分清「遠端設定」與「本機檔案」，避免更新按鈕看似可用，實際上卻沒有更新來源。
先處理欄位相容性，再調整規則
多數常見的 proxies、proxy-groups、rules 結構仍可沿用，但仍須檢查解析記錄。原版核心專屬的指令碼功能、CFW 專用加工語法與舊版實驗欄位，不能假設在 mihomo 中也會照常運作。遇到錯誤時先找出回報的欄位，不要只為了載入檔案就大量刪除所有未知內容。
- 節點協定：VLESS、Hysteria2 等功能取決於目標核心；設定載入成功，不代表每個節點都已成功連線。
- 規則提供者：
rule-providers的下載網址、行為類型與格式都必須相符，並留意記錄中的下載或解析失敗訊息。 - 本機路徑：Windows 磁碟機路徑不能直接用於 Linux；相對路徑的解析位置，應以新用戶端的設定資料夾與核心行為為準。
- 規則順序：規則通常由上往下比對。自訂規則若放在最後的
MATCH之後，通常不會產生預期效果。
將自訂修改放入可持續保留的覆寫設定
不要只修改下載後產生的訂閱檔案，否則下次更新可能會覆蓋變更。優先使用新用戶端支援的覆寫、合併或指令碼機制，並確認實際合併結果：有些機制會取代整個規則陣列，有些則能將規則置頂，不能只看功能名稱就下判斷。先新增一條容易驗證的規則，更新一次訂閱，再確認規則仍然存在。
CFW 的 Parsers 或 Mixin 應逐項改寫成目標用戶端支援的形式，而不是照搬原本的包裝結構。欄位用途可參考核心與設定參考進行確認。
分開測試系統代理與 TUN
遷移時最常見的問題不是節點損壞，而是兩個用戶端搶用同一個連接埠，或舊系統代理仍指向已關閉的程式。切換前，請在 CFW 的 General 頁面關閉 System Proxy；如果之前啟用過 TUN，也要先關閉並正常退出舊用戶端，再啟動新用戶端。
第一輪只測試本機代理連接埠
以下假設新用戶端已明確設定 mixed-port: 7890，並監聽本機迴環位址。7890 只是本次檢查使用的連接埠，不是所有用戶端的預設值。請以介面或實際生效的設定為準，並使用自己有權存取的測試網址：
# 查看 Linux 上 7890 連接埠的監聽狀態
ss -lntp 'sport = :7890'
# 明確透過 HTTP 代理送出請求，不依賴桌面系統代理
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 \
--output /dev/null --write-out 'HTTP %{http_code}\n' \
https://clash86.com/連線遭拒通常代表沒有程式在監聽、連接埠填錯或程式啟動失敗；逾時則需進一步檢查核心記錄、節點連線與 DNS。即使收到 HTTP 回應，也只能證明這次請求有回應，仍應在用戶端的連線記錄中確認實際使用了預期的規則與代理群組。
第二輪再啟用系統代理
確認本機連接埠可用後，再讓新用戶端設定系統代理，並以瀏覽器測試。系統代理主要適用於會遵循相關設定的應用程式；終端機程式是否使用代理，還取決於環境變數與程式本身的參數。GNOME 桌面可執行 gsettings get org.gnome.system.proxy mode 查看桌面代理模式，但這項結果不代表所有應用程式都已透過代理連線。
最後再依需求啟用 TUN
TUN 用來接管更多不遵循系統代理設定的連線，因此需要相應權限或用戶端服務。先確認新用戶端已獲得服務權限，再啟用 TUN；不要讓新舊兩個虛擬介面同時接管預設路由。Linux 上可用 ip rule 和 ip route show table all 輔助檢查，但不要照抄網路文章中的批次刪除路由指令。詳細步驟請參閱TUN 模式教學。
依驗收清單確認遷移完成
延遲測試通過不代表遷移已完成。這類測試通常只確認測試目標可連線，不能取代實際服務、規則比對與 DNS 檢查。建議使用相同網路，依照下列順序逐項驗證，每次只調整一個設定，方便找出問題。
| 驗收項目 | 操作方式 | 通過條件 |
|---|---|---|
| 訂閱更新 | 手動更新一次，檢查時間與記錄 | 節點仍在，自訂規則沒有被覆蓋 |
| 規則分流 | 分別開啟應直連與應走代理的網址 | 連線記錄顯示預期規則與代理鏈 |
| DNS 與內部網路 | 連線至常用網域、路由器與內部網路服務 | 解析正常，區域網路連線未被錯誤接管 |
| 背景恢復 | 關閉視窗、從休眠喚醒、切換網路 | 背景程序與所需的流量接管狀態皆可恢復 |
| 退出後恢復 | 關閉代理後正常退出新用戶端 | 系統不再指向失效的本機代理連接埠 |
如果啟用 fake-ip 後發現內部網站解析異常，請搭配 DNS 設定與 fake-ip-filter 進行排查；不要把所有 DNS 問題都簡單歸咎於「節點不好」。IPv6 也要另外確認：能連上 IPv4 網站，不代表 IPv6 連線也經過預期路徑。
手機還要增加一次鎖定螢幕測試。Android 裝置鎖定螢幕後若中斷連線，請先檢查電池最佳化、自動啟動與背景限制；這和桌面端是否成功匯入 YAML 設定是不同問題。
保留回復期限，再清理舊安裝
首次驗證完成後，至少經過一次重新開機、一次網路切換與一次訂閱更新，再考慮解除安裝 CFW。保留備份不代表要讓舊用戶端繼續開機執行：請關閉它的開機啟動，並確認舊背景服務不會占用連接埠。刪除程式檔案也不一定會自動移除系統服務或網路設定，清理方式應依原本的安裝方式處理。
- 在新用戶端完成正常退出測試，確認一般網路連線可恢復。
- 保留訂閱來源、本機覆寫設定與遷移紀錄，並確認備份檔案確實能讀取。
- 取消舊程式的開機啟動，並依原本的服務管理或解除安裝方式清理背景元件。
- 若要回復舊環境，先關閉新用戶端的系統代理與 TUN，再啟動舊環境，避免重複接管流量。
遷移是否完成，不是看介面是否相似，而是確認訂閱能更新、規則有跡可循、退出後網路能恢復。依「備份 → 匯入 → 本機連接埠 → 系統代理 → TUN → 重新開機驗收」的順序操作，遇到問題就能判斷卡在哪個環節，不必一次重裝所有元件。