Clash for Windows 停更後怎麼辦：完整遷移至 mihomo 核心客戶端

先判斷需要遷移的是客戶端、訂閱，還是本機設定

Clash for Windows 停止維護後，既有安裝不會立即失效。只要訂閱網址仍可存取、節點協定仍受目前核心支援，舊客戶端通常仍能載入設定並轉送流量。真正的問題在於核心長期未更新後，新協定欄位、規則語法、DNS 行為與系統相容性都不會持續跟進。保留舊版本適合作為短期過渡，不適合作為長期的設定入口。

遷移前先區分三類資料。客戶端是圖形介面與系統整合層；訂閱是由伺服器產生設定的入口；本機 YAML 則可能包含手寫節點、規則集、DNS 與 TUN 參數。三者不能當成同一個檔案處理。只有訂閱的使用者，遷移通常只需儲存訂閱 URL。若有手寫規則或覆寫內容，還要另外匯出設定並記錄本機參數。

遷移目標

優先選擇仍在維護、採用 mihomo 核心、能顯示核心版本並支援設定檢查的客戶端。mihomo 延續 Clash 設定體系，並擴充協定、規則集、DNS、TUN 與流量嗅探能力；舊設定通常可直接匯入，再依裝置進行調整。

遷移前應儲存的內容

訂閱原始 URL，以及訂閱名稱、更新時間與剩餘流量資訊。
目前正在使用的 YAML 檔案，不要只儲存客戶端截圖。
策略群組中手動選取的節點，例如「節點選擇」、「串流媒體」、「下載」分別選取了哪些節點。
本機覆寫內容，包括 DNS、TUN、追加規則、略過代理的網址與應用程式分流清單。
系統代理連接埠。常見的混合連接埠是 7890，控制連接埠常見為 9090，但仍應以舊設定的實際值為準。

從 Clash for Windows 找到設定

在 Clash for Windows 中先進入「Profiles」，確認目前的設定名稱。訂閱設定可記錄頁面上的訂閱網址；本機設定可透過設定選單開啟檔案所在位置。常見資料目錄位於 %USERPROFILE%\.config\clash，但可攜版、自訂 Home Directory 或不同發行版本可能使用其他路徑，應以客戶端顯示的目錄為準。

複製目錄時，重點查看 config.yaml、訂閱產生的 YAML、Provider 快取與自訂腳本。快取檔案不是遷移核心，新 mihomo 客戶端會重新下載代理提供者與規則集。需要保留的是原始設定，以及日後能再次取得設定的網址。

選擇 mihomo 客戶端時，查看核心與系統能力

遷移不等於尋找外觀完全相同的 Clash for Windows。更可靠的選型方式是先核對核心，再檢查系統接管方式與設定管理。桌面端需要系統代理、TUN、開機啟動與設定更新；Android 端需要 Android VPN 權限、依應用程式分流、背景執行與電池策略支援。

桌面端需要核對的項目

核心資訊可見：在「設定」或「關於」頁面確認使用 mihomo，並顯示具體版本號。
設定檢查清楚：匯入失敗時應指出 YAML 的行號或欄位，而不是只顯示啟動失敗。
系統代理可控制：能夠設定 HTTP、SOCKS 或 Mixed 連接埠，常見預設值為 7890。
TUN 狀態可確認：能顯示虛擬網卡是否建立，並提示管理員權限或服務安裝狀態。
覆寫與訂閱分離：訂閱更新後，本機連接埠、DNS 與 TUN 的修改不應被整份覆蓋。

Android 端需要核對的項目

支援 mihomo 設定，並能匯入遠端訂閱或本機 YAML。
透過 Android 的 VPN 介面接管流量，啟動時會出現系統 VPN 授權視窗。
提供「設定」→「網路」或「設定」→「覆寫」等入口，用於調整 DNS、IPv6、TUN 堆疊與 MTU。
提供依應用程式設定代理的功能，可設定只代理選取的應用程式，或排除指定應用程式。
記錄頁面能查看連線目標、命中規則、策略群組與出站節點。

客戶端介面名稱可能不同，但核心能力應以實際版本與設定測試為準。匯入後可在記錄中尋找 mihomo 啟動資訊，再造訪一個網頁，確認連線記錄同時顯示目標網域、命中規則與出站策略。如果只看到介面顯示「已連線」，不能證明 DNS 與規則鏈都正常。

遷移訂閱：優先重新匯入原始網址

僅使用機場或服務商訂閱時，最穩妥的方式不是複製 Clash for Windows 產生的 config.yaml，而是在新客戶端中重新加入原始訂閱 URL。桌面端通常從「設定」→「新增」→「URL」加入；Android mihomo 客戶端通常從「設定」→右上角「+」→「從 URL 匯入」加入。填寫名稱後立即更新一次，再檢查代理群組與節點數量。

