mihomo 與原版 Clash 有什麼差異：協定支援、DNS 設定與遷移注意事項

先釐清 Clash、Clash Meta、mihomo 與用戶端

原版 Clash 通常是指 Dreamacro 專案發布的 Clash 核心。它讀取 YAML 設定，建立 HTTP、SOCKS 或 mixed 監聽連接埠，再依照代理群組與規則決定連線去向。Clash Meta 是在這套設定思路上擴充而成的核心分支，後來以 mihomo 作為專案名稱。實際遷移時，可以將「Clash Meta 設定」與「mihomo 設定」理解為同一技術路線不同階段的稱呼，但不能因此認定任意版本之間都完全相容。

Clash Verge Rev、FlClash 等圖形化用戶端負責匯入設定、切換系統代理、顯示日誌與管理核心；mihomo 才是執行協定、DNS、規則與 TUN 接管的核心。訂閱服務則提供節點與策略設定。這三者分別屬於介面、執行層與設定來源，排查問題時應先確認錯誤來自哪一層。

使用命令確認目前執行的核心

以命令列部署時，可先執行版本查詢。不同建置版本輸出的附加資訊可能不同，但結果中應能看到 mihomo 名稱、版本、目標系統與處理器架構。

mihomo -v

例如，某台機器可能顯示 Mihomo Meta v1.19.3 linux amd64。這裡的 v1.19.3 只用於說明如何讀取版本，不應視為所有功能的統一最低要求。協定、設定欄位與預設行為會隨發布版本變化，遷移前應以目前二進位檔的版本資訊及相應發布說明為準。

如果機器上仍使用名為 clash 的舊可執行檔，也要執行一次 clash -v。僅將新檔案改名為舊名稱，不會把舊核心升級為 mihomo；判斷依據應是程式輸出與實際程序路徑，而不是檔案名稱。

協定與規則能力有哪些實際差異

原版 Clash 已涵蓋 Shadowsocks、VMess、Trojan、HTTP、SOCKS5 等常見代理類型，並提供 DIRECT、REJECT、代理群組、規則模式與基礎 DNS 功能。mihomo 延續這些設定結構，同時加入或擴充 VLESS、Reality、Hysteria2、TUIC、WireGuard 等能力。具體協定能否使用，還取決於核心版本、訂閱產生方式，以及伺服器端參數是否完整。

協定名稱相同，不代表參數可以直接沿用

遷移時最容易誤判的是「訂閱中看得到節點，所以節點一定能連線」。用戶端能成功解析 YAML，只代表設定格式基本可讀，不代表握手參數正確。例如 VLESS Reality 通常還涉及伺服器名稱、公鑰、短 ID、用戶端指紋與流控參數；Hysteria2 需要核對伺服器位址、驗證資訊、TLS 伺服器名稱及憑證驗證設定。欄位缺失時，節點仍可能出現在清單中，但連線日誌會在握手階段失敗。

• 先選擇一個明確可用的節點，不要一開始就透過自動測速群組間接測試。
• 將日誌層級暫時設為 debug，完成一次目標連線後立即查看握手錯誤。
• 區分逾時、DNS 解析失敗、TLS 名稱不相符與驗證失敗，這些情況分別對應不同的修復方向。
• 訂閱轉換器可能會改寫欄位，必要時比對訂閱原始內容與用戶端儲存的設定。

規則仍會依順序執行

mihomo 沒有改變規則模式的核心原則：由上而下求值，第一條符合的規則決定去向。遷移後若出現「所有流量都走代理」或「特定網域無法直連」，首先檢查規則順序，而不是反覆切換節點。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN,blocked.example,REJECT
  - MATCH,PROXY

這裡的 PROXY 必須是設定中已定義的策略群組，並不是核心內建的出口。no-resolve 表示比對這條 IP 規則時不主動將網域解析成 IP，並不等於關閉所有 DNS。舊設定若缺少名為 PROXY 的策略群組，測試設定時就應先回報引用錯誤，而不是等到連線階段才處理。

