Clash for Windows 停止更新後如何遷移：替代用戶端與設定相容性指南

先選擇持續維護的用戶端，再遷移訂閱與規則

Clash for Windows 停止維護後，不建議繼續將其作為長期主要用戶端。遷移的重點不是找一套介面完全相同的軟體，而是確認新用戶端採用的核心、支援的設定欄位、系統代理實作方式及 TUN 能力符合目前需求。對於 Windows、macOS 與 Linux 桌面環境，優先考慮採用 mihomo 核心且仍持續維護的圖形化用戶端；需要輕量部署或遠端管理時，也可以直接使用 mihomo 命令列核心搭配控制面板；Android 與 iOS 則應依各平台支援的用戶端重新匯入訂閱，不能直接複製桌面程式目錄。

大多數標準訂閱都能在新用戶端中重新加入，不必搬移舊用戶端的完整執行目錄。真正需要個別處理的是本機 YAML 設定、規則集、策略群組選擇、覆寫內容、腳本、訂閱更新網址，以及區域網路分享參數。Clash for Windows 的介面設定、JavaScript Parser、特定版本的 Profiles 資料結構與系統代理狀態，並不等同於通用 Clash 設定；直接複製後可能出現設定無法載入、規則順序改變或 DNS 行為不同等問題。

依系統、核心與維護狀態選擇替代用戶端

替代用戶端的名稱相近，但並不是同一個專案的延續版本。選擇時應將「圖形介面」與「代理核心」分開判斷：介面負責設定管理、訂閱更新、系統代理開關與日誌顯示；核心負責協定連線、規則比對、DNS、TUN 與流量轉送。採用 mihomo 核心的用戶端通常能識別更多現代設定欄位，但實際支援程度仍會受到用戶端版本、核心版本與作業系統權限影響。

如果原本只使用「規則模式、訂閱更新、系統代理」三項功能，遷移到主流 mihomo 桌面用戶端通常相當直接。若舊環境依賴 TUN、腳本覆寫、複雜 DNS、區域網路分享或多個代理提供者，則應先閱讀目標用戶端的設定說明，再進行小範圍測試。不要只憑介面截圖判斷相容性；同一個用戶端在不同版本中可能更換核心或調整設定儲存方式。

Windows 使用者優先檢查服務模式

Windows 下的一般系統代理主要影響遵循系統代理設定的應用程式；遊戲、命令列程式、部分商店 App，以及自行建立網路堆疊的軟體，可能不會經過這個入口。需要接管更多流量時，通常要使用 TUN。TUN 涉及虛擬網卡、系統管理員權限、路由表與 DNS 接管，因此遷移後應先驗證一般系統代理，再單獨啟用 TUN，避免同時排查多個變數。

macOS 與 Linux 使用者留意權限與桌面環境

macOS 的系統延伸功能、網路權限與背景項目設定會影響 TUN 與開機啟動。Linux 則需要考慮桌面環境的代理設定、NetworkManager、systemd 服務以及核心網路權限。用戶端宣稱支援某個平台，只代表能夠執行，並不保證每種桌面環境都能自動寫入系統代理。對伺服器或無桌面環境而言，mihomo 核心搭配設定檔通常比桌面用戶端更合適。

能匯入訂閱，不代表舊設定可以原樣複製

Clash 設定通常使用 YAML，但「都是 YAML」不代表欄位完全相容。標準代理節點、代理群組與規則具備較高的可遷移性；與特定核心、圖形化用戶端或作業系統綁定的部分，則需要重新檢查。遷移時可以將內容分成四層：訂閱資料、核心設定、用戶端覆寫與系統狀態。

1. 訂閱資料：包括訂閱網址、節點、策略群組與遠端規則提供者。最穩妥的方式是在新用戶端中重新加入訂閱網址，讓目標用戶端自行下載與解析。
2. 核心設定：包括連接埠、執行模式、DNS、TUN、規則、代理群組、外部控制器與區域網路監聽。應依目標核心文件檢查欄位。
3. 用戶端覆寫：包括訂閱合併、全域擴充、設定預處理、腳本與介面儲存的附加項目。這一層通常無法跨用戶端直接重複使用。
4. 系統狀態：包括系統代理、虛擬網卡、服務、啟動項目、防火牆放行與本機連接埠佔用。複製設定檔不會自動遷移這些狀態。

通常可以保留的設定部分

