本文目錄
修改入站設定後，連線已經停止，Mihomo 的 CPU 使用率卻遲遲不降；再改一次，閒置時的使用率甚至更高。這時要分清「載入設定時暫時忙碌」與「監聽器關閉後仍在空轉」，先確認是哪個處理程序忙碌，以及剛才究竟關閉了哪個入口。
沒有流量，為何重新載入後 CPU 仍降不下來？
官方 #3314 記錄的是舊式串流加密的 Shadowsocks 入站關閉問題：變更或移除相關 listeners 項目，或變更 ss-config 後，舊監聽器的接收迴圈可能沒有結束。即使沒有流量，仍會持續消耗 CPU；重複觸發相同的關閉操作，還可能累積更多未結束的迴圈，而且不一定出現錯誤日誌。
這與代理節點緩慢、一般 SS 出站失敗或所有重新載入卡頓的情況不同。v1.19.33 已包含對應修正；若未使用這類入站，或只有在正常傳輸流量時才出現高使用率，就不能直接套用本文判斷原因。
依處理程序與發生時機區分
| 觀察到的現象 | 接著應檢查什麼 |
|---|---|
| 相關 SS 入站關閉後，實際 Mihomo 處理程序的閒置 CPU 持續偏高 | 核對入站類型、加密演算法、執行中的核心與關閉時間。 |
| 只有載入大型設定時短暫升高，載入完成便回落 | 檢查設定驗證的處理成本，不要誤判為監聽器關閉後仍在空轉。 |
| 用戶端介面忙碌，Mihomo 處理程序的使用率正常 | 檢查介面、系統匣或日誌處理。 |
| 沒有相關入站，或只在轉送大量流量時升高 | 記錄當時的工作負載並查找其他執行原因，本文無法確認根本原因。 |
先找入站設定，別把訂閱中的 SS 節點算進去
入站是其他程式或裝置連到這個 Mihomo 執行個體的入口；出站則是 Mihomo 連到外部服務所使用的代理節點。
先檢查用戶端最後交給核心的設定，在 listeners 中尋找 type: shadowsocks，並核對其 cipher；舊式簡寫入口則查看最上層的 ss-config。僅在 proxies 中看見 type: ss，並不足以符合本題條件。
本題的串流加密演算法範例包括 aes-128-ctr、aes-256-cfb、rc4-md5、chacha20、chacha20-ietf 和 xchacha20。
v1.19.33 固定版本原始碼將這些相容演算法交給內嵌監聽器實作；none、AEAD 與 2022 加密演算法使用另一套實作，不在這項關閉缺陷的範圍內。不能因為名稱相近，就把 chacha20-ietf 與 chacha20-ietf-poly1305 歸為同一類。
目前 Wiki 的常用入站加密演算法表，並未將上述舊式串流演算法列為新設定選項。本文依固定版本原始碼說明既有設定的相容處理方式，不建議為了重現問題而建立舊加密入站。也不要只在單邊更改 cipher，使用這個入口的另一端必須相符。
先從既有故障保留這些證據
- 分別觀察 Mihomo 與介面處理程序，確認高 CPU 屬於哪個實際執行個體。
- 記錄用戶端版本、執行中的核心版本及啟動方式，不要只寫「最新版」。
- 保留相關 listeners 或 ss-config 變更前後的副本，記錄原入站類型、cipher 與關閉時間。
- 確認故障是否緊接相關入站變更、移除或關閉而發生，而不是任意一次無關的重新載入。
- 原始設定保留在本機；公開回報前移除入站密碼、訂閱權杖、私密金鑰與伺服器資訊。
先備份可用設定，別再反覆熱重載
先另外備份正在使用的完整設定、覆寫、外部資源與用戶端設定，記錄目前核心版本、系統代理及 TUN 狀態。若這個入站仍提供其他裝置連線，請先安排可中斷連線的時段，並保留不依賴它的管理方式。排查期間不要同時更新訂閱、修改 DNS 或清空整個資料目錄。
已經出現空轉時，不要反覆刪除、加入入站來「清理」。舊版缺陷發生在監聽器關閉後，繼續熱重載可能再次觸發。暫時恢復時，應使用應用程式或服務所支援的正常停止方式，確認對應的舊執行個體確實結束，再啟動事前驗證可用的設定。關閉視窗、停用 TUN 或看不到連線，都不能代替確認處理程序已結束。
不必為了本文在舊版上反覆製造故障，也不必開放 external-controller 或複製官方重現與重新載入腳本。設定測試 -t 通過，只能證明對應的設定檢查完成，無法證明執行中的監聽器關閉迴圈已修復。
取得修正後，完整重啟實際執行的核心
Mihomo v1.19.33 正式發布記錄列出修正提交 349af19。固定標籤的 listener/shadowsocks/tcp.go 在 Close() 開始時，先設定 closed 再關閉監聽器；接收迴圈遇到關閉錯誤時才會結束。這是修正關閉處理，並非降低 CPU 上限或更改節點測速。
讓實際執行個體使用修正
採用原專案支援的穩定更新方式
獨立核心應從 MetaCubeX/mihomo 正式發布中，選擇符合系統與架構的版本；圖形介面用戶端則依該專案支援的應用程式或核心更新流程操作，不要任意覆寫服務目錄內的二進位檔。
確認更新確實包含 349af19
v1.19.33 是本文已核對的正式修正版本。FlClash v0.9.2 更新記錄明確包含 Mihomo v1.19.33，可作為有來源的範例；其他用戶端與核心分支仍須另查各自記錄，不能只比較介面版本號。
正常停止舊執行個體，再啟動更新後的執行個體
保留設定與資源副本，依應用程式或服務要求正常重啟，確認舊執行個體結束、新執行個體的啟動日誌顯示預期核心。不能只因換了設定，就認定留在舊處理程序中的迴圈已消失；只更新檔案卻未結束舊處理程序，也不代表修正已實際執行。
mihomo -vmihomo -v 顯示的是目前指令呼叫到的程式，可能只是 PATH 中另一個同名檔案，必須與服務或用戶端實際使用的核心一致。由應用程式管理的核心，應優先查看專案提供的版本資訊與啟動日誌，不要只為查詢版本而強行取出內部程式。
閒置使用率、後續重新載入與實際連線都要檢查
在相同裝置、相同設定與相近背景活動下，比較完整重啟前後的 Mihomo 處理程序使用率。先暫停經過這個執行個體的測試流量，觀察一段閒置時間，再恢復實際工作；啟動瞬間或真正傳輸流量時的峰值，不能當成關閉後持續空轉的證據。
只有修正已實際執行，且環境允許短暫斷網時，才進行原本需要的入站變更、移除與恢復。若實際工作需要多次這類重新載入，應分別記錄每次之後的閒置 CPU，確認不會隨相關關閉次數繼續上升；不必為了湊次數而反覆開關舊版或製造高負載。
驗收結果
- 已確認實際執行核心包含 349af19，舊執行個體已結束。
- 停止測試流量後，核心回到接近原先正常閒置狀態的使用率，沒有持續空轉；不要套用別人的 CPU 百分比。
- 後續確實需要關閉或變更這個入站時，不再出現相同的持續高使用率或逐次累積。
- 恢復所需入站後，原先合法的用戶端能重新連線，並完成真正的 HTTPS 請求；規則、出站與連線記錄符合原本設計。
- 系統代理或 TUN 只依原用途恢復；結束或停用後，裝置仍可回到事前記錄的網路狀態。
本站未在真實用戶端、路由器或伺服器上執行本文的重現操作，也不承諾特定效能倍數或零 CPU。以上是根據官方缺陷、固定原始碼與修正記錄擬定的檢查步驟；實際網路、其他高使用率原因與用戶端整合仍須分別驗證。
仍有異常就恢復可用方案，保留最小回報資料
若更新後無法開啟、入站無法連線或設定不相容，先保存第一個錯誤與目前副本，停止繼續重新載入。依專案支援的方式還原事前驗證可用的程式版本、相符設定與外部資源，避免新舊程式共用唯一的資料目錄；系統代理與 TUN 則按原記錄恢復至可用狀態。
舊版本可能仍有本題缺陷，還原舊版只是應急，不能當成修復。若需要暫時停用有問題的入站，先確認依賴它的連線與管理入口，正常停止對應執行個體後，再使用已驗證可用的設定；不要只在仍空轉的舊處理程序中刪除項目，然後繼續熱重載。
若仍會復發，請向專案提供系統與架構、實際執行核心、入站類型與 cipher、造成關閉的具體操作、相同條件下的閒置 CPU 趨勢，以及完整重啟與後續重新載入的差異。缺少這些前提時，應保留為原因未明，不把所有高 CPU 都歸因於 #3314。公開資料只保留重現問題所需的最少設定關係，以及已移除敏感資料的錯誤訊息，不上傳完整訂閱或密碼。