mihomo 核心功能解析：與原版 Clash 的規則、協定及運作能力差異

mihomo 與原版 Clash 的相容性

原版 Clash 建立了一套易於組合的設定結構：在 proxies 中定義節點，在 proxy-groups 中組織手動選擇、自動測試或故障轉移策略，再以 rules 依序將連線交給策略群組。mihomo 延續了這項基本結構，因此常見的 Clash YAML 設定通常可以作為遷移起點。像是 DOMAIN-SUFFIX、DOMAIN、IP-CIDR、GEOIP、MATCH 等基礎規則，以及 select、url-test、fallback 等常見策略群組，在兩類設定中都有相近的意義。

這種相容性不代表兩者的設定欄位完全相同。mihomo 新增的欄位、代理類型或規則語法，原版 Clash 不一定能識別；反過來，舊設定中遺留的欄位也可能已被調整、淘汰，或只在特定客戶端的預處理層生效。尤其是訂閱轉換服務產生的設定，可能混合核心欄位、客戶端專用欄位與範本變數。遷移時應檢查最後交給核心的 YAML，而不是只看訂閱網址的名稱。

設定相容性可分為三個層次

1. 語法可讀取：YAML 的縮排、清單與欄位名稱能通過解析，核心可以啟動。
2. 物件可識別：節點協定、策略群組類型、規則類型與 DNS 欄位受到目前核心版本支援。
3. 行為符合預期：規則命中順序、DNS 回傳結果、測速方式與流量接管範圍，均符合原設定目標。

僅顯示「設定匯入成功」，通常只涵蓋前兩個層次的一部分。真正的相容性檢查還要觀察代理群組是否完整、規則提供器是否更新成功、DNS 是否正在監聽、記錄中是否出現未知欄位，以及目標網站最後命中了哪個策略。

規則系統差異：從順序比對到條件組合

Clash 與 mihomo 的規則處理都遵循一項關鍵原則：規則由上而下檢查，第一個命中的規則決定連線去向。因此，規則數量多不一定代表分流準確，順序與條件範圍更重要。將寬泛的網域後綴規則放在具體規則前面，可能導致後續規則永遠沒有執行機會；若將 MATCH 提前，便會直接接管其餘流量。

mihomo 在基礎規則模型上提供更豐富的比對維度。除了網域、目標 IP、來源 IP、連接埠與程序等常見條件外，受支援的版本還能使用邏輯組合，透過 AND、OR、NOT 關係組織多個條件。如此便能表達「某個程序存取特定連接埠時採用指定策略」、「某個網域集合且協定類型符合條件時使用代理」等更細緻的需求。實際規則名稱與巢狀寫法可能隨版本演進，撰寫前應核對目前版本文件與啟動記錄。

基礎規則與擴充規則的重點

• 網域規則：DOMAIN 精確比對完整網域，DOMAIN-SUFFIX 比對某個網域及其子網域，適合穩定的網站分類。
• IP 規則：IP-CIDR 與 IP-CIDR6 依據目標位址範圍判斷。若要避免因這條規則觸發額外 DNS 解析，可依規則支援情況使用相應選項。
• 地理資料規則：GEOIP 依 IP 資料庫分類；mihomo 也常搭配 GEOSITE 或規則集合處理網域分類。結果品質取決於資料檔案來源與更新時間。
• 程序規則：可依程序名稱或路徑進行分流，適用於桌面系統，但權限、作業系統與接管方式都會影響識別結果。
• 入站與網路條件：可依據入站來源、TCP 或 UDP、來源位址及連接埠等資訊細分策略，適合閘道或多入口部署。
• 規則提供器：透過 rule-providers 將大型規則集拆出主設定，並按指定週期更新，再由 RULE-SET 引用。

規則提供器是大型設定中非常實用的結構，但並非「越多越好」。多個規則集可能涵蓋相同網域，更新失敗也可能讓分流結果與預期不同。建議將必須直連的區域網路與系統服務放在較前方，依優先順序排列業務明確的規則集，並在最後保留清楚的兜底策略。對於來源不明、長期未更新或容量異常龐大的規則集，應先確認其內容格式與行為。

rule-providers:
  service-set:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-set.yaml
    url: https://example.com/rules/service-set.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,service-set,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這段結構展示的是規則組織方式，不代表適合直接複製到所有環境。遠端位址、策略群組名稱、規則集格式與儲存路徑都必須與實際設定相符。特別是 behavior 與下載檔案的內容格式必須一致，否則規則提供器可能載入失敗。客戶端顯示更新成功後，還應查看核心記錄是否已完成解析。

協定支援差異：能匯入節點不代表能夠連線