常見的 proxies、proxy-groups、rules、proxy-providers 與 rule-providers 可以作為遷移基礎。使用 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP 和 MATCH 等規則類型時，應繼續維持由上而下的比對順序。第一條命中的規則會決定流量去向；遷移時若用戶端自動插入規則或覆寫規則清單，結果可能與舊環境不同。

需要重新核對的設定部分

• tun 下的網路堆疊、自動路由、介面偵測與 DNS 劫持選項。
• dns 下的 enhanced-mode、Fake IP 範圍、回退解析器與網域過濾清單。
• external-controller、控制器監聽位址與存取金鑰。
• allow-lan、bind-address 與本機防火牆規則。
• 僅由舊用戶端解讀的 Parser、JavaScript 腳本、快速指令與介面覆寫。
• 僅存在於特定核心中的協定參數、規則類型與嗅探設定。

以下是一份用於遷移驗證的簡化結構，重點是確認連接埠、模式、DNS 與規則能由新核心載入。範例不包含真實節點，實際使用時應從訂閱匯入節點與策略群組，而不是將敏感連線資訊寫入公開文件。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這段設定中的 PROXY 必須對應實際存在的代理群組，否則核心會回報找不到策略目標。DNS 位址也只是結構範例，應依網路環境、隱私需求與訂閱說明選擇。若遷移前使用 redir-host，切換至 fake-ip 後可能改變區域網路網域、特殊應用程式與連線測試工具的表現，因此首次匯入時不要順便變更 DNS 模式。

備份設定來源，而不是複製整個執行狀態

開始遷移前，先在舊用戶端中記錄目前能正常運作的基準狀態。備份的目標是能夠說明「原本如何連線」，而不是讓兩個用戶端共用同一個資料目錄。不同用戶端可能同時寫入設定索引、快取與策略選擇記錄，共用目錄容易造成檔案格式衝突。

建議保留的內容

• 有效的訂閱網址及其用途，區分主要訂閱、測試訂閱與本機設定。
• 手動維護的 YAML 檔案、規則檔案、代理提供者與規則提供者網址。
• 目前使用的代理模式，例如規則、全域或直連。
• 常用策略群組的選擇結果，例如自動選擇、故障轉移或指定節點。
• 混合連接埠、HTTP 連接埠、SOCKS 連接埠與外部控制連接埠。
• DNS 增強模式、TUN 狀態、區域網路存取狀態與監聽位址。
• 需要保留的 Parser 或覆寫邏輯，並以文字說明它具體修改了哪些欄位。

訂閱網址與本機設定可能包含存取憑證，不應貼到公開日誌、截圖或線上格式化工具。備份檔案應存放在目前帳戶可控的位置。若準備重灌系統，還應額外記錄用戶端版本、核心版本與系統架構，因為相同設定在不同核心版本上的表現可能不同。

退出舊用戶端前記錄連接埠佔用情況

Clash 類用戶端常用 7890 這類本機連接埠，但實際連接埠可能已被修改。遷移後若新用戶端提示監聽失敗，常見原因包括舊程序尚未退出、另一個代理程式仍佔用連接埠，或系統服務仍在背景執行。關閉視窗不一定等於退出程序，應從用戶端選單正常退出，並檢查工作管理員或系統程序清單。

先以最小設定建立連線，再逐項恢復進階功能

一次匯入所有舊設定會讓故障來源難以定位。較可靠的順序是先驗證用戶端與核心能否啟動，再驗證訂閱解析、節點連線與規則比對，最後處理 TUN、DNS 覆寫與區域網路分享。

1. 確認系統與處理器架構。

   Windows 需要區分 x64、ARM64 等架構；macOS 需要區分 Apple 晶片與 Intel 機型；Linux 還要確認發行版、套件格式與桌面環境。安裝套件架構不相容時，程式可能無法啟動或無法安裝系統服務。

2. 安裝目標用戶端並檢查核心。

   首次啟動後查看用戶端顯示的核心名稱與版本。若準備使用 mihomo 設定擴充功能，應確認目前實際執行的是 mihomo，而不是只憑用戶端名稱推斷。

3. 徹底退出舊用戶端。

   關閉舊用戶端的系統代理與 TUN，再退出背景程序。不要讓新舊兩個用戶端同時修改系統代理、路由與 DNS。

4. 重新加入訂閱。

   優先使用原訂閱網址在新用戶端中建立設定。更新完成後檢查是否產生節點與策略群組，並確認設定頁面沒有解析錯誤。訂閱服務提供的格式若只面向特定用戶端，應先確認是否提供 Clash 或 mihomo 格式。

