先釐清用戶端、核心與設定檔
遇到「訂閱匯入成功，節點卻無法使用」時，先別急著更換訂閱。圖形介面用戶端負責管理訂閱、顯示介面及系統設定；核心則負責解析設定檔、建立代理連線與執行分流。介面顯示了節點名稱，不代表後端核心支援該節點使用的協定。排查時應先查看用戶端記錄中的核心名稱與版本，而不只是視窗顯示的用戶端版本。
mihomo 是原 Clash Meta 專案更名後的核心，沿用 Clash 設定體系並持續擴充。談到「原版 Clash」時，也要區分過去的開源核心與閉源 Premium 核心：兩者功能並不完全相同，尤其是規則提供器與 TUN。若把兩者混為一談，就容易誤以為「舊版 Clash 完全沒有規則集」等錯誤結論。
| 比較對象 | 需要確認的差異 | 遷移時的影響 |
|---|---|---|
| 原版開源 Clash | 歷史開源分支支援的協定與設定能力 | 不能直接套用 mihomo 的欄位集合 |
| Clash Premium | 歷史上的閉源增強版，曾提供規則集、TUN 等功能 | 部分功能概念相近，但欄位與行為仍須重新確認 |
| mihomo | 原 Clash Meta，擴充協定、規則與網路接管能力 | 保留許多常用寫法，但並非所有舊設定都能原樣執行 |
若直接執行獨立核心，可用 mihomo -v 查看版本。使用圖形介面用戶端時，請在核心資訊或啟動記錄中確認實際載入的執行檔；升級介面程式，不代表已切換至預期的核心。
新增協定：節點能否使用的第一道關卡
相較歷史上的原版 Clash，mihomo 的一項直接改進是支援更多代理協定及其傳輸組合，例如 VLESS、Hysteria2、TUIC。這些並非同一協定的不同名稱，也無法只靠修改設定中的 type 互相轉換。伺服器採用哪種協定，用戶端就必須依照該協定填寫驗證、傳輸與 TLS 參數。
VLESS 與 REALITY 須分開理解
VLESS 是代理協定，REALITY 則是相關連線可採用的安全機制，兩者並非同義詞。VLESS 節點可能使用一般 TLS，也可能採用 REALITY；不同組合還可能涉及 network、servername、flow、reality-opts 等欄位。請依伺服器提供的參數設定，不要看到 VLESS 就自行加入 REALITY 設定。
- UUID：用於設定 VLESS 使用者身分，不能以其他協定的密碼替代。
- 伺服器名稱：
servername與 TLS 握手有關，填錯可能造成憑證或握手錯誤。 - REALITY 參數：公鑰、短 ID 等必須與伺服器端相符；節點名稱相同不代表參數一致。
- 傳輸方式：TCP、WebSocket、gRPC 等設定須在連線兩端一致，不能只修改其中一個欄位。
Hysteria2 與 TUIC 仰賴 UDP 連線
Hysteria2 和 TUIC 使用以 QUIC 為基礎的傳輸方式，連線至伺服器時需要可用的 UDP 通道。即使目前網路能開啟一般 HTTPS 網頁，也不代表這類節點一定連得上。此時應依據記錄檢查逾時、驗證與 TLS 錯誤，而非反覆切換規則模式。
第一代 Hysteria 與 Hysteria2 也不能混用。轉換訂閱時，若將第二代節點輸出為第一代類型，或遺漏必要的驗證參數，改用其他策略組也無法修復。最穩妥的做法是選用訂閱服務明確提供的 mihomo 相容設定，並確認產生的節點類型。
規則集：重複使用規則並掌握比對順序
rule-providers 可將一組規則作為獨立資源管理，再透過 RULE-SET 在主要規則中引用。這並非 mihomo 首創；歷史上的 Clash Premium 也支援類似功能。mihomo 持續擴充這套體系的格式與比對能力，實際可用欄位仍取決於正在執行的核心版本。
先分清三種規則類型
domain：用於網域項目，不要將完整的DOMAIN-SUFFIX,example.org當成一般網域直接填入。ipcidr：用於 IP 網段，例如192.168.0.0/16。classical：使用包含規則類型的項目，例如DOMAIN-SUFFIX,example.org。
以下是本機規則集範例，不含代理節點。請將第一段合併至現有設定，並依核心實際工作目錄解析路徑，確認該目錄中有第二段所示的檔案。這個範例只示範引用方式，不能取代完整的訂閱設定。
rule-providers:
local-direct:
type: file
behavior: classical
format: yaml
path: ./rules/local-direct.yaml
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,DIRECTrules/local-direct.yaml 檔案內容如下，兩個項目分別比對保留的示例網域與私有網段：
payload:
- DOMAIN-SUFFIX,example.org
- IP-CIDR,192.168.0.0/16,no-resolve實際遷移時應保留自己的最終策略，不能照抄範例中的 MATCH,DIRECT，再期待流量經由代理傳輸。規則通常由上而下比對；若將範圍過廣的直連規則放在前面，後續代理規則就沒有機會生效。引用的策略組名稱也必須確實存在，大小寫與空格都須一致。
規則集格式不能任意互換
mihomo 支援的 MRS 二進位規則格式有特定用途，主要適用於 domain 和 ipcidr 類型，不能只把任意 classical 檔案改副檔名就拿來使用。遠端規則集的 interval 以秒為單位，例如 86400 代表一天；這是規則資源的更新間隔，與用戶端訂閱 Profile 的更新週期不同。
TUN 強化：擴大接管範圍，也增加排查層次
系統代理主要影響會主動遵循代理設定的應用程式；TUN 則透過虛擬網路介面與路由接管更多 IP 流量，適合處理不讀取系統代理設定的程式。歷史上的 Premium 也支援 TUN，因此不能簡化成「舊版沒有、新版才有」。mihomo 的重點在於持續維護 TUN 實作、提供網路堆疊選擇，以及支援搭配路由與 DNS 的設定能力。
網路堆疊、路由與 DNS 是三件事
| 設定項目 | 主要用途 | 排查重點 |
|---|---|---|
tun.stack | 選擇 system、gvisor 或 mixed 等支援的處理方式 | 依目前核心與系統的支援狀況為準，不要只看名稱判斷快慢 |
tun.auto-route | 自動設定流量進入 TUN 所需的路由 | 確認是否與現有 VPN、容器網路及自訂路由衝突 |
tun.auto-detect-interface | 自動識別對外網路介面 | 檢查多張網卡或網路切換時，是否選到正確的出口 |
tun.dns-hijack | 接管符合條件的傳統 DNS 請求 | 不能因此認定應用程式內的 DoH 也會自動受到接管 |
在 Linux 下建立 TUN 裝置、修改路由都需要相應權限。圖形介面用戶端可能透過已安裝的特權服務執行這些操作；獨立核心則須自行處理權限與服務管理。遇到權限不足時，請先確認服務狀態、記錄，以及 /dev/net/tun 是否可用；不要反覆切換節點來排查裝置建立失敗的問題。
以下僅列出常見的 TUN 設定片段，須合併至既有的 DNS、節點與規則設定後再測試。這段設定不包含完整的 DNS 監聽設定，也不代表所有裝置都適合直接啟用自動路由。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53設定相容性：能解析不代表行為一致
常見的 proxies、proxy-groups、rules 等結構依然熟悉，但遷移不能只是複製文字。舊欄位可能已有建議用法的變更；新欄位也可能遭舊核心拒絕或忽略。即使語法檢查通過，仍須實際確認 DNS、策略組選擇與程序比對結果。
啟動流量接管前，先驗證設定檔
mihomo -v
mihomo -t -f ./config.yaml第二條指令用於檢查設定，不是完整的網路連線測試。檢查通過後，仍須確認節點握手、DNS 解析與分流結果。若使用圖形介面用戶端，請留意它可能在啟動前合併或覆寫訂閱內容；手動檢查的原始 YAML，可能與實際交給核心執行的設定檔不同。
- 確認監聽連接埠：例如預計使用
mixed-port: 7890，請確認瀏覽器或系統代理也指向本機的 7890，而非舊設定中的其他連接埠。 - 確認控制介面：
external-controller與代理連接埠用途不同。若設定為127.0.0.1:9090，9090 是管理介面，不是瀏覽器連線使用的 HTTP 代理連接埠。 - 確認訂閱內容：只有節點清單的訂閱，不一定包含策略組、DNS 與規則。如何補上這些內容，須查看用戶端的設定合併機制。
- 確認本機覆寫：自訂規則、連接埠與 DNS 應放在用戶端提供的持久化覆寫機制中；直接修改遠端訂閱檔案，可能在更新時遭到覆蓋。
DNS 與程序規則須分別驗證
fake-ip 與 redir-host 是 DNS 處理模式，不是代理模式。切換核心時若同時變更 DNS 模式、上游伺服器與 TUN 開關，就很難判斷問題出在哪一層。建議先沿用原本的 DNS 設定，確認基本連線正常後再逐項調整。
程序名稱、程序路徑等規則，也取決於系統支援、核心權限及能否正確取得連線資訊。即使規則設定正確，也可能因為無法識別程序而未命中。排查時請查看連線記錄中的程序資訊與命中規則；不要把所有未命中情況都歸咎於規則順序。
遷移驗證：每次只變更一個變數
遷移的目標是確認哪些能力獲得補足，以及現有設定是否維持預期行為。建議依照以下順序逐步驗證，每一步都記錄結果再進行下一步，比一次啟用所有強化選項更容易找出問題。
- 備份：保存原有 Profile、本機規則、覆寫設定，以及目前使用的連接埠與 DNS 設定。訂閱網址可能包含存取憑證，請勿將完整內容貼到公開記錄中。
- 基本代理：先關閉 TUN，使用確認可用的節點測試本機 7890 代理入口，排除協定與驗證錯誤。
- 驗證規則：分別造訪應直連與應經代理連線的網站，檢查連線記錄中的命中規則及最終策略，不要只看網頁是否能開啟。
- 載入規則集：確認 provider 的載入狀態；檔案路徑錯誤、下載失敗與項目格式錯誤是不同問題，應依記錄分別處理。
- TUN 接管：最後才啟用 TUN，測試不遵循系統代理的應用程式，並檢查區域網路存取、其他 VPN 與網路切換。
- 更新訂閱：手動更新一次，確認自訂設定仍然保留，再安排自動更新。
是否值得遷移，主要取決於實際需求：若訂閱包含 VLESS、Hysteria2 等節點，或需要更細緻的規則與持續維護的 TUN 功能，mihomo 的優勢就相當明確。若現有連線異常，仍應先分辨是節點故障、設定錯誤或系統網路衝突。更換核心能補足功能缺口，卻不能取代對伺服器參數與本機路由的檢查。