mihomo 核心比原版 Clash 強在哪裡：協定支援、規則集與 TUN 差異比較

先釐清核心與用戶端

Clash、mihomo 與 FlClash 位於不同層級。核心負責讀取 YAML 設定、建立代理連線、比對規則、處理 DNS 與轉送流量；用戶端則負責訂閱管理、編輯設定、系統代理切換、顯示日誌，以及申請平台權限。FlClash 是圖形化用戶端，mihomo 是它可以使用的代理核心。比較「原版 Clash 與 mihomo」時，真正比較的是兩套核心的能力，而不是視窗配置或按鈕數量。

通常所說的原版 Clash，是 Dreamacro 發布的開放原始碼 Clash。其公開版本停留在 v1.18.0，常見基礎能力包括 HTTP、SOCKS5 與 mixed 入站、規則模式、策略組、DNS 處理，以及 Shadowsocks、VMess、Trojan 等代理類型。Clash Meta 從原版程式碼體系持續擴充，後來更名為 mihomo。許多設定欄位仍具相容性，因此舊訂閱通常可以直接載入，但相容不代表兩者功能完全相同。

一組可直接觀察的差異

能力	原版 Clash	mihomo	日常影響
基礎規則與策略組	支援	相容並持續擴充	舊設定的遷移成本較低
新型出站協定	範圍固定	支援 Hysteria2、TUIC、VLESS、WireGuard 等	訂閱包含新節點時，不必另換核心
規則集	具備基礎 rule-providers 體系	格式、比對行為與更新能力更完整	大型規則可拆分維護
TUN	不同發行版本的能力不一	持續維護自動路由、嚴格路由與多種協定堆疊	可接管不讀取系統代理的程式
流量嗅探	能力有限	獨立的 sniffer 設定與覆寫策略	透明代理下仍能還原網域資訊

協定支援：差異首先出現在節點類型

原版 Clash 常見的出站類型已能涵蓋傳統訂閱：Shadowsocks、VMess、Trojan、HTTP、SOCKS5 與 Snell 等。問題在於代理協定仍持續演進。若伺服器提供 Hysteria2、TUIC、VLESS Reality、ShadowTLS 或 WireGuard 節點，舊核心可能直接提示不支援該代理類型，也可能在解析訂閱後忽略對應節點。

mihomo 為這些類型提供原生設定入口，並讓它們納入統一的策略組、健康檢查與規則分流體系。例如，一個 url-test 策略組可以同時容納傳統 Trojan 節點與 Hysteria2 節點，再依探測延遲自動選擇。對使用者而言，升級點不只是協定名稱變多，而是訂閱中的節點都能由同一套規則呼叫。

協定變多，不代表必須全部啟用

Hysteria2：以 QUIC 為基礎，通常使用 UDP，適合伺服器與網路環境都能穩定支援 UDP 的情境。
TUIC：同樣依賴 QUIC 與 UDP，參數中的 UUID、密碼與壅塞控制設定必須與伺服器一致。
VLESS：可搭配 TLS、Reality 與不同傳輸方式使用，不能只憑節點名稱判斷傳輸結構。
WireGuard：採用通道介面模型運作，需要正確填寫私鑰、公鑰、位址與允許的路由範圍。
ShadowTLS：用於特定鏈式結構，實際設定通常還會引用另一個撥號代理。

選擇節點時仍應考量伺服器部署品質、鏈路丟包與本地網路。一次延遲測試只能反映探測 URL 當下的往返時間。例如，在同一網路中 TCP 節點測得 82 ms、QUIC 節點測得 61 ms，不代表後者持續下載時一定更快；若電信業者限制 UDP 流量，QUIC 節點可能在幾分鐘後出現明顯抖動。

rule-providers：將大型規則拆離設定本文

rule-providers 的核心用途，是將規則存放在獨立檔案，再由主設定透過 RULE-SET 引用。這個概念並非 mihomo 憑空新增，原版 Clash 後期的設定體系已可見規則提供者；mihomo 的優勢在於持續完善格式支援、比對類型、更新流程與相關行為，並能搭配更豐富的規則語法使用。

只有幾十條規則的設定，可以直接將網域寫在 rules 下。規則達到數萬條後，繼續內嵌會讓主檔案難以閱讀，也會使訂閱覆寫與版本管理變得複雜。拆分後，主設定只保留規則集位址、更新週期與目標策略，規則內容則由獨立檔案維護。

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/private-ip.yaml
    path: ./ruleset/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,節點選擇

