Clash 客戶端停止更新後該用什麼：FlClash 與 Clash Verge Rev 遷移方案比較

先確認停止更新的是客戶端，不是設定格式

原版 Clash 核心與 Clash for Windows 已停止維護。Clash for Windows 常見的最後版本是 v0.20.39，舊安裝包仍可能啟動，但繼續使用會遇到三個實際問題：新系統相容性問題不會再修復、新版規則能力無法加入，以及訂閱服務逐步轉向 mihomo 後可能出現欄位無法識別。遷移的重點不是尋找介面完全相同的複製品，而是將訂閱、覆寫規則、代理模式與系統接管方式平穩轉移到仍在維護的客戶端。

目前常用的替代方案主要採用 mihomo 核心。mihomo 延續 Clash 設定體系，並加入規則集、程序比對、TUN、流量嗅探與更完整的 DNS 設定。大部分標準 YAML 設定可以繼續使用，但客戶端自身的介面設定無法直接互通。例如 Clash for Windows 的視窗狀態、啟動項目與 Mixin 腳本，不會隨訂閱網址自動遷移。

遷移前要分清四類資料

• 訂閱網址：服務端提供的 URL，通常可在舊客戶端的 Profiles 或設定頁面找到。
• 設定檔：包含 proxies、proxy-groups、rules、dns 等欄位的 YAML 檔案。
• 客戶端設定：開機啟動、系統代理、TUN、區域網路存取與主題等本機選項。
• 覆寫內容：舊版 Mixin、Parsers、腳本或手動追加的規則，需要另外重建。

如果平時只貼上訂閱連結並選擇節點，遷移通常只需十分鐘左右。如果修改過 DNS、規則順序或連接埠，則應先匯出目前生效的設定，再逐項還原。訂閱服務每次更新都可能覆蓋本機檔案，因此自訂內容更適合放進新客戶端提供的覆寫功能，而不是直接修改訂閱產生的 YAML。

FlClash 與 Clash Verge Rev 該怎麼選

兩者都能執行 mihomo 設定，但產品定位不同。FlClash 支援 Windows、macOS、Linux 與 Android，桌面版和行動版的介面與操作流程較為一致。Clash Verge Rev 主要面向 Windows、macOS 與 Linux 桌面環境，設定管理、系統匣操作、系統服務與桌面 TUN 工作流程更集中。

適合優先選擇 FlClash 的情況

• 電腦和 Android 手機都要使用 Clash 設定，並希望選單結構相近。
• 主要操作是加入訂閱、切換節點、查看連線，以及啟用或停用系統代理。
• 需要在觸控裝置上管理策略群組，不想維護兩套完全不同的操作習慣。
• 使用本機 YAML 檔案，希望直接匯入後查看錯誤提示與規則比對結果。

適合優先選擇 Clash Verge Rev 的情況

• 主要裝置是 Windows、macOS 或 Linux 桌上型電腦。
• 需要頻繁切換多個訂閱，並統一加入 DNS、規則或代理群組覆寫。
• 希望透過系統匣快速切換系統代理、TUN 模式與代理模式。
• 需要讓不讀取系統代理的軟體經由 TUN 連線，並希望使用系統服務來減少需要權限操作的次數。

選擇時不必只看介面截圖。更可靠的判斷標準是裝置平台、是否依賴 TUN、是否維護自訂規則，以及訂閱數量。單台 Windows 電腦搭配一個訂閱，兩者都能完成任務；涉及 Android 時優先考慮 FlClash；涉及多份桌面設定與複雜覆寫時，Clash Verge Rev 的管理流程通常更直接。

從 Clash for Windows 遷移訂閱與設定

第一步：儲存訂閱網址與本機 YAML

開啟 Clash for Windows，進入 Profiles 頁面。記下仍在使用的訂閱名稱、更新時間與 URL。如果介面沒有直接顯示完整網址，可檢查設定檔來源，或登入訂閱服務的管理頁面重新複製。接著開啟設定所在目錄，將目前使用的 YAML 檔案複製到獨立資料夾。

只儲存 config.yaml 還不夠。Clash for Windows 可能會將訂閱檔案放在 profiles 目錄，並透過索引記錄目前的選擇。如果有 Mixin 或 Parser，也要將相關文字另外複製成純文字檔案。遷移時應先理解這些內容再重建，不建議將整個舊資料目錄覆蓋到新客戶端目錄。

1. 停用自動更新設定，避免備份過程中訂閱檔案被重新整理。
2. 複製訂閱 URL，並為每個網址標註用途，例如「日常」、「測試」、「備用」。
3. 匯出或複製目前生效的 YAML。
4. 抄下 General 頁面中的連接埠與開關狀態。
5. 儲存自訂 Mixin、Parser 與手寫規則。