在舊客戶端記錄訂閱更新時間、節點數量與主要策略群組名稱。
在新客戶端加入相同的訂閱網址，設定更新週期，例如 1440 分鐘。
更新完成後選取該設定，並等待核心重新載入。
進入「代理」頁面，確認 GLOBAL、DIRECT、REJECT 以及自訂策略群組都能正常顯示。
依序測試至少兩個節點，記錄延遲與實際連線狀態。

延遲數值只能用於初步篩選。某個節點顯示 42 ms，不代表下載速度一定高於 95 ms 的節點。遷移驗收時可進行三項具體檢查：網頁首次開啟是否在 2 秒內完成、連續播放 1080p 影片時是否頻繁緩衝、同一測試檔案的穩定速率是否明顯低於遷移前。若所有節點都異常，應先檢查 DNS、系統代理與 TUN，而不是反覆更換訂閱。

訂閱網址屬於敏感設定

訂閱 URL 往往包含可識別帳戶的權杖。不要將完整網址寫入公開記錄、截圖、程式碼儲存庫或共用 YAML。多裝置使用時，應直接在每台裝置的客戶端中儲存網址。

為什麼不建議長期複製產生的設定

產生的設定是某次訂閱更新的結果，其中節點位址、憑證參數、策略群組與規則都可能持續變更。直接複製可用於臨時復原，但不會自動取得後續更新。如果設定中還有 proxy-providers 或 rule-providers，複製時也要確保 Provider URL 仍然有效，並確認本機快取路徑能由新客戶端重新建立。

本機 YAML 遷移：先檢查，再修改裝置相關欄位

mihomo 對經典 Clash 設定具有高度相容性，常見的 proxies、proxy-groups、rules、proxy-providers 與 rule-providers 都能繼續使用。遷移時不應先大幅改寫語法，而應先保留原檔副本，直接匯入並讀取第一個明確錯誤。一次只修改一類欄位，更容易定位問題。

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

上例使用 7890 作為 Mixed 入站連接埠，9090 作為外部控制連接埠，DNS 監聽 1053。這些值可以在桌面系統使用，但不能機械式複製到所有裝置。Android 客戶端通常自行管理 VPN 入站與控制介面，手寫的監聽位址可能與客戶端內建服務衝突。

通常可以原樣保留的欄位

proxies 中由目前 mihomo 版本支援的節點協定參數。
proxy-groups 的 select、url-test、fallback 與 load-balance 結構。
rules 中的網域、IP、程序與規則集引用，但程序規則會受系統權限影響。
proxy-providers 與 rule-providers 的遠端 URL、更新間隔與健康檢查邏輯。
DNS 的 nameserver、fallback、nameserver-policy 與 fake-ip-filter 規則。

需要依裝置檢查或改寫的欄位

external-controller：建議限制在 127.0.0.1。舊設定若監聽 0.0.0.0:9090，會將控制介面暴露給區域網路。
secret：啟用遠端控制時應設定獨立值，並同步填入對應面板的連線設定。
interface-name：Windows、Linux 與 Android 的網路介面名稱不同，遷移後通常需要刪除舊值或重新選取。
routing-mark：主要用於 Linux 策略路由，複製到 Windows 或 Android 不具同等作用。
tun：不同平台支援的 stack、自動路由與 DNS 劫持方式存在差異。
Provider 的本機 path：Windows 路徑如 C:\Users\... 不能用於 Android，應改為相對路徑或交由客戶端管理。

不要整段跨平台複製 TUN 設定

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

桌面端的 TUN 通常需要管理員權限或系統服務支援；Android 端則依賴系統 VPN 介面。同一台 Android 裝置同一時間只能維持一個主要 VPN 接管工具。若手機上同時執行其他 VPN、企業工作資料 VPN 或本機防火牆，mihomo 客戶端可能無法建立介面。

遷移後若網頁能開啟但應用程式無法連網，可先在「設定」→「網路」中將 TUN stack 從 system 切換為 mixed 或 gvisor 進行比較，再檢查依應用程式代理清單。切換後應完全停止並重新啟動服務，避免舊虛擬介面狀態干擾結果。

桌面與 Android 多端保持一致的正確分層方式

多端一致不代表每台裝置都使用完全相同的一份 YAML。更合理的結構是將節點、遠端規則與策略群組作為共用層，將連接埠、TUN、區域網路存取、應用程式分流與系統權限作為裝置層。共用層由訂閱或 Provider 更新，裝置層則放在各客戶端的覆寫功能中。

適合跨裝置共用的內容

節點訂閱與 proxy-providers。
策略群組名稱與基本選擇邏輯。
網域規則、IP 規則與遠端 rule-providers。
DNS 上游與網域分流策略。
常用的直連、拒絕與代理規則。

應在每台裝置單獨維護的內容

