Clash for Windows 停止更新後如何遷移：Clash Verge Rev、FlClash 等替代用戶端

遷移範圍：分別處理用戶端、核心與設定

Clash for Windows（以下簡稱 CFW）原專案已於 2023 年停止維護。已安裝的程式不一定會立即失效，但後續的系統相容性、協定支援與問題修正，已無法再仰賴原專案。遷移的目標不是複製整個安裝資料夾，而是保留訂閱來源、分流需求與必要設定，再由新用戶端重新建立執行環境。

用戶端負責介面、訂閱管理、系統代理與服務控制；核心則負責解析設定、建立連線及執行規則。CFW 過去有不同的核心使用方式，因此不能只看用戶端名稱，就判斷舊設定具備哪些功能。遷移前應記下實際使用的核心類型與版本，再確認新用戶端內建的核心；不要直接比較兩套軟體的用戶端版本號。

• 優先遷移：訂閱網址、本機 YAML、自訂規則、策略組名稱、規則集來源。
• 分開重新設定：系統代理開關、開機啟動、服務權限、TUN 網卡與路由設定。
• 視需要保留：策略組目前的選擇、延遲測試參數、DNS 設定，以及個別應用程式指定的代理埠。
• 不要直接覆寫：舊用戶端資料庫、核心執行檔、快取資料夾與虛擬網卡驅動程式。

替代用戶端：依平台與設定方式選擇

Windows 桌面使用者可優先比較 Clash Verge Rev 與 FlClash。兩者都以 mihomo 核心管理設定，但介面配置、設定增強功能入口與系統整合方式各有不同。Linux 與 macOS 使用者也要確認安裝套件的架構；Android 使用者則不能沿用 Windows 安裝套件和系統代理的操作方式。

請以本機實際顯示的核心版本為準

用戶端更新與核心更新採用不同的版本序列，同一個用戶端也可能允許切換核心。先從用戶端的核心資訊或記錄檔確認版本；若能找到實際的核心檔案，也可在終端機讀取版本。以下命令需在對應的執行檔所在資料夾執行，檔名以安裝內容為準：

# Windows PowerShell
.\mihomo.exe -v

# macOS / Linux
./mihomo -v

不要為了顯示較新的版本號，就直接替換舊用戶端內的核心。控制介面、啟動參數與目錄慣例可能不相容。選擇用戶端時，先確認訂閱所需的協定，再確認目標用戶端實際採用的核心是否支援；能匯入 Clash 設定，不代表支援 mihomo 的所有擴充欄位。

遷移前先備份：保存來源檔案與最終生效設定

舊用戶端中看到的訂閱檔案，可能不是核心最後載入的內容。CFW 的 Parsers、Mixin 或手動修改，可能會在訂閱載入後繼續變更埠、規則與策略組。如果只保存訂閱連結，後續新增的規則很容易在新用戶端中遺失。

1. 記錄目前狀態。保存用戶端版本、核心版本、目前的設定名稱、執行模式，以及系統代理和 TUN 是否已啟用。
2. 備份訂閱來源。保存原始訂閱網址與服務提供者名稱。訂閱網址通常含有存取權杖，請勿放在公開筆記或截圖中。
3. 複製本機檔案。從舊用戶端開啟設定所在資料夾，將 YAML、引用的本機規則集與自訂處理指令碼複製到獨立的備份資料夾。
4. 記錄處理結果。如果舊用戶端提供檢視執行中設定的功能，也請另存最終設定，並註明它與原始訂閱的差異。執行中的設定可能含有明文節點憑證，請以敏感檔案方式保存。
5. 保存系統設定。記下 HTTP/SOCKS 埠、區域網路共享、略過清單，以及瀏覽器或命令列工具個別指定的代理位址。

Windows 可前往「設定」→「網路和網際網路」→「Proxy」查看目前的手動代理設定。若舊設定使用 127.0.0.1:7890，請記下這個位址與埠；這只是常見範例，不代表每台電腦都使用 7890。macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「Proxy」確認，選單名稱可能因系統版本略有不同。

匯入訂閱：先確認連線，再還原增強功能

在新用戶端的訂閱或設定頁面新增原始訂閱網址，更新完成後選取該設定。不同發行版本的入口可能標示為「設定」、「訂閱」或「Profiles」；操作重點是確認下載成功、核心載入成功，且節點清單不是空的。如果需要登入訂閱服務重新產生連結，請先確認新連結的格式與 mihomo 相容。

1. 先關閉舊用戶端的系統代理、TUN 與背景服務，再結束舊用戶端。只關閉視窗，程式可能仍在系統匣中執行。
2. 在新用戶端匯入一份設定，先使用規則模式，暫時不要啟用 TUN、區域網路共享或開機啟動。
3. 選取一個已知可用的節點，檢查連線記錄，再啟用系統代理並造訪平常需要使用的網站。
4. 確認基本連線正常後，再加入自訂規則、DNS 設定、規則集與設定增強功能。
5. 手動更新一次訂閱，確認增強內容仍然存在，避免只有目前檔案中的修改成功保留。

遇到埠號衝突，先處理占用的程序，別反覆修改設定

舊核心與新核心不能同時監聽相同位址的同一個埠。如果記錄中出現 address already in use，請先檢查占用 7890 的程序，不要連續更換埠號。以下為診斷範例：

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