behavior 決定檔案中可寫入的內容

domain：用於網域類項目，適合網域後綴、完整網域等集合。
ipcidr：用於 IPv4、IPv6 網段。若目前比對不需要觸發 DNS，可在引用規則後加入 no-resolve。
classical：每個項目都可以帶有完整規則類型，例如 DOMAIN-SUFFIX、PROCESS-NAME 或 IP-CIDR。

interval: 86400 表示每 86400 秒檢查一次遠端規則，也就是 24 小時。它不是「每次請求都下載」。首次取得成功後，核心會使用本地快取；遠端伺服器暫時無法連線時，既有檔案通常仍可繼續參與比對。需要注意的是，規則位址本身也必須能由目前網路存取，否則首次啟動時可能沒有可用快取。

mihomo 也支援面向規則集合的二進位 mrs 格式。它適合體積較大的網域或 IP 規則集，目標是降低解析負擔與儲存空間。mrs 不是一般文字檔，無法直接用編輯器逐行修改；需要人工維護的私有規則，繼續使用 YAML 或文字格式會更直觀。

規則順序仍比規則數量重要

Clash 規則採用由上而下、首次命中即停止的邏輯。即使規則集更新成功，如果將寬泛的代理規則放在直連規則之前，後面的直連項目仍不會執行。常見順序是私有網域、區域網路與保留位址在前，業務規則集居中，GEOIP 或其他區域判斷靠後，最後用 MATCH 收尾。

TUN 模式：從系統代理擴展到全域流量接管

系統代理通常只會影響主動讀取作業系統代理設定的應用程式。瀏覽器大多支援，但遊戲、命令列工具、部分商店用戶端、虛擬機程式，以及直接發起 UDP 通訊的軟體可能繞過它。TUN 模式會建立虛擬網路介面，將符合路由條件的 IP 流量送入核心，因此涵蓋範圍更廣。

原版 Clash 的不同版本與發行形式曾提供 TUN 能力，但設定、平台適配與維護狀態並不統一。mihomo 持續擴充 TUN 的自動路由、DNS 劫持、多種網路協定堆疊、介面選擇與嚴格路由，這也是現代圖形化用戶端普遍採用 mihomo 的重要原因。

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

這幾個欄位分別控制什麼

stack: mixed：使用混合協定堆疊處理連線，通常可作為桌面端的起點。具體可用值應以目前核心版本為準。
auto-route: true：自動寫入所需路由，讓目標流量進入 TUN 介面。
auto-detect-interface: true：自動識別目前的預設出口，減少 Wi-Fi 與有線網路切換後的手動調整。
strict-route: true：加強路由限制，降低部分流量繞過 TUN 的可能性；某些虛擬化或區域網路環境需要額外測試。
dns-hijack：接管指定連接埠的 DNS 請求。傳統 DNS 通常使用 UDP 或 TCP 53 連接埠。

在 FlClash 中，通常應先匯入設定並確認一般系統代理可用，再進入「設定」→「網路設定」啟用 TUN 模式。Android 與桌面系統會要求建立 VPN 或虛擬網路介面；授權後再檢查日誌中的 TUN 初始化結果。若用戶端版本的選單文字略有調整，可在「設定」中尋找 TUN、VPN 服務或網路介面相關項目。

TUN 常見衝突點

其他 VPN 同時執行：兩個程式都嘗試接管預設路由時，可能造成斷網或路由反覆切換。
區域網路存取異常：印表機、NAS 或開發裝置所在網段需要加入直連規則，常見私有網路包括 192.168.0.0/16、10.0.0.0/8 與 172.16.0.0/12。
虛擬機與容器網路：Docker、WSL、Hyper-V 等會建立虛擬網卡，自動介面識別不正確時，需要檢查出口選擇與排除路由。
DNS 被重複接管：系統安全軟體、加密 DNS 工具與 mihomo 同時監聽或重新導向 DNS，可能造成查詢逾時。

嗅探能力：透明代理仍能找回網域

規則引擎更適合依網域判斷流量，但 TUN 最先看到的往往只有目標 IP。例如某個應用程式已自行完成 DNS 查詢，接著直接連線至 203.0.113.10:443，核心若只取得 IP，就無法直接使用 DOMAIN-SUFFIX 規則。嗅探器會分析連線初期的資料，從 TLS 的伺服器名稱、HTTP Host 或 QUIC 資訊中擷取目標網域，再用於規則比對。