原版 Clash 支援一批傳統代理協定，並透過統一的策略群組完成節點切換。mihomo 在此基礎上擴充更多現代協定與傳輸組合，常見包括 VLESS、Reality、Hysteria2、TUIC、WireGuard，以及不同協定下的 TLS、WebSocket、gRPC 等參數組合。實際可用範圍取決於 mihomo 版本、編譯目標與客戶端整合進度，不能只因訂閱中出現某種連結格式，就判定一定可用。

訂閱匯入通常包含兩個階段：客戶端或訂閱服務先將節點連結轉換為 YAML 物件，接著由核心讀取物件並建立連線。某個節點沒有出現在代理群組中，可能是轉換階段未能識別；節點已顯示但連線報錯，則更可能是核心參數、伺服器端設定、網路環境或系統時間問題。將這兩個階段分開檢查，比反覆重新匯入訂閱更有效。

協定遷移時需要核對的參數

• 伺服器位址、連接埠、使用者識別碼或驗證資訊是否完整。
• TLS 是否啟用，伺服器名稱、ALPN 與憑證相關參數是否符合伺服器端設定。
• 傳輸層是 TCP、UDP、WebSocket、gRPC 或其他形式，路徑與服務名稱是否一致。
• Reality 情境中的公鑰、短識別碼與指紋參數是否正確。
• Hysteria2、TUIC 等基於 UDP 的協定是否受到目前網路、路由器或防火牆限制。
• 策略群組是否引用對應節點，節點名稱變更後是否產生失效引用。

測速結果也不能完全代表實際存取體驗。url-test 通常使用指定 URL 測量回應時間，並依間隔重新測試；它能協助選出可連線且延遲較低的節點，卻無法涵蓋影片傳輸量、長連線穩定性、UDP 品質與目標網站本身的限制。若所有節點測速正常但特定應用程式無法使用，應繼續檢查規則命中、DNS 結果、IPv6 路徑，以及應用程式是否繞過系統代理。

從原版 Clash 切換至 mihomo 的主要好處之一，是能在同一套策略體系中處理更多節點類型。但協定越多，也代表設定欄位越複雜。對訂閱使用者而言，應優先請服務提供者產生對應 mihomo 的設定格式；手動維護設定的使用者，則應先以單一節點與簡單策略群組驗證連線，再逐步加入自動選擇、負載平衡與複雜規則。

運作能力差異：DNS、嗅探與 TUN 模式

核心的運作能力決定流量如何進入代理系統，以及規則比對時能取得哪些資訊。系統代理通常只影響遵循作業系統代理設定的應用程式；TUN 模式則透過虛擬網路介面接管更廣泛的 IP 流量，適合不讀取系統代理設定的程式、部分遊戲或需要統一處理的環境。mihomo 為 TUN、DNS 與流量識別提供較多設定選項，但也更依賴系統權限與正確的網路參數。

TUN 模式的關鍵重點

啟用 TUN 後，客戶端通常需要建立虛擬網卡、調整路由或啟用自動重新導向功能。不同作業系統的實作細節各異，客戶端可能提供 system、gVisor 或 mixed 等協定堆疊選項，實際可用項目以目前核心與客戶端為準。某種協定堆疊在一台裝置上運作穩定，不代表在所有系統版本、虛擬機器或企業安全環境中都會有相同結果。

TUN 模式常見問題包括路由未正確寫入、區域網路存取遭接管、DNS 請求路徑不一致、休眠恢復後虛擬介面失效，以及其他 VPN 軟體同時修改預設路由。排查時可以先關閉其他網路接管工具，確認一般系統代理模式是否可用，再啟用 TUN 並檢查記錄。若只有區域網路裝置無法存取，應檢查私有位址範圍是否設定為直連，而不是直接修改所有規則。

DNS 模式與網域規則

網域規則能否準確運作，與 DNS 處理方式密切相關。mihomo 常見的增強 DNS 模式包括 redir-host 與 fake-ip。fake-ip 會為網域回傳保留位址範圍中的映射位址，再由核心在連線階段還原網域資訊，這有助於讓只發起 IP 連線的應用程式也能參與網域規則比對。某些區域網路服務、裝置探索、遊戲平台或依賴真實位址判斷的程式，可能需要加入 fake-IP 過濾範圍。

DNS 設定還可能區分預設解析器、代理節點網域解析器、依網域策略選擇的解析器與後備解析器。最容易出現的問題是循環依賴：代理節點的伺服器位址本身是網域，但解析該網域又被設定為必須透過尚未建立的代理存取。合理做法是為節點網域準備可直接存取的基礎解析路徑，並明確區分「解析代理伺服器位址」與「建立代理後解析目標網站」這兩個階段。

流量嗅探的作用範圍