第二步：在新客戶端加入訂閱

安裝新客戶端後，先只加入一個主要訂閱。在 FlClash 中進入「設定」→「加入」，選擇 URL 類型，貼上訂閱網址並執行更新。在 Clash Verge Rev 中進入「訂閱」→「新增」，填寫名稱與訂閱 URL，儲存後點選更新。不同版本的選單名稱可能略有調整，但都應選擇遠端訂閱，而不是將 URL 當成本機 YAML 內容貼上。

更新成功後，先檢查策略群組是否完整，再選擇一個節點進行延遲測試。延遲結果只能反映探測目標的回應時間，不能單獨證明所有網站都能存取。建議分別開啟一個直連網站與一個需要代理的目標，再查看「連線」頁面中的規則、策略群組與實際出站節點。

第三步：核對連接埠，避免重複監聽

舊版 Clash 設定經常使用 HTTP 連接埠 7890、SOCKS5 連接埠 7891 和外部控制連接埠 9090。mihomo 設定也常使用 mixed-port: 7890，讓 HTTP 與 SOCKS 共用同一個入口。兩套客戶端同時執行時，如果都監聽 7890，就會出現「address already in use」、「連接埠已被使用」或啟用系統代理後無法連線。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

遷移測試期間應徹底退出舊客戶端，確認系統匣中不再執行後，再啟動新客戶端。若必須並行比較，可暫時將其中一套改為 7892，但系統代理只能指向目前要測試的連接埠。測試結束後恢復統一連接埠，避免瀏覽器、終端機與開發工具各自留下不同的代理網址。

自訂規則、代理群組與 DNS 要怎麼遷移

規則遷移的關鍵是維持順序。Clash 與 mihomo 都會由上到下比對規則，命中後停止繼續尋找。將特定網域規則放在寬泛的 GEOIP 或 MATCH 後面，即使語法正確也不會生效。遷移時先搬移精確規則，再搬移規則集引用，最後核對兜底規則。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

代理群組名稱必須相符

規則的最後一項引用的是策略名稱。上例中的 Proxy 必須存在於 proxy-groups。如果訂閱實際使用「節點選擇」或「代理」，直接複製規則會回報找不到策略群組，或在載入階段失敗。中文群組名稱、英文群組名稱與大小寫都必須完全一致。

訂閱更新後節點名稱可能改變，因此自建代理群組應優先引用其他穩定的策略群組，或使用客戶端支援的覆寫機制。不要將數十個節點名稱手動寫入長期規則檔案，否則服務端改名後就得逐條維護。

舊版 Mixin 不應整段照搬

Clash for Windows 的 Mixin 可以透過 JavaScript 修改設定，Parser 也可能在訂閱進入核心前進行轉換。新客戶端未必支援相同的腳本介面。遷移時先判斷舊邏輯實際做了什麼：加入規則、修改 DNS、變更連接埠，還是插入代理群組。能以標準 YAML 表達的內容，應改寫為客戶端的全域擴充、合併覆寫或腳本覆寫。

例如原本的 Mixin 只將日誌層級改為 info 並啟用區域網路存取，就沒有必要繼續保留腳本。直接在新客戶端「設定」→「參數設定」中調整對應選項會更清楚。若要開放區域網路，還應限制監聽位址並檢查系統防火牆，避免將控制連接埠暴露在不受信任的網路中。

DNS 先使用訂閱預設值

DNS 是遷移中最容易出現「節點可用但網頁打不開」問題的部分。舊設定可能使用 fake-ip，新客戶端也可能預設啟用流量嗅探。這些設定與系統安全軟體、區域網路網域、虛擬機器網路之間可能產生差異。首次執行時先使用訂閱提供的 DNS 區段，確認代理運作正常後，再恢復自訂 nameserver、fallback 或 fake-ip-filter。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

198.18.0.0/15 屬於基準測試用途的位址範圍，常被 Fake-IP 模式用於本機映射。看到連線記錄指向這段位址，不代表遠端網站實際使用這個 IP。出現區域網路裝置、印表機或特定應用程式解析異常時，應先檢查網域是否需要加入 Fake-IP 排除清單，而不是立即關閉整套 DNS 模組。

系統代理與 TUN 的遷移順序

系統代理適合瀏覽器、聊天工具，以及明確讀取作業系統代理設定的軟體。TUN 模式會在網路層接管更多流量，適合遊戲啟動器、命令列程式、部分商店應用程式，以及不讀取系統代理的軟體。兩者不是速度檔位，也不是必須同時啟用的兩個開關。