sniffer:
  enable: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip 允許針對目標呈現為純 IP 的連線嘗試識別網域；override-destination 決定是否以嗅探結果覆寫原本的目標資訊。連接埠範圍應依實際業務設定，不宜為了「全部涵蓋」而對所有連接埠啟用每一種解析器。非 HTTP、TLS 或 QUIC 的私有協定，無法透過這些解析器取得有效網域。

嗅探不是 DNS 的替代方案

嗅探發生在建立連線階段，DNS 則決定網域如何解析，兩者處理的問題不同。穩定的設定通常仍需要合理設定 nameserver、fallback、fake-ip 或 redir-host 等 DNS 欄位。若使用 Fake IP，核心會將網域對映至保留位址池，再於連線階段還原網域；嗅探則能補足繞過核心 DNS、直接連線至 IP 的流量。

少數應用程式會使用憑證固定、加密的用戶端問候或自訂 QUIC 行為，嗅探未必能取得可用名稱。遇到連線被錯誤覆寫時，可以先查看日誌中的原始目標與嗅探目標，再透過略過網域或略過來源位址規則排除特定業務，而不是直接關閉全部嗅探。

DNS、規則與 TUN 必須作為一套設定檢查

mihomo 的強化能力彼此相關。只開啟 TUN 而不處理 DNS，可能導致規則無法取得網域；只啟用嗅探而未設定正確的規則順序，還原出的網域仍會命中錯誤策略；規則集設定正確，但下載位址遭目前網路阻擋，首次啟動時規則檔案仍無法寫入。排查時應依「入站接管 → DNS → 嗅探 → 規則比對 → 策略組 → 出站連線」的順序查看日誌。

一套可重複執行的檢查流程

在一般系統代理模式下，確認至少有一個基礎節點可以建立 TCP 連線。
檢查 mixed 入站連接埠是否被占用，常見值為 7890，不要讓兩個用戶端監聽同一個連接埠。
確認 DNS 日誌能回傳結果，並觀察回傳的是實際 IP 還是 Fake IP 位址。
啟用 TUN 後關閉系統代理，測試不讀取系統代理的應用程式是否進入核心日誌。
查看連線紀錄中的 Host、目標 IP、命中規則與最終策略組，確認嗅探結果沒有錯誤覆寫。
手動更新規則提供者，確認 HTTP 狀態、儲存路徑與更新時間；再等待一個完整的 interval 週期，驗證是否能自動更新。
分別測試 TCP 與 UDP。網頁可以開啟，只代表 TCP 路徑基本正常，不能證明 QUIC、遊戲語音或 DNS 的 UDP 路徑正常。

哪些使用者能直接感受到 mihomo 的提升

只使用瀏覽器、基礎 Shadowsocks 節點與幾條網域規則的使用者，切換核心後未必能立即感受到速度變化。mihomo 的價值更偏向「涵蓋能力與設定上限」：訂閱出現新協定時可以解析，應用程式繞過系統代理時可由 TUN 接管，透明流量缺少網域時可由嗅探補足，大型規則則能透過規則提供者獨立更新。

訂閱包含 Hysteria2、TUIC 或 VLESS：協定相容性是直接需求。
需要代理遊戲、終端機或商店用戶端：TUN 比單獨設定 HTTP 系統代理的涵蓋範圍更完整。
維護大量分流規則：rule-providers 能將主設定與規則資料分離。
使用 Fake IP 與透明代理：DNS、嗅探與網域規則之間的整合更為重要。
頻繁切換 Wi-Fi、有線網路與熱點：自動介面識別與自動路由可減少手動調整。

將舊設定遷移至 mihomo 時，不必立即開啟所有強化功能。較穩妥的順序是先驗證節點與策略組，再驗證規則，接著調整 DNS，最後啟用 TUN 與嗅探。如此發生異常時，就能快速定位是代理協定、解析鏈路、規則順序還是系統路由所造成。

結論可濃縮為四點：原版 Clash 奠定了設定語法與規則代理模型；mihomo 延續其相容基礎，並持續加入新協定；規則提供者更適合維護大型且可更新的規則資料；TUN 與嗅探則讓分流從「支援系統代理的應用程式」擴展至更完整的裝置流量。實際設定應圍繞所需功能啟用，而不是機械式堆疊欄位。