核心定位：Clash Meta 與 mihomo 的設定界線

mihomo 是從 Clash Meta 延續發展而來的代理核心。用戶端負責管理設定、系統代理與介面操作；核心則負責監聽連線、解析規則並建立代理連線。用戶端名稱含有 Clash，不代表它一定使用 mihomo；能匯入 YAML，也不表示它支援其中所有協定與擴充欄位。

本文所說的「新增特性」，是指相較早期 Clash 開源核心擴充的功能，並非某個版本在同一天新增的功能。Clash Premium 等分支也有實作規則提供器，因此不能簡單地把 rule-providers 視為 mihomo 專屬欄位。遷移時應確認目前使用的核心，而不只是比較用戶端外觀。

功能主要設定入口啟用條件
外部規則集rule-providers、RULE-SET規則格式須與 behavior 相符，且資源可讀取
網域嗅探sniffer連線已進入核心，且流量包含可識別的網域資訊
VLESS 出站type: vless伺服器協定、傳輸層與 TLS 參數一致
Hysteria2 出站type: hysteria2伺服器支援 Hysteria2，網路允許相應的 UDP 通訊

先確認目前執行的核心

獨立部署時可執行以下指令。若使用圖形介面用戶端，請先查看核心資訊頁與啟動記錄；系統終端中的同名程式，可能不是用戶端實際呼叫的執行檔。

mihomo -v
mihomo -t -f config.yaml

-v 用於查看核心版本，-t 用於測試指定設定。設定測試可以找出不少欄位與參照錯誤，但無法證明遠端節點可連線，也不能取代實際的 DNS、TCP 與 UDP 測試。若遇到不支援的欄位，請保留完整版本輸出，再對照該版本的設定文件。

rule-providers：將規則內容與分流策略分開

若將大量網域逐一寫進 rules，維護成本會隨之增加。規則提供器可將「需要比對的集合」移至獨立資源，主設定只保留集合名稱、更新方式與最終動作。規則集不是節點訂閱：前者提供比對條件，後者提供代理伺服器，兩者不能互相匯入。

HTTP 規則集與 RULE-SET 參照

以下以公開網域規則集說明各欄位的關係。遠端資源由相關專案維護，部署前請先檢視內容與用途。範例會將比對結果交給 REJECT，其餘連線則直連；用途是驗證規則集能否載入，並非完整的分流方案。

mode: rule
log-level: info

rule-providers:
  reject-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt
    path: ./ruleset/reject-domains.yaml
    interval: 86400

rules:
  - RULE-SET,reject-domains,REJECT
  - MATCH,DIRECT
  • type: http：透過 HTTP 或 HTTPS 取得資源；首次使用仍須確保網路連線正常。
  • behavior: domain：將內容視為網域集合，而非完整規則敘述。
  • format: yaml：指定資源的編碼格式。URL 結尾是 .txt，不代表內容一定是純文字格式。
  • path：本機快取位置。請確認核心工作目錄有寫入權限，並避免多個規則集共用同一個檔案。
  • interval: 86400：更新間隔為 86400 秒，也就是 24 小時，單位不是毫秒。

behavior 必須與檔案內容相符

domain 用於網域集合，ipcidr 用於 IP 網段集合，classical 則用於 DOMAIN-SUFFIX、IP-CIDR 等規則敘述。三者不能只更改名稱，卻沿用同一份檔案。以下是本機 classical YAML 檔案的結構，可用來了解它與一般網域清單的差異：

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.50.0/24,no-resolve

這裡的 example.com 是保留示例網域，192.168.50.0/24 則是私有網段範例。此檔案只列出比對條件；要直連、走代理或拒絕連線，則由主設定中的 RULE-SET,集合名稱,策略名稱 決定。若需要使用不同出口，應將條件拆分為不同集合，而非在集合項目後任意加上策略組。

網域嗅探：從連線內容補足網域資訊