為什麼 DNS 設定是遷移的高風險部分

舊 Clash 設定遷移至 mihomo 後，即使代理節點可以連線，也可能出現網頁開啟緩慢、區域網路網域失效、中國大陸與其他地區的解析結果不符預期，或啟用 TUN 後完全無法解析。這類問題通常不是協定不相容，而是系統 DNS、mihomo DNS、代理節點網域解析與 fake-ip 對映之間形成了錯誤路徑。

理解 fake-ip 與 redir-host

enhanced-mode: fake-ip 會先向應用程式回傳保留位址，再由核心保存網域對映，並在接管連線時還原真實目標。常見位址池是 198.18.0.1/16。它適合需要依網域規則處理的情境，但區域網路探索、印表機、部分遊戲平台，或會自行驗證憑證與位址的應用程式，可能需要加入過濾清單。

redir-host 更接近先解析真實位址，再處理連線。它減少 fake-ip 對區域網路應用程式的影響，但網域規則命中、解析延遲與快取行為會有所不同。遷移時不應只因為某個範本使用 fake-ip，就直接覆蓋現有設定，應先確認目前的接管方式與應用程式需求。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

範例將 DNS 監聽限制在 127.0.0.1:1053，用於說明連接埠與監聽位址的關係。若由 TUN 的 DNS 劫持接管請求，設定還要與用戶端產生的 TUN 區段配合。連接埠 1053 不是強制值，也不會自動修改作業系統 DNS。

代理節點網域需要獨立考量

如果代理伺服器本身填寫的是網域，核心必須先解析該網域，才能建立代理連線。若這個解析請求又被規則送進尚未建立的代理，就可能形成啟動迴圈。mihomo 設定可透過 proxy-server-nameserver 指定代理節點網域的解析伺服器，並透過 nameserver-policy 為特定網域選擇解析路徑。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

這段設定只展示欄位關係，不包含完整的代理、策略群組與規則定義。使用加密 DNS 時，還要確保其網域能完成初始解析。遷移後若日誌持續出現 DNS 逾時，應先使用一般 IP DNS 驗證基礎路徑，再逐項恢復 DoH、策略解析與規則跟隨，避免同時改動四、五個變數。

TUN 模式遷移要檢查權限、路由與介面

系統代理只會影響主動讀取系統代理設定的應用程式。終端機命令、遊戲、虛擬機器與部分更新程式可能繞過系統代理，因此不少使用者遷移至 mihomo 時會同時啟用 TUN。TUN 會建立虛擬網路介面並修改路由，涵蓋範圍更廣，也更依賴作業系統權限與路由設定。

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

stack 可用值與行為應依目前 mihomo 版本核對，常見選擇包括 system、gvisor 與 mixed。遷移時先沿用用戶端預設值，再根據日誌處理相容性問題。直接將路由器範本複製到桌面系統，可能連同帶入介面名稱、路由表或 DNS 劫持方式，造成網路中斷。

依序縮小 TUN 故障範圍

1. 關閉 TUN，只啟用 mixed 連接埠，確認代理節點本身可以運作。
2. 檢查監聽連接埠。常見範例是 mixed-port: 7890，瀏覽器可暫時將 HTTP 與 SOCKS5 代理設定為 127.0.0.1:7890。
3. 啟用 TUN，確認用戶端已取得建立虛擬介面與修改路由所需的權限。
4. 檢查是否同時執行 VPN、虛擬機器網路、遊戲加速器或另一套透明代理。
5. 分別測試 IP 與網域。IP 可連線但網域失敗時，優先回頭檢查 DNS 設定。
6. 存取區域網路裝置，確認私有位址規則位於兜底規則之前。