5. 先啟用規則模式與系統代理。

   選擇一個可用節點或策略群組，保持 TUN 關閉，透過瀏覽器測試基本連線。此時應查看核心日誌，確認網域解析、規則命中與代理握手均正常。

6. 恢復自訂規則與覆寫。

   每次只增加一類變更，例如先恢復規則提供者，再恢復代理群組調整，最後處理 DNS。加入後立即重新載入設定並觀察錯誤位置。

7. 視需要啟用 TUN。

   確認一般系統代理可用後，再授予必要權限並開啟 TUN。測試完成後檢查路由、DNS 與虛擬網卡是否在用戶端退出時正確恢復。

8. 最後設定開機啟動與區域網路分享。

   只有在日常連線穩定後，才設定自動啟動。區域網路分享還需要綁定合適的位址、設定防火牆規則，並限制在可信任的網路中使用。

從核心啟動、規則命中到系統恢復逐層檢查

「瀏覽器可以開啟網頁」只能證明部分鏈路有效。完整遷移還需要確認訂閱能更新、規則結果符合預期、其他應用程式能依需求接入代理，以及退出用戶端後系統網路能夠恢復。

第一層：設定是否被核心接受

先查看啟動日誌。YAML 縮排錯誤、重複欄位、代理群組引用不存在、規則提供者下載失敗與連接埠衝突，通常會在這一層出現。設定解析失敗時不要反覆切換節點，應先定位日誌中的欄位名稱與行號。若本機設定可以載入而訂閱設定不能載入，問題更可能出在訂閱格式或覆寫流程。

第二層：節點與 DNS 是否正常運作

連線測試應同時觀察延遲測試與實際請求。延遲測試成功不代表所有目標網站都能存取，因為測試位址、DNS 結果、規則路徑與協定握手可能不同。出現網域無法存取但 IP 連線正常時，優先檢查 DNS；若所有節點同時逾時，則檢查本機網路、防火牆、訂閱有效性與系統時間。

第三層：規則是否按預期命中

開啟用戶端連線記錄，查看目標網域命中了哪條規則，以及最後使用哪個策略群組。若流量意外直連，請檢查高優先級的直連規則是否覆蓋後續代理規則；若所有流量都經過代理，請檢查目前是否誤選全域模式，或 MATCH 前缺少必要的直連規則。使用規則提供者時，還要確認遠端檔案已成功下載並被設定引用。

第四層：系統代理與 TUN 是否衝突

啟用 TUN 後，部分用戶端仍會同時保留系統代理，在特定環境下可能造成重複接管或增加排查難度。應依目標用戶端的實作方式選擇建議的組合。若只有瀏覽器可用而其他應用程式不可用，表示一般系統代理可能已生效，但目標應用程式不讀取該設定；若啟用 TUN 後完全斷網，應檢查虛擬網卡權限、自動路由、DNS 劫持與其他 VPN 軟體。

第五層：退出後的網路恢復

退出新用戶端後，確認系統代理已關閉、瀏覽器可以直連允許存取的網站，且 DNS 沒有繼續指向失效的本機監聽連接埠。Windows 可檢查系統代理頁面，macOS 可檢查目前網路服務的代理項目，Linux 則依桌面環境與啟動方式檢查環境變數、桌面代理及 systemd 服務。若退出後仍無法連網，先清除殘留代理狀態，再檢查虛擬網卡與路由。

遷移完成後的長期維護重點

新用戶端穩定運作後，還需要固定維護來源。用戶端、代理核心、訂閱與規則資料庫是四個獨立的更新環節，不應把所有異常都歸因於用戶端。介面更新可能改變設定管理方式，核心更新可能新增或調整欄位，訂閱更新會改變節點與策略群組，規則資料庫更新則會影響網域與位址分類。

日常使用中，建議保留一份結構簡單的緊急設定，並記錄目前的穩定版本。更新前先閱讀變更說明，更新後依序檢查核心啟動、訂閱刷新、常用規則與 TUN。若工作環境對連續性要求較高，可以延後重大版本切換，先在獨立設定中測試。替代用戶端的最終目標，是建立可驗證、可回復的設定鏈路，而不是持續追逐介面或功能數量。

如果尚未確定目標用戶端，可以先查看本站的用戶端比較與概念速查，再根據作業系統、是否需要 TUN、是否維護本機規則，以及是否需要區域網路分享來選擇。完成安裝後，依照使用教學建立最小可用設定，比直接匯入所有舊資料更容易定位問題。