連線疑難排解 · Clash 技術部落格

Mihomo 大型設定載入慢：dialer-proxy 修復

Mihomo 啟動或重新載入大型設定時卡住、記憶體暴增？先確認大量內嵌 proxies 是否使用 dialer-proxy，保留完整設定副本，核對 v1.19.33 修正，再驗證載入、實際請求與還原方式。

閱讀正文回到部落格
  • Mihomo
  • v1.19.33
  • dialer-proxy
  • 設定驗證
  • 記憶體用量
本文目錄
文章作者
Clash 官網
發布日期
預計閱讀
約 8 分鐘

啟動核心或重新載入設定時，CPU 和記憶體突然升高，介面遲遲未就緒；平常代理卻不一定持續占用大量記憶體。出問題的時機比「訂閱很大」更有用：先看是否卡在設定驗證，而不是立刻刪除節點或修改 DNS。

先分清設定載入慢，還是執行期間記憶體持續增加

本文限定 Mihomo 設定中大量內嵌 proxies 設定了 dialer-proxy 的情況。官方 #3315 從真實使用者的大量節點設定，找出驗證成本問題；v1.19.33 已包含對應修正。這不是所有大型訂閱、記憶體增加或用戶端卡頓的共同原因。

依出現時機選擇排查方向

現象優先檢查
啟動、重新載入或 -t 驗證時卡頓，許多 proxies 帶有 dialer-proxy繼續核對實際設定、執行中的核心版本，以及同一份完整副本的驗證結果。
只有開啟系統匣選單或記錄頁面時卡頓先檢查用戶端介面與記錄處理，不把核心驗證修正當成通用解法。
正常執行一段時間後，記憶體持續增加分別記錄連線數、DNS 與執行記錄，與本文載入階段的峰值區分。
直接出現 not found 或 circular dialer-proxy dependency 錯誤先修正不存在的目標或實際循環，升級不會讓無效參照變成有效。

先記下用戶端版本、實際執行的 Mihomo 版本及啟動記錄。桌面用戶端的版本與核心版本是兩回事；命令列的 mihomo -v 也可能執行 PATH 裡另一份程式，必須確認與用戶端目前使用的核心相符。

檢查用戶端最後交給核心的設定，不只看訂閱原文。確認 proxies 中是否有大量項目設定 dialer-proxy，以及參照的出站代理或策略群組是否存在。少量相關項目通常不足以解釋這項驗證成本問題；proxy-providers 不在舊檢查的範圍內，不能只看節點總數就套用結論。

僅示意參照關係，不是可用的節點設定
proxies:
  - {name: relay, type: socks5, server: 127.0.0.1, port: 1080}
  - {name: node-a, type: socks5, server: 127.0.0.1, port: 1081, dialer-proxy: relay}
  - {name: node-b, type: socks5, server: 127.0.0.1, port: 1082, dialer-proxy: relay}

範例中的 relay 是被參照的代理名稱；本機位址與連接埠只是佔位值，不應貼上取代真實訂閱。A 參照 B、B 又參照 A，或項目參照自己，仍屬於真正的循環。目標改名或遭覆寫刪除時，也應先恢復正確參照，而不是刪除 dialer-proxy 來跳過檢查。

用完整副本驗證，並保留還原方式

保持相同條件比較

  1. 先備份原本可用的設定

    將目前設定、覆寫、外部資源及用戶端設定備份到獨立目錄，記下原核心版本與系統代理/TUN 狀態。不要在唯一的資料目錄裡同時升級、更改訂閱及調整 DNS。

  2. 確認測試程式與目錄

    命令列使用者應先確認待測檔案確實存在、內容正確，再將佔位路徑換成完整副本的路徑。-v 查詢版本；-t 會初始化資料目錄，若 -f 指定的檔案不存在，可能產生預設設定，並不是唯讀操作。-d 指定副本的資料目錄，原有相對路徑與必要資源須一併保留；不能只因測試成功就認定已讀取待測設定。

  3. 只測試一次並記錄結果

    選在可以中斷的時段，觀察開始到結束的時間、程序記憶體峰值與第一則錯誤。測試可能消耗資源或讀取外部資源，不保證完全沒有網路存取；若應用程式管理的核心沒有支援的命令列入口，請使用專案提供的設定驗證與記錄，不要強行覆寫或擷取內部程式。