流量嗅探可從 HTTP Host、TLS Server Name 等握手資訊中識別目標網域，補足只有目標 IP 時缺少的網域資訊。這對 TUN 情境下的規則比對很有幫助，但嗅探並非解密 HTTPS 內容，也不能保證所有連線都能擷取網域。加密握手方式、QUIC、應用程式自訂協定或直接使用 IP 的連線，都可能限制識別效果。

啟用嗅探後若出現個別應用程式連線異常，可以先查看識別出的網域是否正確，再針對相關目標設定略過策略。不要把嗅探、DNS 與規則問題混為一談：記錄中有網域但策略錯誤，重點檢查規則順序；記錄中只有 IP，重點檢查 DNS 與嗅探；若連線根本沒有進入核心，則應檢查系統代理、TUN 路由或應用程式本身的設定。

從 Clash 設定遷移至 mihomo 的檢查順序

遷移設定最穩妥的方法，不是一次啟用所有擴充能力，而是先建立可驗證的最小設定，再逐層恢復功能。如此便能判斷錯誤發生在 YAML 解析、節點連線、策略群組引用、規則載入、DNS 或系統接管階段。

1. 確認客戶端實際使用的核心。在客戶端的關於頁面、核心管理頁或啟動記錄中查看核心名稱與版本。介面標題中的 Clash 字樣不能作為判斷依據。
2. 備份原始設定。保留原始 YAML、訂閱網址、自訂規則與 DNS 設定。客戶端資料庫與另行匯出的 YAML 可能不是同一份內容，重要修改應單獨保存。
3. 先驗證 YAML 解析。匯入後檢查記錄中的未知欄位、重複鍵、縮排錯誤與規則提供器載入失敗。YAML 使用空格表達層級，Tab 或錯誤縮排都可能改變結構。
4. 使用簡單策略測試節點。先建立一個手動選擇群組，只放入少量節點，確認 TCP 與所需的 UDP 連線可以運作。此時先不要加入複雜的測速與負載平衡。
5. 檢查策略群組引用。規則末端指向的群組必須存在；策略群組內引用的節點或其他群組名稱也必須完全一致。名稱中的空格與標點同樣是名稱的一部分。
6. 逐步載入規則集。依序加入區域網路直連、核心業務規則、區域規則，最後加入兜底規則；每次都觀察規則提供器的更新狀態與實際命中結果。
7. 最後調整 DNS 與 TUN。先在系統代理模式下確認基礎連線，再啟用增強 DNS、嗅探與 TUN。每增加一層接管能力，都應重新測試網頁、命令列程式、區域網路與 UDP 應用程式。

發生異常時如何定位

如果核心無法啟動，優先檢查設定語法、欄位支援與監聽連接埠衝突；如果所有節點都無法使用，檢查網路連通性、協定參數、系統時間與節點網域解析；如果只有部分網站方向錯誤，查看連線記錄中的網域、目標 IP 與命中規則；如果瀏覽器正常但應用程式無法使用，檢查該應用程式是否讀取系統代理，或是否需要 TUN 接管；如果啟用 TUN 後全域斷網，先恢復至系統代理模式，再檢查虛擬網卡、預設路由與 DNS 監聽狀態。

記錄層級也應依需求調整。日常使用保留一般層級即可，排查時暫時啟用更詳細的記錄，並注意其中可能包含存取網域、節點位址與本機路徑等資訊。完成定位後恢復正常層級，可減少無關輸出與長期記錄佔用。

如何選擇原版 Clash 或 mihomo

對目前仍在選擇客戶端的使用者而言，更實際的問題通常不是單獨安裝哪一個命令列核心，而是選擇採用哪種核心的客戶端。若設定只包含傳統協定與基礎分流，現有環境能穩定運作，也沒有新增能力需求，就不必因名稱變更而倉促遷移。穩定的設定、清楚的規則與可重複的備份，比追逐每個新增欄位更重要。

如果訂閱包含 VLESS Reality、Hysteria2、TUIC 等節點，或需要邏輯規則、規則提供器、細緻的 DNS 策略、流量嗅探與 TUN 接管，mihomo 通常能提供更完整的實作基礎。選擇時也要確認圖形客戶端是否及時整合相應版本、能否管理核心更新、是否清楚顯示記錄，以及系統代理與 TUN 開關是否符合目前平台的使用習慣。

最後可以將差異概括為：原版 Clash 奠定設定與規則分流模型，mihomo 延續這套模型並擴充協定、規則與運作能力。遷移的重點不是開啟所有擴充選項，而是確認每項新增能力要解決什麼問題，並透過記錄與分階段測試驗證結果。對大多數設定而言，先確保基礎節點、策略群組與規則順序正確，再處理 DNS、嗅探與 TUN，便能減少最常見的連鎖故障。