在 Windows 上，權限申請通常由用戶端完成；在 macOS 上，可能涉及 VPN 設定或網路擴充功能授權；Linux 服務部署則需要檢查服務使用者、網路能力與路由操作權限。不同用戶端對這些步驟的封裝方式不同，不能將某個用戶端的選單開關視為 mihomo 核心的通用設定欄位。

將舊設定遷移至 mihomo 的可重現步驟

第一步：保留舊檔案與執行資訊

複製目前的 config.yaml、規則集、本機覆寫設定與用戶端設定目錄，並記錄舊核心版本、系統代理連接埠、控制連接埠、TUN 狀態及正常使用的節點。訂閱網址不應寫入公開日誌或截圖。若用戶端支援多個設定，應明確確認哪一份正在生效，避免修改到未選取的檔案。

第二步：先進行靜態設定測試

mihomo 提供設定測試參數，可在啟動服務前檢查 YAML 語法、策略群組引用與部分欄位錯誤。假設設定檔位於目前目錄，可以執行：

mihomo -t -f config.yaml

測試通過只表示核心能夠載入設定，不代表每個節點都能建立連線，也不代表遠端規則集一定能下載。若測試失敗，應從第一個錯誤開始修復；後續錯誤可能只是前面的縮排或欄位結構問題連帶產生。

第三步：使用最小設定驗證監聽連接埠

遷移時可以暫時保留一個代理、一個策略群組與少量規則，將 mixed 連接埠設為 7890，控制介面限制在 127.0.0.1:9090。如果啟用了外部控制介面，應同時設定存取金鑰，並確認用戶端填寫的位址、連接埠與金鑰一致。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-this-local-secret"

這裡的金鑰是範例值，實際設定應予以替換。控制連接埠只供管理介面讀取狀態與切換策略，不承載網頁代理流量；將瀏覽器代理指向 9090 不會得到正確結果。

第四步：逐項恢復規則集、DNS 與 TUN

建議依照「節點連線 → 策略群組 → 本機規則 → 遠端規則集 → DNS → TUN」的順序恢復。每加入一層，就完成一次網域存取、IP 存取、區域網路存取與日誌檢查。如此一來發生問題時，回退範圍只有一個步驟。

• 規則提供者：檢查 behavior、檔案格式、更新間隔與引用名稱。
• 地理資料：確認 GEOIP、GEOSITE 資料檔案能由目前的核心讀取。
• 策略群組：檢查規則目標名稱與 proxy-groups 名稱完全一致。
• 訂閱覆寫：確認用戶端更新訂閱時是否會覆蓋本機 DNS 或 TUN 設定。
• 區域網路：需要其他裝置連線時再啟用 allow-lan，並設定監聽位址與防火牆。

常見遷移症狀與對應檢查項目

進行終端機測試時可明確指定代理，避免將「終端機沒有讀取系統代理」誤判為核心故障。例如 mixed 連接埠為 7890 時，可以讓支援 SOCKS5 的工具連線至 socks5h://127.0.0.1:7890；其中由代理端解析網域的方式，更適合驗證 mihomo 的網域規則路徑。

遷移完成後的驗收標準

遷移完成不應只以用戶端系統匣圖示變色為依據。至少應驗證：設定測試通過；選定節點可建立連線；DIRECT 與代理規則分別命中；被拒絕規則確實阻擋；DNS 沒有持續逾時；系統代理與 TUN 的涵蓋範圍符合預期；訂閱更新後本機覆寫設定仍然保留。

1. 記錄目前 mihomo 版本與用戶端版本，方便後續升級比較。
2. 在日誌中確認一個直連請求、一個代理請求與一個拒絕請求的規則命中結果。
3. 關閉系統代理後檢查 TUN 是否仍依預期接管；關閉 TUN 後檢查 mixed 連接埠是否仍可獨立使用。
4. 更新一次訂閱並重新載入設定，確認策略群組名稱、DNS 與規則提供者沒有被覆蓋。
5. 重新啟動用戶端或系統，確認核心、設定與權限狀態都能恢復。