命令列：替換路徑後使用同一份完整副本
mihomo -v
mihomo -t -d "/path/to/complete-copy" -f "/path/to/complete-copy/config.yaml"

更新實際執行的核心，保留循環檢查

v1.19.33 的正式發布記錄列出 #3315 修正。固定標籤的原始碼改為重複利用走訪狀態，避免對每個帶有參照的節點反覆配置大型檢查資料；找不到目標與循環參照的錯誤仍會保留。更新修正的是驗證成本，不會修好設定中的實際參照關係。

依專案支援的方式更新

  1. 先確認更新管道

    獨立核心使用者可從 MetaCubeX/mihomo 的穩定發布管道，選擇符合系統與架構的版本；用戶端使用者請依該專案支援的應用程式或核心更新流程操作，不要任意覆寫服務目錄裡的二進位檔。

  2. 確認更新確實包含修正

    v1.19.33 是本文已核對的正式修正版本。FlClash v0.9.2 的更新記錄明確列出 Mihomo v1.19.33，可作為有來源的例子；其他用戶端須核對各自記錄，不能只因應用程式更新成功就認定核心已替換。

  3. 重新確認執行中的版本

    依專案要求正常重新啟動相關應用程式或核心，再查看實際程序或啟動記錄中的版本。保留原設定與資源副本，首次驗證時不要同時切換節點、更新訂閱或修改 DNS。

同一設定驗證通過後，再測試實際代理請求

驗證清單

  • 已確認實際執行的核心包含 v1.19.33 的 #3315 修正，而不只是更新用戶端介面。
  • 同一份完整副本的 -t 驗證，或應用程式管理核心所支援的驗證入口正常結束，並已確認實際讀取待測設定；在相同裝置、相近負載下比較耗時與記憶體峰值，不套用別人的秒數或記憶體上限。
  • 正常啟動與重新載入後，代理群組、節點選擇及 dialer-proxy 參照仍符合原本設計。
  • 恢復需要的系統代理/TUN 後，對同一目標發出實際 HTTPS 請求並核對連線記錄；設定驗證通過不代表節點一定可用。
  • 若仍出現目標不存在或循環錯誤，依完整錯誤修正設定；若只有處理流量時記憶體持續增加，改查其他原因，不要反覆執行載入壓力測試。

本站未在真實用戶端或路由器上執行本文命令，也不保證特定效能提升倍數。上述比較用來協助讀者判斷自己的設定是否符合已確認的修正情況；網路、裝置記憶體及其他設定問題仍須分別驗證。

更新後仍異常，先恢復可用方案

先保存目前錯誤與設定副本，停止反覆重新載入。依事前記錄，撤銷本輪新開啟的系統代理/TUN 設定，恢復原本可用的連線方式；不要清空所有規則或關閉安全軟體來掩蓋問題。

若升級後發生相容性問題，依該專案支援的方式恢復已知可用的版本，以及相符的設定和資源，避免新舊版本共用唯一的資料目錄。舊版本可能仍有本文的驗證成本問題，不應把還原當成修復；記憶體較少的裝置應優先恢復先前可用的設定，暫緩載入有問題的大型設定。

向專案回報時，提供執行中的核心版本、系統與架構、載入階段、相關項目規模、耗時與記憶體趨勢，以及去識別化的錯誤。分享前移除訂閱權杖、節點密碼、私密金鑰與真實伺服器資訊；盡量只保留重現問題所需的最小參照關係，不公開完整訂閱。

參考資料