Clash 用戶端停止維護後：設定匯出、核心替換與替代方案

先判斷停止維護影響的是哪一層

Clash 相關專案大致分三層：核心、圖形化用戶端、設定與規則集。核心負責協定解析、DNS 與 TUN 路由；用戶端負責介面、訂閱管理與系統代理開關；設定層是 profile 檔案與規則集檔案。三層之間透過 YAML 設定與本機連接埠通訊，只要介面不變，任何一層都可以單獨替換。

先確認停止維護發生在哪一層，再決定要不要動設定。判斷依據是 release 標籤的發布時間與預設分支最後一次提交時間，與 star 數、下載量無關。

停止維護層級與處置方式
層級	典型訊號	實際影響	處置方式
核心	儲存庫已封存，最後一個 release 距今超過 12 個月；原版 Clash 停在 v1.18.0（2023 年 8 月）	新協定與 DNS 功能不再合併，規則集新格式無法解析	更換核心，profile 大多可沿用
用戶端	超過 9 個月沒有新 release，issue 長期無人回覆	介面與訂閱管理停留在舊版本，TUN 可能與新版系統不相容	更換用戶端，訂閱與 profile 可原樣匯入
規則集	規則儲存庫 6 個月沒有提交	網域庫與 IP 庫逐漸過期，分流準確率下降	更換規則來源，修改 rule-providers 的 url

在用戶端「設定」→「版本資訊」或「關於」中記錄兩個版本號：介面版本與核心版本，格式如 v1.18.0、v1.19.5。
開啟對應儲存庫的 releases 頁面，核對最新 tag 的日期，確認是否真的停止更新。
開啟 profile 目錄，確認設定來自訂閱連結還是本機檔案。前者可以重建，後者必須先備份。

只有用戶端層停止維護時，改動最小

保留現有 profile 與規則集，直接換一個仍在維護的介面即可。核心、訂閱、規則集都不需要動，移轉時間通常在十分鐘以內。

移轉前先匯出設定資產

設定資產分三類：訂閱連結、本機 profile 檔案、用戶端裡手動改過的項目（連接埠、TUN 開關、開機自動啟動、規則覆寫）。前兩類可以完整匯出，第三類只能逐項記錄。匯出動作要在關閉代理的狀態下進行，避免中途斷網導致訂閱更新失敗。

各平台 profile 預設目錄