先使用系統代理完成基礎驗證

1. 退出舊版 Clash 客戶端，關閉殘留的系統代理。
2. 啟動新客戶端並選擇有效節點。
3. 將代理模式設為「規則」。
4. 啟用「系統代理」，保持 TUN 關閉。
5. 存取直連與代理目標，並在連線清單中檢查命中的規則。

這一步成功後，表示訂閱、連接埠與基本規則正常。如果一開始就啟用 TUN，故障範圍會同時包含虛擬網卡、路由、DNS 與權限，不利於定位。Windows 上還要檢查「設定」→「網路和網際網路」→「代理」，確認手動代理位址指向 127.0.0.1 與目前的監聽連接埠。

需要全域接管時再啟用 TUN

Clash Verge Rev 桌面版通常會要求安裝或啟用服務元件，FlClash 首次啟用 TUN 也會觸發系統授權。Windows 應允許網路元件完成安裝；macOS 需要在「系統設定」→「網路」或隱私權與安全性相關提示中核准；Linux 則可能需要設定權限與路由能力。完成授權後重新啟動客戶端，再啟用 TUN。

實際觀察可用連線建立時間，而不是只盯著延遲數字。以同一網路、同一節點為例，系統代理下網頁首次連線約 180 毫秒，TUN 下約 190 至 230 毫秒都屬於常見波動；如果啟用 TUN 後持續超過 2 秒，或 DNS 查詢反覆逾時，就應檢查 DNS 劫持、IPv6、MTU 與其他虛擬網卡，而不是直接更換全部規則。

遷移失敗時依現象排查

訂閱更新失敗或回傳空白設定

• 在訂閱服務後台重新複製 URL，避免網址末尾混入空格。
• 確認訂閱尚未過期，並檢查服務端是否限制更新時間或請求頻率。
• 舊客戶端能更新、新客戶端不能更新時，比較 User-Agent 要求與網路路徑。
• 先關閉覆寫；原始訂閱可以載入後，再逐項恢復附加設定。

設定提示 YAML 解析錯誤

YAML 使用空格表示階層，Tab、全形冒號與錯誤縮排都會造成解析失敗。即使錯誤指向第 48 行，問題也可能來自第 47 行未閉合的引號。將自訂內容縮減到最小區段，再逐段加入，比反覆點選更新更有效。節點名稱包含冒號、井號或特殊符號時，應使用引號包住。

系統代理已啟用，但瀏覽器仍直接連線

• 檢查瀏覽器是否安裝獨立的代理擴充功能，擴充功能可能會覆蓋系統設定。
• 確認監聽位址是 127.0.0.1，連接埠與系統代理一致。
• 查看連線清單；沒有新連線通常表示流量沒有進入客戶端。
• 命中 DIRECT 則檢查規則順序，命中代理但連線失敗則檢查節點。

啟用 TUN 後無法解析網域

先關閉 TUN，確認系統代理模式恢復正常。然後檢查 DNS 是否啟用、nameserver 是否可達、Fake-IP 排除項目是否涵蓋區域網路網域。Windows 可在終端機執行 ipconfig /flushdns 清除系統快取；macOS 可先切換一次網路連線，再重新測試。不要在同一次排查中同時更改 DNS、MTU、IPv6 與規則，否則無法判斷哪項調整有效。

遷移完成後的驗收清單

完成遷移不代表看到節點顯示綠色就算成功。應從設定更新、規則命中、系統接管與重新啟動後恢復四個方面驗收。以下項目全部通過後，再解除安裝舊客戶端並刪除不再使用的設定副本。

• 訂閱可以手動更新，更新後代理群組與節點正常顯示。
• 在規則模式下，直連目標命中 DIRECT，代理目標命中預期的策略群組。
• 關閉系統代理後流量恢復直連，啟用後進入新客戶端。
• 需要 TUN 的應用程式可以建立連線，區域網路與印表機裝置仍可存取。
• 重新啟動系統後，開機啟動與自動連線行為符合預期。
• 訂閱更新不會覆蓋本機覆寫內容，手寫規則仍維持正確順序。
• 舊客戶端不再常駐系統匣，也沒有繼續監聽 7890 或 9090 連接埠。

對多數使用者而言，最穩妥的流程是：備份舊資料，安裝仍在維護的 mihomo 客戶端，只匯入主要訂閱，使用系統代理驗證，再恢復規則與 DNS，最後依需求啟用 TUN。FlClash 更適合同時涵蓋桌面與 Android 的使用方式；Clash Verge Rev 更適合以桌面設定管理與系統整合為主的環境。選定一套後保持設定來源清楚，比長期並行執行多個客戶端更容易維護。