名稱脈絡：原版 Clash、Premium 與 Meta 分支
先說結論：Clash Meta 與 mihomo 是同一分支先後使用的名稱，不應簡單視為兩個互不相關的核心；原版 Clash 則是這條技術路線的上游來源。選擇用戶端時，應確認實際執行的核心名稱與版本，而不是只看應用程式名稱是否含有 Clash。
另外也要區分 Clash Premium。許多舊教學把原版開源核心和 Premium 核心統稱為「Clash」，容易讓人誤以為「原版一定支援 TUN」或「舊設定都能直接移轉」。判斷功能時，至少要分清以下四個名稱。
- 原版 Clash 開源核心：通常指 Dreamacro/clash 專案的開源版本，提供本機代理入口、策略群組、規則比對和 DNS 等基礎功能。
- Clash Premium：原專案另行發布的閉源增強核心，曾提供 TUN、規則集和腳本等擴充功能；不能把這些功能全算在原版開源核心上。
- Clash Meta：社群以 Clash 為基礎發展出的分支，擴充了協定、規則與網路接管能力。
- mihomo：Clash Meta 後續採用的專案名稱；目前的文件、程式檔案和記錄中常見此名稱，部分用戶端或訂閱服務仍沿用 Meta 標籤。
用戶端與核心：介面版本不等於功能版本
用戶端負責管理訂閱、切換設定、控制系統代理及顯示記錄；核心則負責解析設定、建立連線、執行規則與處理 DNS。同一款用戶端可能內建特定核心，也可能允許切換核心，因此「用戶端已更新」不代表底層網路功能也已更新。
確認目前執行核心的三個線索
- 開啟用戶端的「關於」或「核心」頁面，分別記下用戶端版本和核心版本。不同用戶端的選單名稱可能不同，別把應用程式版本號當成核心版本號。
- 查看啟動記錄中的核心名稱、版本和設定載入結果。切換核心後應重新確認記錄，避免只更換檔案卻沒有重新啟動程序。
- 若已啟用本機控制介面，可呼叫
/version。回傳內容會因核心版本而異，請確認版本欄位與分支識別資訊。
例如，控制介面設定為 external-controller: 127.0.0.1:9090 時，可在本機執行以下命令。若設定了介面密鑰，須另外使用正確的驗證請求；出現 401 只表示驗證未通過，不代表核心不支援版本查詢。
curl http://127.0.0.1:9090/version9090 在此是控制介面連接埠，不是瀏覽器代理連接埠。控制介面可以修改執行狀態，應維持本機監聽；不要為了讓面板連線而直接改成可從公網存取的位址。
功能比較：協定、規則集、TUN 與 DNS
以下比較的是功能方向，並非每個歷史版本的完整清單。原版專案及其 Premium 發布線已停止原專案維護；mihomo 的具體欄位仍應以所用版本文件為準，尤其是新協定參數、DNS 選項和平台相關功能。
| 比較項目 | 原版開源 Clash | Clash Premium | Meta / mihomo |
|---|---|---|---|
| 常見代理協定 | 支援 Shadowsocks、VMess、Trojan 等協定，實際可用參數受版本限制。 | 沿用原版協定架構，不能視為支援 mihomo 的擴充協定。 | 擴充支援 VLESS、Hysteria2、TUIC 等協定，須確認版本與參數。 |
| 基礎規則 | 支援網域、IP 網段、GEOIP、MATCH 等常見規則。 | 支援基礎規則，並提供規則集等進階功能。 | 支援基礎規則、規則集，以及更多邏輯與比對條件。 |
| TUN 接管 | 不提供 Premium 式的內建 TUN 功能。 | 提供 TUN，實際支援情況受系統與發布版本限制。 | 提供 TUN；協定堆疊與路由選項依版本及平台而異。 |
| DNS 與 Fake-IP | 具備 DNS 與 Fake-IP 基礎功能。 | 具備 DNS 與 Fake-IP 功能。 | 進一步擴充 DNS 策略、上游選擇及解析控制功能。 |
| 移轉注意事項 | 無法辨識分支新增的協定與欄位。 | 不能假設 Premium 腳本可直接在 mihomo 執行。 | 許多基礎設定可沿用，但擴充欄位仍須逐項驗證。 |
協定名稱相同，也要確認傳輸與 TLS 參數
支援某種協定，不代表支援該協定的所有組合。例如，VLESS 是代理協定，REALITY 是相關的 TLS 安全設定功能，而 WebSocket 和 gRPC 則是傳輸方式。伺服器需要哪種組合，用戶端核心就必須支援相應欄位；只看到「支援 VLESS」不足以確認連線條件完整。
同樣地，Hysteria 與 Hysteria2 不是只改顯示名稱就能互通的設定。訂閱中出現 type: hysteria2 時，舊核心無法只把類型改成 hysteria 就取得相容性。應選用相符的核心與訂閱輸出格式，而不是逐一刪除報錯欄位。
規則相容性：基礎語法可沿用，擴充功能須重新確認
多數基礎分流仍採用「由上而下比對，符合後決定策略」的方式。DOMAIN-SUFFIX、IP-CIDR、MATCH 等規則相容性較高，但規則引用的策略群組必須存在，群組中的代理名稱也必須對應到實際資源。
以下規則片段用於說明順序，並非完整的訂閱設定。DIRECT 是內建的直連策略；實際使用時，應將需要代理的規則指向現有策略群組，不要直接照抄成全部直連。
rules:
- DOMAIN-SUFFIX,lan,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,DIRECT- 末尾兜底：
MATCH通常放在最後；若提早放置，後續規則就沒有比對機會。 - 規則集宣告：使用
RULE-SET時，應確認對應的rule-providers名稱、格式和行為類型，不能只複製規則引用行。 - 解析副作用：
no-resolve用來避免該條 IP 規則主動觸發網域解析，不代表整個連線過程都不需要 DNS。 - Premium 腳本：移轉含有
script的舊設定時，須確認目標核心是否支援相應機制，必要時改寫為規則與策略群組。
如果設定載入成功但分流結果不如預期，先確認目前是否為 rule 模式。全域模式不會依照一般規則清單分流，直連模式也無法用來驗證代理規則是否正確。
TUN 與 DNS：功能存在不代表已完成接管
系統代理與 TUN 處理的是不同流量入口
系統代理通常會讓遵循系統設定的應用程式連線至本機 HTTP 或 SOCKS 入口，例如 127.0.0.1:7890。這不保證所有程式都會經過代理，也不代表任意 UDP 流量都會進入核心。TUN 則透過虛擬網路介面和路由接管更多 IP 流量，適用範圍與實作方式都不同。
mihomo 支援 TUN，不代表在設定中寫入 enable: true 就一定會生效。還要確認用戶端具備所需服務權限、系統允許建立介面、路由設定正確，以及是否與其他 VPN 或透明代理衝突。排除問題時，先只保留一種網路接管方式，減少路由迴圈和 DNS 重複劫持。
Fake-IP 是 DNS 運作方式，不是代理協定
Fake-IP 會為網域配置對應位址，讓核心在連線階段找回原始網域並進行分流；常見設定範例使用 198.18.0.1/16 位址池。這不代表目標網站真的位於該位址，也不能據此判斷節點所在地區。
以下片段僅展示相關欄位。1053 是自訂的本機 DNS 監聽連接埠，不會自動取代系統通常使用的 53 連接埠；系統 DNS 如何導入核心，須搭配用戶端接管、TUN DNS 劫持或其他明確設定。
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16DNS 設定欄位與接管順序可參閱完整手冊中的 DNS 說明；Fake-IP 的概念範圍請見術語手冊。
移轉檢查：從舊版 Clash 設定切換至 mihomo
移轉的重點不是把設定檔中的 Clash 字樣換成 mihomo，而是確認協定、規則與系統接管都能正常運作。建議依照以下順序操作，每一步確認無誤後再啟用下一項功能。
- 保留原始設定：備份訂閱網址、目前的 YAML、本機覆寫和策略群組選擇。訂閱 URL 可能含有存取憑證，不應放進公開記錄或截圖。
- 確認訂閱目標：如果服務提供者區分 Clash 與 Meta 輸出格式，先確認所選格式包含目標核心可辨識的協定和欄位。Base64 節點清單無法只靠更改副檔名就變成完整的 YAML 設定。
- 檢查設定語法：使用目標核心測試設定；常見命令為
mihomo -t -f config.yaml。Windows 可使用mihomo.exe -t -f config.yaml，實際程式路徑依安裝位置而定。 - 先測試本機代理：暫時關閉 TUN，確認本機入口連接埠、策略群組和代理連線都正常，再測試規則模式。
- 再啟用網路接管：依照權限需求開啟 TUN，檢查記錄中的介面、路由與 DNS 狀態，並分別測試瀏覽器和不遵循系統代理設定的應用程式。
- 最後恢復自動更新：確認訂閱更新一次後，本機覆寫仍然生效。直接修改遠端設定檔的內容，可能會在後續更新時被覆蓋。
例如，設定使用 mixed-port: 7890 時，可透過以下命令確認 HTTPS 請求是否經過此本機 HTTP 代理入口。命令成功只能證明這個入口和目標請求可用，無法證明所有應用程式、UDP 或 TUN 都正常。
curl -I -x http://127.0.0.1:7890 https://example.com若提示連接埠已被占用，請檢查是否仍有舊核心或其他用戶端正在執行；若提示代理類型未知，優先檢查核心與訂閱格式；若語法檢查通過但連線逾時，再檢查伺服器參數、網路連線和 DNS。將這三類問題分開處理，通常比不斷更換設定更容易找出原因。
選型結論：依訂閱協定與執行平台決定
- 需要新協定或擴充規則：優先選擇明確整合並持續維護 mihomo 的用戶端，同時確認內建核心版本符合設定需求。
- 只使用基礎協定與網域分流：基礎功能不一定需要複雜設定，但新部署仍應優先考量維護狀態與系統相容性，不要只因熟悉舊教學就固定使用舊核心。
- 需要 TUN：除了確認核心支援，也要檢查用戶端的權限管理、系統架構和路由處理能力；手機尤其應以應用程式實際使用的核心及系統 VPN 介面實作為準。
- 移轉 Premium 設定：優先重新檢查腳本、規則集與 TUN 欄位，不要把「能夠匯入」當成「所有行為都一致」。
最後，請分開管理三種更新：訂閱更新會更動代理資源與規則內容，核心更新會改變協定和網路功能，用戶端更新則會影響介面與整合方式。遇到不支援的欄位，單純重新整理訂閱未必有效；伺服器位址失效時，只更換核心也無法解決。先確認問題出在哪一層，再採取相應措施。