連線以目標 IP 進入核心時，網域規則可能缺少比對依據。嗅探會嘗試讀取 HTTP 的 Host、TLS ClientHello 中可見的 SNI，或支援的 QUIC 交握資訊，以補足目標網域。這不是 HTTPS 解密，不會因此取得加密的網頁內容，也不保證每條連線都能辨識出網域。

HTTP、TLS 與 QUIC 設定範例

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]

ports 是嘗試辨識相應協定的目標連接埠範圍。只列出 443，不會自動涵蓋使用其他連接埠的所有 TLS 服務。parse-pure-ip 允許對純 IP 目標嘗試嗅探；force-dns-mapping 則用於相關 DNS 對應情境，讓嗅探繼續嘗試。兩者都不代表一定能擷取網域。

範例將 override-destination 設為 false，避免直接以嗅探出的網域取代原始目標，適合先觀察比對結果的變化。設為 true 會改變連線目標的處理方式，應另行測試。辨識出的網域可能影響規則選擇，但規則仍受目前模式與順序限制；在全域模式下，不能因此期待完整的網域分流。

與 Fake-IP、TUN 的關係

  • Fake-IP：透過核心維護的 DNS 對應，將網域連結至假 IP 位址。應用程式的 DNS 查詢已進入核心時，通常已有可用的網域資訊，嗅探屬於補充機制。
  • TUN：負責透過虛擬網卡接入網路流量。它會擴大流量接管範圍，但不會自動讓所有連線都帶有網域資訊。
  • 嗅探：處理已進入核心的連線，不會接管繞過系統代理、也未經過 TUN 的流量。
  • 辨識限制：ECH 等加密機制、非標準交握、缺少 SNI 或不支援的協定，都可能導致無法擷取預期的網域。

排查時，先確認連線是否出現在用戶端的連線清單，再查看目標 IP、辨識出的網域、命中規則與最終策略。只有連線進入核心後，調整 sniffer 才有意義。若某個應用程式未被接管，應先檢查系統代理或 TUN 路由，而非一再擴大嗅探連接埠範圍。

VLESS：分別確認協定、傳輸層與 TLS 參數

VLESS 是代理協定，WebSocket 是可選的傳輸方式，TLS 則是連線安全層，三者並非同一個開關。若伺服器使用 VLESS over WebSocket over TLS，用戶端必須同時確認 UUID、連接埠、WebSocket 路徑、Host 與 TLS 伺服器名稱一致。

以下使用保留示例網域與示範 UUID 說明欄位結構，並非可用服務。實際部署時應使用伺服器提供的完整參數，不要試猜路徑或關閉憑證驗證來排除連線錯誤。

proxies:
  - name: VLESS-WS-TLS
    type: vless
    server: vless.example.com
    port: 443
    uuid: 550e8400-e29b-41d4-a716-446655440000
    network: ws
    tls: true
    servername: vless.example.com
    udp: true
    ws-opts:
      path: /proxy
      headers:
        Host: vless.example.com

常見參數不相符情況

  1. 傳輸類型不一致：伺服器使用 TCP，用戶端卻設定 network: ws，無法只靠更改連接埠解決。
  2. 網域用途混淆：server 是連線位址，servername 用於 TLS，WebSocket 的 Host 用於 HTTP 請求。依部署方式不同，三者可以不同，但不能任意互換。
  3. 路徑不一致：/proxy 與其他路徑可能由反向代理轉送至不同服務，請保留伺服器要求的路徑與大小寫。
  4. 混用其他方案的欄位：REALITY、公鑰、指紋與 flow 各有適用條件，不應直接加到一般的 WebSocket TLS 範例中。

新增代理項目後，還要將其名稱加入現有策略組，並在規則中參照該策略組。只在 proxies 中新增項目，不代表實際請求就會選用它。如果用戶端會定期覆寫訂閱設定，請使用用戶端支援的覆寫或合併功能保存自訂項目，避免下次更新時遺失。

Hysteria2：先檢查 UDP 連線，再調整傳輸參數

