先確認核心：用戶端名稱不等於功能範圍
匯入訂閱後出現 unsupport proxy type，或設定檔中寫了 sniffer 卻沒有預期效果，先別急著更改節點密碼。第一步應確認用戶端實際啟動的是哪個核心。介面負責管理訂閱、系統代理與開關，核心則負責解析設定、比對規則及建立連線；介面名稱相似，不代表支援相同的欄位。
本文將「原版 Clash」分為兩種：原版開源核心，以及曾獨立發行的 Clash Premium。Premium 的 TUN、規則集等功能不能直接視為原版開源核心的能力。mihomo 則由 Clash Meta 演進而來，沿用了許多 Clash 設定習慣，但不只是更改程式名稱。
- 桌面用戶端：查看「關於」頁面的核心版本資訊，並檢查啟動記錄。各用戶端的選單名稱可能不同，請以實際介面為準。
- 命令列部署：對實際執行的二進位檔執行
mihomo -v；不要只確認下載資料夾中另一份程式的版本。 - 路由器或容器：同時確認外掛選用的核心、容器映像檔與程序路徑。更新管理介面不一定會同步更新核心。
協定支援：VLESS、Hysteria2、TUIC 是主要差異
如果現有訂閱只有傳統的 Shadowsocks、VMess、Trojan 節點，遷移後可能看不出明顯差異。較容易引發相容性錯誤的，通常是新協定、新加密方式，以及協定附帶的傳輸參數。節點名稱標示「Hysteria2」並不代表核心支援；核心讀取的是 YAML 中的 type 與相關欄位。
| 協定或功能 | 原版 Clash | mihomo |
|---|---|---|
| Shadowsocks、VMess、Trojan | 可使用常見基礎協定，實際參數依版本而異 | 支援，且持續擴充 |
| VLESS | 原版開源核心與 Premium 均不支援此協定 | 支援，節點類型為 vless |
| Hysteria2 | 不支援 | 支援，節點類型為 hysteria2 |
| TUIC | 不支援 | 支援，節點類型為 tuic |
| VLESS 搭配 REALITY | 不支援 | 支援相應設定，但伺服器端參數必須相符 |
錯誤發生在哪個階段，決定了優先檢查項目
如果設定檔測試直接回報「不支援的代理類型」，問題出在本機解析階段，尚未進入節點連線測試。反之，設定載入成功但連線逾時，也不能據此判定協定不受支援。接著應檢查伺服器位址、連接埠、驗證資訊與傳輸網路。
- VLESS：確認 UUID、TLS、
servername、傳輸方式與flow。使用 REALITY 時，也要確認公鑰、short ID 等對應參數。 - Hysteria2：以 QUIC 為基礎，需要 UDP 網路可達。只測試伺服器的 TCP 連接埠，無法證明節點可用；也不要直接將第一代 Hysteria 設定改名後使用。
- TUIC：同樣要留意 UDP 網路狀況，且驗證欄位必須符合伺服器端的協定版本。用戶端支援 TUIC，不代表伺服器參數設定正確。
訂閱轉換也有其限制。轉換器可以重新排列欄位，卻無法替舊核心補上協定實作。轉換後若節點消失，請先確認輸出格式是否選用 mihomo，以及轉換服務是否支援該協定；不要反覆更新同一份不相容的訂閱。
規則集比較：rule-providers 並非 mihomo 獨有
rule-providers 用來宣告規則集來源，RULE-SET 則用來在規則清單中引用規則集。原版開源 Clash 與 Premium 在這方面的功能有明顯差異：Premium 已支援規則集，不能將所有規則集功能都說成是 mihomo 新增。mihomo 則在此基礎上支援更多格式與用法。
| 設定項目 | 遷移時的判斷方式 |
|---|---|
rules |
基礎規則清單仍依序由上而下比對，符合的第一條規則會採用其對應策略。 |
rule-providers |
Premium 已支援；不能假設原版開源核心也具備 Premium 的功能。 |
behavior |
區分 domain、ipcidr 與 classical，內容必須符合宣告的類型。 |
format: mrs |
這是 mihomo 支援的規則集格式，可用於 domain、ipcidr，不適用於 classical。 |
type: inline |
mihomo 可將規則內容直接寫入 provider 的 payload；舊核心不一定相容。 |
先用本機 YAML 驗證規則集流程
以下範例可合併至 mihomo 設定檔，不需從遠端下載，方便區分「規則寫錯」與「規則檔下載失敗」。設定只使用內建策略 DIRECT 與 REJECT，不依賴尚未定義的節點群組。
rule-providers:
local-block:
type: file
behavior: domain
format: yaml
path: ./rules/local-block.yaml
rules:
- RULE-SET,local-block,REJECT
- MATCH,DIRECT在設定檔的工作目錄中建立 rules/local-block.yaml，並填入以下內容。此處的 example.org 是用來示範規則行為的保留網域；測試時應預期該網域及其子網域會遭到拒絕。
payload:
- '+.example.org'behavior: domain 的內容應為網域比對項目，請勿填入 DOMAIN-SUFFIX,example.org。若使用 classical，才依對應的規則類型撰寫，例如 DOMAIN-SUFFIX,example.org；規則集內不需附加最終出口策略。
sniffer 與 DNS：識別網域不等於解密流量
遷移後，部分連線從比對 IP 規則改為比對網域規則，通常與 DNS 映射或嗅探有關。mihomo 的 sniffer 可從部分協定交握中擷取主機名稱，例如 HTTP 的 Host、TLS 的 SNI，以及受支援的 QUIC 交握資訊。它不是透過安裝憑證進行 HTTPS 中間人解密，也無法保證識別每一條連線的網域。
先觀察，再決定是否覆寫目標
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
override-destination: false
TLS:
ports: [443, 8443]
override-destination: false此範例只列出 HTTP 與 TLS，不代表所有連接埠都需要嗅探。override-destination: false 表示不依據嗅探結果覆寫連線目標；嗅探資訊仍可能用於網域識別與規則判斷。是否覆寫目標，應配合 DNS 與應用程式行為進行測試，不應將它視為必開的最佳化選項。
- 無法識別網域：可能是連線未經過設定的連接埠、交握內容不含可用網域，或應用程式使用了會隱藏相關資訊的機制。
- 應用程式直接連線至目標 IP：嗅探不一定能還原網域，請保留必要的 IP 規則，不要只留下網域規則。
- 網站被錯誤分流：一併檢查規則順序、DNS 回應結果、fake-ip 映射與 sniffer 設定；不要一開始就擴大嗅探範圍。
dns.enhanced-mode: fake-ip 與 redir-host 是不同的處理方式，fake-ip 也不是 mihomo 獨有。遷移時先保留原有 DNS 模式；如需調整，再分開修改並清除相關 DNS 快取。核心的 DNS 監聽位址也必須與系統或流量接管路徑連接；只設定 dns.listen 不代表系統請求已送達該位址。
TUN 與連接埠：設定相容不代表流量接管方式相同
瀏覽器可以上網，但遊戲、命令列或其他應用程式沒有走代理時，通常應檢查流量入口，而非立刻更換協定。系統代理主要影響遵循該設定的應用程式；TUN 則透過虛擬網路介面接收流量，可涵蓋更多應用程式，但也涉及權限、路由與 DNS 接管。
原版 Premium 已提供 TUN，不能將原版開源核心與它混為一談。mihomo 也支援 TUN，但無法保證舊設定中的堆疊選擇、介面參數與路由設定在所有系統上都能原樣運作。Windows、macOS、Linux 的權限與服務管理方式各不相同。
遷移時分兩階段驗證
- 先關閉 TUN，使用明確指定的代理確認節點與規則運作正常。例如設定
mixed-port: 7897後，代理入口為127.0.0.1:7897；7897 是此處的範例值，並非所有用戶端的固定連接埠。 - 在終端機執行下方指令，確認請求確實經過該入口。測試網址僅用於檢查基本 HTTPS 連線，不代表所有目標網站都能正常存取。
- 確認明確指定的代理運作正常後，再於用戶端啟用 TUN。檢查提權或服務狀態，以及虛擬介面與路由是否已建立，最後測試不會讀取系統代理設定的應用程式。
curl --proxy http://127.0.0.1:7897 --connect-timeout 10 -I https://example.com遇到 address already in use 時，先確認是否同時執行了兩個核心。遷移期間舊用戶端未關閉，是本機監聽連接埠衝突的常見原因。若整台裝置無法上網，先關閉新用戶端的 TUN 與系統代理，恢復基本網路後再逐項排查；不要同時疊加多個 VPN 或路由接管工具。
設定檔遷移步驟：分開驗收測試、載入、規則與連線
設定檔「可以載入」，只代表它通過目前階段的解析與初始化，不代表所有欄位都已生效，更不代表節點與 DNS 已可使用。部分未知欄位可能不會產生明顯錯誤，因此也應檢查執行記錄與實際行為。
- 備份目前狀態。保存原始訂閱、合併後的執行設定檔，以及本機覆寫檔。請勿將訂閱連結或節點驗證資訊張貼至公開討論區。
- 選擇相符的訂閱格式。若訂閱服務提供 Clash 與 Clash Meta/mihomo 兩種輸出格式，請依實際使用的核心選擇；並檢查產生的設定內容，不要只看按鈕名稱。
- 先執行設定檔測試。使用實際部署的二進位檔，並指定設定檔與工作目錄，避免相對路徑指向錯誤位置。
- 確認入口與節點。先透過明確指定的代理進行測試，再查看連線記錄中選用的節點或策略群組；若連線失敗，請保留完整錯誤資訊。
- 確認規則集。檢查 provider 是否載入成功、規則項目是否存在，以及測試網域實際符合哪一條規則。
- 最後再啟用進階功能。每次只修改 DNS、sniffer、TUN 其中一項。若出現異常，才能明確還原至上一份可用設定。
mihomo -v
mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml上述 /srv/mihomo 是 Linux 部署範例目錄，執行前請確認檔案確實位於該目錄。Windows 可在目前設定目錄執行 mihomo.exe -t -d . -f .\config.yaml 進行測試。若由用戶端管理核心，實際生效的檔案可能是訂閱與覆寫內容合併後產生；不要只測試未被使用的原始檔案。
如何選擇：依節點協定與維護需求判斷
若需要 VLESS、Hysteria2、TUIC、MRS 規則集或 sniffer 等功能，mihomo 的支援範圍較符合需求。若只維護傳統協定的設定，遷移重點應放在設定可否驗證、用戶端是否持續維護，以及發生問題時能否定位原因，而非期待更換核心就能自動降低延遲。
- 現有設定運作穩定：保留備份，先在獨立的測試環境驗證新核心，不要同時修改節點、規則與 DNS。
- 訂閱提示不支援該協定：先確認產生的格式與實際執行的核心，再決定是否切換用戶端或核心。
- 路由器資源有限：留意規則集大小、載入時間與裝置可用記憶體；選擇格式不能取代實際運行狀況的觀察。
- 準備從 mihomo 轉回其他核心：逐一移除目標核心不支援的協定與欄位，再重新測試設定檔並驗收連線。
兩者的差異可分三個層面理解：協定決定節點能否被識別；規則與 DNS 決定連線如何分流；系統代理或 TUN 則決定流量能否進入核心。依這三個層面逐一檢查，比一次切換多個設定更容易找出問題。