profile 與設定檔位置
平台	用戶端設定目錄	核心預設目錄
Windows	`%APPDATA%\io.github.clash-verge-rev.clash-verge-rev\profiles\`，舊版 Verge 在 `%APPDATA%\clash-verge\`	`%USERPROFILE%\.config\clash\`
macOS	`~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/`	`~/.config/mihomo/`
Linux	`~/.config/io.github.clash-verge-rev.clash-verge-rev/profiles/`	`~/.config/mihomo/` 或 `/etc/mihomo/`
Android	應用程式內「設定檔」選單的匯出項目，匯出檔案通常會放在 `/sdcard/Download/`	應用程式私有目錄，未 root 無法直接讀取

匯出步驟

關閉系統代理與 TUN：「設定」→「系統代理」關閉，「設定」→「TUN 模式」關閉。
在「訂閱」頁對目標 profile 按右鍵 →「複製訂閱連結」，貼到本機文字檔儲存。
本機檔案型 profile：把整個 profiles 目錄複製到備份磁碟，包含 providers 子目錄。
記錄連接埠：混合連接埠 7890、控制連接埠 127.0.0.1:9090、DNS 監聽 1053。
記錄規則集來源：rule-providers 中每一項的 url、interval 與 path。

一份最小可移轉設定

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

proxy-providers:
  main:
    type: http
    url: "https://sub.example.com/link/8f3c1a2b?flag=meta"
    interval: 3600
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

其中 unified-delay 與 tcp-concurrent 是 mihomo 的欄位，原版 Clash 讀到會直接回報解析錯誤。移轉時依目標核心版本決定保留或刪除，其餘欄位兩邊通用。

核心替換：從原版 Clash 到 mihomo

原版 Clash 核心停在 v1.18.0；Clash.Meta 分支在 2024 年更名為 mihomo，主線推進到 v1.19 系列，TUN 堆疊、DNS 與規則集格式仍在更新。兩者大部分設定欄位同名，差異集中在近兩年新增的能力上。

欄位相容性對照
設定欄位	原版 Clash v1.18.0	mihomo v1.19.x	移轉動作
`mixed-port`	支援	支援	無需改動
`tun.stack`	支援 system / gvisor	新增 mixed 取值	可維持原值
`sniffer`	不支援	支援	可新增，用於還原被 fake-ip 覆蓋的網域
`rule-providers` 的 `format: mrs`	不支援	支援	想降低記憶體用量可改用 mrs
`geodata-mode`、`geox-url`	不支援	支援	需要 geo 檔案時補上
`proxy-groups` 的 `lazy`	不支援	支援	選用，減少閒置時的健康檢查
`sub-rule`（1.19 新增）	不支援	支援	舊核心解析會出錯

反向相容基本成立：mihomo 能直接讀取原版 Clash 的 profile，反過來則會因為多出的欄位解析失敗。所以移轉方向只有舊核心到 mihomo 這一條，不能反著走。

Linux 下替換核心的命令列

# 停掉舊核心服務
sudo systemctl stop clash

# 下載並安裝 mihomo 核心（amd64 範例）
curl -LO https://github.com/MetaCubeX/mihomo/releases/download/v1.19.5/mihomo-linux-amd64-v1.19.5.gz
gunzip mihomo-linux-amd64-v1.19.5.gz
sudo install -m 0755 mihomo-linux-amd64-v1.19.5 /usr/local/bin/mihomo

# 確認替換生效
mihomo -v

# 以舊設定前景試跑，觀察是否有欄位解析錯誤
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

試跑時保持前景輸出，確認日誌裡沒有 parse error 一類的欄位錯誤後再結束，交給 systemd 託管。非 root 使用者執行需要額外授予網路能力：

[Unit]
Description=mihomo
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
LimitNOFILE=1048576
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

不要在同一個路徑反覆覆蓋不同核心的二進位檔

舊核心的行程可能仍在背景執行並佔用 9090 連接埠，替換後會表現為「設定沒生效」。先確認行程已結束，再覆蓋二進位檔。

依平台選擇替代用戶端

選擇替代用戶端要看三個硬指標：是否內建核心下載與更新通道、是否支援直接匯入 profile 目錄、是否同時提供系統代理與 TUN 兩種模式。三項都滿足的介面，移轉成本最低，因為訂閱與連接埠習慣都能照搬。

各平台可選用戶端
平台	可選用戶端	核心	設定匯入方式
Windows	Clash Verge Rev、FlClash、Clash Nyanpasu	mihomo	貼上訂閱連結，或把 yaml 拖進視窗
macOS	Clash Verge Rev、FlClash、Mihomo Party	mihomo	同上；首次開啟 TUN 需在系統設定中批准
Android	FlClash、Clash Meta for Android	mihomo	在應用程式內貼上訂閱，或從本機檔案匯入
iOS	App Store 中提供 Network Extension 的用戶端，如 Shadowrocket、Stash、Loon	各自核心	多數只接受訂閱連結，不解析完整 yaml
Linux	Clash Verge Rev（AppImage / deb / rpm）、mihomo + systemd	mihomo	設定檔直接放到 /etc/mihomo

iOS 端要注意地區差異：這類用戶端在中國大陸的 App Store 無法下載，需要切換到其他地區的帳號。同時它們多數不解析完整 yaml，只接受訂閱連結，本機手寫的規則要提前整理到訂閱端，否則移轉後會缺規則。

從舊用戶端搬移設定的順序

先安裝新用戶端，暫時不要解除安裝舊的，方便隨時對照。
匯入訂閱連結，等 profile 產生完成、節點清單出現。
對照備份記錄逐項改回：混合連接埠、控制連接埠、TUN 堆疊類型、開機自動啟動、系統代理模式。
新用戶端連線正常後，再停用舊用戶端並解除安裝其背景服務。Windows 的服務模式、macOS 的特權 helper 都要單獨移除，否則會殘留監聽連接埠。

移轉後的驗收清單

以下十項依序做一遍，能涵蓋絕大多數移轉遺留問題。指令中的連接埠以預設值為準，改過連接埠就替換成實際值。

核心版本：curl -s http://127.0.0.1:9090/version，回傳的 version 欄位應與安裝的 tag 一致。
代理鏈路：curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204，回傳 HTTP/2 204 表示鏈路暢通。
DNS 解析：Windows 用 nslookup www.google.com 127.0.0.1，macOS 與 Linux 用 dig @127.0.0.1 -p 1053 www.google.com，回傳 198.18.0.0/16 網段位址表示 fake-ip 生效。
規則命中：開啟介面的「連線」頁，先連線到台灣本地網站，確認是否走 DIRECT；再連線到境外網站，確認是否進入代理群組。
TUN 路由：Windows 執行 route print -4 檢查 TUN 網路卡與 198.18.0.0 網段；Linux 執行 ip route show table all | grep 198.18。
連接埠佔用：Windows 用 netstat -ano | findstr :9090，macOS 與 Linux 用 lsof -i :9090，確認只有一個行程在監聽。
訂閱更新：手動觸發一次更新，日誌中不應出現 403、404 或 TLS 握手失敗。
規則集落地：檢查規則集目錄下的檔案大小不為 0，修改時間是剛剛。
開機自動啟動：重新啟動系統一次，確認用戶端會自動啟動，系統代理狀態與重新啟動前一致。
退回路徑：中斷代理節點，確認 DIRECT 規則下的網站仍可連線，表示分流沒有全部壓到代理群組。

常見移轉故障與處理

訂閱更新回傳 403 或 404

多半是 User-Agent 不符。部分伺服器端會依 UA 回傳不同格式，新核心的預設 UA 與舊用戶端不一致時，面板會直接拒絕。先在用戶端的訂閱設定裡找 UA 下拉選項，切到 clash 再試；其次是連結本身過期，回面板重新複製一份。

規則集下載失敗

geodata-mode: true 時需要 geoip.dat、geosite.dat 或對應的 mmdb 檔案，mihomo 會嘗試自動下載到工作目錄，網路受限時會失敗。手動把檔案放進工作目錄，或在 geox-url 裡換成可存取的位址。

TUN 模式無法啟動

Windows：需要先安裝服務模式，首次安裝會一併釋放 wintun.dll；裝過舊版服務的，先在設定裡解除安裝再重裝。
macOS：首次開啟要在系統設定裡批准網路擴充功能或特權 helper，一旦拒絕過，只能在設定裡重置授權後重來。
Linux：非 root 執行要給二進位檔加上網路能力，sudo setcap cap_net_admin,cap_net_bind_service+ep /usr/local/bin/mihomo。

啟動後立即結束，或設定未生效

先確認 9090 是否被舊行程佔用，再檢查設定檔的縮排與編碼：YAML 用 Tab 縮排會直接解析失敗，檔案要存成 UTF-8 無 BOM。把日誌等級調到 log-level: debug，日誌會給出確切行號，比逐行比對設定檔快得多。

移轉的本質是把三樣東西搬進新殼子：訂閱連結、profile 檔案、連接埠與模式習慣。這三樣在手，用戶端換幾次都不影響日常使用；反過來，只記得介面上的開關位置，下次遇到停止維護還得從頭摸一遍。