桌面的 Mixed、HTTP、SOCKS 與控制連接埠。
是否允許區域網路裝置連線，以及監聽位址。
Windows 服務模式、開機啟動與 TUN 驅動程式狀態。
Android 依應用程式代理、VPN 常駐、電池最佳化與行動網路行為。
是否啟用 IPv6、MTU 數值與具體 TUN stack。

例如，桌面端可以保留 mixed-port: 7890，讓瀏覽器或開發工具手動連線至 127.0.0.1:7890；Android 端不需要其他應用程式填寫這個連接埠，而是由 VPN 介面統一接管。將桌面端連接埠設定視為「跨端必要項目」，容易造成 Android 端啟動衝突或產生無效設定。

策略群組選擇不會自動同步

即使桌面與 Android 使用相同訂閱，客戶端本機選取的節點通常也不會自動同步。桌面端將「節點選擇」設為某個香港節點，不會讓手機立即選取相同節點。若希望多端行為穩定，可讓主要策略群組引用 url-test 自動測速群組，並設定合理的測試網址、間隔與容差。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT

這裡的 interval: 300 表示每 300 秒測試一次，tolerance: 50 表示延遲差異不超過 50 ms 時減少頻繁切換。測試 URL 應保持穩定並回傳小體積回應。不同網路下的結果仍可能不同，因此手機使用行動網路時選取的節點不一定與桌面寬頻相同。

遷移後的驗證順序與常見故障

遷移完成後不要只檢查一個網頁。應依序從設定載入、DNS、規則命中、節點連通與系統接管五個層級進行驗證。如此可以判斷問題發生在設定解析、網域解析、策略選擇還是虛擬網卡。

設定載入：記錄中沒有 YAML 解析錯誤、重複連接埠或 Provider 下載失敗。
DNS 解析：網域請求能夠取得結果，記錄中沒有連續的 timeout、SERVFAIL 或循環查詢。
規則命中：造訪常用網站時，連線記錄顯示預期規則與策略群組。
節點連通：至少測試兩個不同地區的節點，排除單一節點故障。
系統接管：關閉系統代理或停止 VPN 後，網路路徑出現預期變化；重新啟動後恢復。

匯入成功，但所有節點都逾時

先檢查手機或電腦的系統時間，憑證握手對時間偏差相當敏感。接著更新訂閱，確認節點參數不是舊快取。若只有網域節點逾時而 IP 節點可用，應重點檢查 DNS。若記錄顯示 connection refused，可能是節點服務連接埠無法連線；顯示 i/o timeout 時，還需排查本機網路、路由與防火牆。

規則模式下部分應用程式無法連網

將模式暫時切換至 Global，僅用於定位問題。如果 Global 可用而 Rule 不可用，問題通常出在規則、策略群組或規則集更新。檢查最終 MATCH 指向的策略群組是否存在，再確認該群組已選取可用節點。完成診斷後應切回 Rule，而不是長期使用 Global 掩蓋規則錯誤。

Android 啟動後很快被系統停止

進入 Android「設定」→「應用程式」→對應客戶端→「電池」，選擇允許背景執行或不受限制；再檢查「設定」→「網路與網際網路」→「VPN」中的連線狀態。不同廠商的選單名稱可能有所差異。若啟用一律開啟的 VPN，還要確認沒有將另一個 VPN 應用程式設為相同角色。

訂閱更新後本機規則消失

這表示修改直接寫入訂閱產生的檔案中，而更新操作覆蓋了整份設定。應還原原訂閱，將裝置規則移至客戶端的覆寫、合併設定或獨立 Provider 中。共用訂閱負責更新節點，本機覆寫負責固定設定，分開這兩層後才能持續維護。

保留回退期間

新客戶端穩定執行數天後，再清理舊目錄。期間不要讓兩個客戶端同時啟用系統代理或 TUN。需要比對時，先完整停止其中一個客戶端，再啟動另一個，並確認系統代理位址與 VPN 圖示已切換。

遷移完成後的維護方式

遷移完成後，建議記錄客戶端版本、mihomo 核心版本、訂閱更新週期與關鍵覆寫內容。發生問題時，先比較最近一次客戶端更新、核心更新與訂閱更新的時間，通常可以快速縮小變更範圍。客戶端介面版本與核心版本是兩個概念，排查協定或規則行為時應優先記錄核心版本。

設定檔也應保持易讀。策略群組使用穩定名稱，規則依用途分段，Provider 採用明確的更新週期。修改前複製一份可正常啟動的版本；調整 DNS、TUN 或規則集時一次只修改一個模組，並在記錄中驗證結果。如此即使日後更換另一款 mihomo 客戶端，共用設定仍可繼續使用。

對大多數使用者而言，遷移路徑可以歸納為三步：儲存訂閱與舊 YAML、選擇仍在維護的 mihomo 客戶端，最後分別設定桌面與 Android 的裝置參數。訂閱負責更新節點，共用規則負責流量決策，本機覆寫負責處理系統差異。依照這個界線管理，比複製整份舊目錄更穩定，也更方便日後排錯。