如果確認需要改用 7891，瀏覽器擴充功能、終端機環境變數及其他手動設定的代理用戶端也必須一併修改。系統代理開關通常只會影響遵循系統設定的應用程式，無法保證所有程式都會自動套用。

規則與自訂設定：檢查引用、順序與覆寫關係

mihomo 能處理許多 Clash 格式的設定，但遷移時不能只把欄位逐字複製過去。首先確認 proxies、proxy-providers、proxy-groups 與 rules 之間的名稱引用。策略組改名後，如果規則仍使用舊名稱，可能會載入失敗。規則會由上而下比對；兜底規則 MATCH 應放在最後，否則後續規則將無法生效。

用最小設定骨架確認本機設定能否載入

以下是用來測試新用戶端能否載入的最小 YAML。它只包含直連，沒有代理節點，也不能取代正式訂閱。確認核心能夠載入後，再加入實際節點或 provider 與策略組；請勿直接用這份骨架覆寫訂閱檔案。

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

proxy-groups:
  - name: 業務出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,業務出口

這裡的 業務出口 同時用於策略組名稱與規則目標，兩處必須完全一致。mixed-port 會在同一個埠提供 HTTP 與 SOCKS 代理入口。範例未設定 external-controller，因此不會額外開啟控制介面；如果用戶端會自行管理控制介面，請依照用戶端產生的設定操作。

逐項遷移訂閱增強功能與規則集

• Parsers 與 Mixin：這些是用戶端端的處理機制，並非通用的核心設定區段。請將實際效果改寫為新用戶端提供的合併或指令碼功能，不能假設舊指令碼可以原樣執行。
• 規則集：保留 rule-providers 的來源、behavior、format 與更新間隔，並確認 RULE-SET 中引用的名稱。
• 本機路徑：舊資料夾中的相對路徑，在新的工作目錄下可能失效。遷移本機規則檔案後，請重新確認核心實際解析的路徑與讀取權限。
• 舊版指令碼模式：如果舊設定依賴 Clash Premium 的指令碼功能，不能假設 mihomo 提供相同的執行方式。請將分流需求改寫為目標核心支援的規則或用戶端處理邏輯。
• 策略組狀態：策略組定義可以遷移，不代表目前選取的項目也會一併遷移。重新選擇出口後，再確認自動測速與故障切換是否符合預期。

DNS 與 TUN：最後啟用，分別測試

先使用系統代理確認連線與規則，再啟用 TUN，可降低同時排查 DNS、路由與權限問題的難度。TUN 會在虛擬網卡層接管流量，通常需要系統權限或背景服務；Windows 服務安裝、macOS 網路授權與 Android VPN 授權採用不同機制，必須在目標系統上重新完成設定。

DNS 設定應整體遷移。fake-ip 模式會回傳用於對應網域名稱的位址，但不代表 DNS 請求一定會經過代理。還須確認 DNS 上游、nameserver-policy、相關路由，以及 TUN 的 DNS 劫持設定。瀏覽器內建的安全 DNS、應用程式中的 DoH 和其他 VPN，也可能改變 DNS 解析路徑。

• 區域網路服務：測試路由器管理頁面、NAS 與印表機。如果本地域名依賴路由器 DNS，請確認相關查詢仍會交給適當的本機解析器。
• 公司網路：測試公司內網域名與 VPN。多張虛擬網卡同時變更預設路由時，請逐一停用，找出衝突來源。
• DNS 快取：切換 Fake-IP 模式或解析策略後，請重新啟動測試中的應用程式；Windows 可視需要執行 ipconfig /flushdns 清除系統 DNS 快取。
• 監聽範圍：只有確定需要其他裝置連線時，才啟用區域網路共享，並檢查防火牆規則。單機遷移不需要將代理埠開放給區域網路。

如果系統代理運作正常，但啟用 TUN 後出現異常，請優先檢查權限、路由與 DNS，不要立刻更換訂閱。節點測速成功只代表某一項測試請求能完成，無法證明應用程式流量已正確交由 TUN 接管。

驗收與回復：更新訂閱後再停用舊環境

遷移驗收至少應涵蓋一般瀏覽器、手動指定代理的工具，以及需要 TUN 的應用程式。下表列出檢查項目與預期結果，並非預先提供的實測成績。建議對同一目標連續操作三次，記錄時間、命中規則與出口，避免把偶然連線成功當成遷移完成。

失敗時依相反順序回復

先關閉新用戶端的 TUN 與系統代理，再停止背景服務，並確認監聽埠已釋出。接著啟動舊用戶端，還原原本的設定與代理狀態。兩個用戶端不要同時搶用系統代理或 TUN 路由。如果新用戶端已結束，但瀏覽器仍無法連線，請確認系統是否還留有指向 127.0.0.1:7890 的手動代理設定，而該埠已無服務在監聽。

完成訂閱更新、系統重新啟動與常用應用程式測試後，再移除舊的開機啟動項目並解除安裝舊用戶端。保留一份離線設定備份與遷移紀錄，記下新用戶端版本、實際核心版本、埠號與增強規則入口。之後若遇到訂閱變更或系統升級問題，就能判斷故障來自用戶端、核心還是設定，不必重新猜測整個連線流程。