Hysteria2 以 QUIC 為基礎，依賴 UDP 通訊。它與第一代 Hysteria 使用不同的設定語法；節點標示為 Hysteria2 時，應使用 type: hysteria2。能透過 TCP 連線至伺服器的 443 連接埠，不代表同一連接埠上的 UDP 服務也能連通。

proxies:
  - name: HY2-TLS
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: demo-password-for-documentation
    sni: hy2.example.com
    skip-cert-verify: false

此處同樣使用保留示例網域與示範認證資訊。password 必須與伺服器的認證設定一致，sni 則應符合實際憑證與伺服器部署需求。若伺服器啟用了特定混淆機制，也必須設定對應欄位；不能因協定名稱相同就省略這些參數。

連線逾時的檢查順序

  • 確認伺服器位址能解析至預期的 IP，並特別檢查 IPv4 與 IPv6 連線是否都正常。
  • 確認伺服器正在監聽 UDP 443，且主機防火牆、雲端安全性群組與中間閘道均允許相應流量。
  • 確認認證資訊、SNI、憑證有效期限，以及用戶端裝置的時間。
  • 改用另一個網路進行對照測試，確認目前網路是否限制 UDP 流量。
  • 基礎連線建立後，再依伺服器要求調整頻寬或混淆參數；每次只變更一類設定。

Hysteria2 的實際表現會受到封包遺失、網路壅塞、電信業者政策與伺服器資源影響；協定名稱本身不代表固定傳輸速度。比較時應使用相同裝置、網路與目標，並分別記錄連線成功率與傳輸表現；不要將單次測速結果套用至所有環境。

設定驗證：依序檢查解析、資源、連線與規則

規則集、嗅探與新協定可以搭配使用，但初次遷移時不建議一次啟用所有功能。先備份原始設定，並保留一個已確認可用的出口，再逐項修改。以下流程可協助區分「設定載入失敗」與「節點連線失敗」。

  1. 解析層：執行 mihomo -t -f config.yaml，檢查縮排、重複的頂層鍵、未知的代理類型，以及參照不存在的策略組等問題。
  2. 資源層：啟動核心，檢查規則集是否下載成功。HTTP 錯誤、寫入權限不足與內容格式不符，應分別排查。
  3. 連線層：先選擇一個代理節點測試交握。VLESS 著重檢查傳輸與 TLS，Hysteria2 則著重檢查 UDP 與認證。
  4. 規則層：切換回規則模式，確認目標連線是否命中預期的 RULE-SET，以及最終出口是否符合策略組目前的選擇。

使用明確的連接埠測試本機入口

若測試設定中有 mixed-port: 7890，可用以下請求測試本機 HTTP 代理入口。mixed-port 同時接受 HTTP 與 SOCKS 代理連線；該連接埠不是節點伺服器連接埠，也不是外部控制器連接埠。

curl -I --proxy http://127.0.0.1:7890 https://example.com

這項指令只能確認這次請求的處理結果。請同時查看連線記錄，確認流量實際經過代理節點還是 DIRECT；收到網頁回應，並不能單獨證明分流設定正確。測試期間可暫時將 log-level 設為 debug，結束後再恢復為 info。分享記錄前，請移除訂閱網址、認證資訊與個人瀏覽記錄。

合併 YAML 時保留唯一的頂層鍵

本文各程式碼區塊分別示範不同功能，不能未經整理就連續附加到檔案末尾。若已有 proxies，應將新節點加入原有清單；若已有 rules，則應依優先順序插入規則。重複定義同名頂層鍵可能會造成錯誤，也可能被解析器覆寫，不應依賴這種行為合併設定。

遷移完成的判斷標準為：核心版本明確、設定測試通過、規則資源可用、目標協定能完成交握，且連線記錄顯示預期的規則與出口。若需擴大系統流量接管範圍，再另外啟用 TUN，並重新測試區域網路存取、DNS 與應用程式連線。基本操作可參考本站的設定教學，名詞說明請參閱概念速查。