本文目錄
記憶體增加時，先分清增加的是 Clash Party 應用程式還是 Mihomo 核心，再比較是否由開啟日誌頁觸發。以下在同一環境記錄趨勢，並說明已撤銷的日誌啟停方案為何不能當作正式修復。暫時重新啟動、安全更新與日誌頁重測各有目的，不能用其中一項結果代替其他判斷。
離開日誌頁後，記憶體為什麼還在漲？
Clash Party 啟動後原本穩定，開啟一次日誌頁後記憶體持續增加，切到其他頁面也不停，這與專案 issue #1976 中的意見回饋一致。Windows、macOS 和 Linux 使用者均報告過相似現象，涉及 1.9.6 和 2.0.0。
日誌頁透過即時連線接收資料，離開頁面不一定表示連線已停止。專案曾提出在離開頁面時停止介面監聽和主處理程序的日誌 WebSocket，但這項變更後來被撤銷。日誌連線持續存在，不能單獨證明記憶體增加的原因，仍須比較應用程式與核心的趨勢。
如果記憶體從啟動時就上漲，或只有 Mihomo 核心上漲，應另查核心、連線和設定。判斷依據是同一環境中的持續趨勢；短時峰值和其他使用者的記憶體數值，都不能單獨確定原因。
比較開啟日誌頁前後的記憶體趨勢
測試前固定同一份設定、節點、網路和代理模式，不要一邊換規則一邊觀察記憶體。Windows 可用工作管理員，macOS 可用活動監視器，Linux 可用系統監視器；重點是分別記錄 Clash Party 應用處理程序組和 Mihomo 核心，而不是只看整機已用記憶體。
不需要一直盯著日誌內容，也不需要製造大量連線。用一個平時能穩定存取的網頁維持普通使用，就足以比較「從未進入日誌頁」和「進入後再離開」兩段趨勢。
完成一次可重複的前後對照
完整退出後重新啟動
從系統匣選單退出 Clash Party，確認應用及其子處理程序已經結束，再重新開啟；先不要進入日誌頁。
記錄開啟日誌頁前五分鐘的記憶體用量
在相同網路活動下，每分鐘記錄一次應用處理程序組和 Mihomo 核心的記憶體，避免用單個瞬時數值下結論。
開啟日誌頁一次
停留約一分鐘，讓頁面收到實時日誌；隨後切到首頁或代理頁，不要清空日誌、換設定或重啟核心。
再觀察五分鐘
繼續記錄同一組處理程序。若離開日誌頁後應用側仍連續上漲，而核心趨勢沒有同步變化，證據更接近已知問題。
按記憶體變化選擇檢查方向
| 觀察到的現象 | 更可能的範圍 | 下一步 |
|---|---|---|
| 兩段趨勢相近，而且都沒有持續上漲 | 目前沒有復現日誌頁問題 | 目前沒有復現，不需要為這個 issue 更換版本或改設定。 |
| 開啟日誌頁後持續上漲，離開頁面也不停 | 與官方 issue 的觸發方式一致 | 完整退出後重新測試，並暫時避開日誌頁 |
| 從啟動開始就上漲，是否開啟日誌頁都一樣 | 可能另有連線、快取、規則或核心問題 | 分別觀察桌面應用與 Mihomo 處理程序，不直接歸因於日誌頁 |
| 只有 Mihomo 核心處理程序上漲，介面處理程序穩定 | 問題可能在流量、規則或核心 | 記錄核心版本、執行設定、規則模式與連線數量，轉向核心側檢查 |
| 開啟日誌頁時短暫增加，離開後很快穩定 | 可能是頁面正常載入 | 延長觀察，但不要把短時峰值當成洩漏 |
Issue 中既有數百 MB 增至數 GB 的意見回饋，也有緩慢上漲的意見回饋。機器、執行時間與日誌量不同，不能用一個固定數值判斷。
- Mihomo 核心持續產生執行日誌
- 主處理程序日誌連線透過 WebSocket 接收實時日誌
- 介面監聽器把日誌事件傳送給渲染頁面
- 日誌頁顯示、篩選並保留目前日誌
圖示說明曾提出的日誌啟停方案：離開日誌頁時停止介面監聽和主處理程序的日誌連線。這項變更後來被撤銷，不能據此認定目前正式版已解決記憶體用量增加。
暫時無法升級時，怎樣規避日誌頁問題
暫時無法升級時，可以完整結束 Clash Party，再重新啟動並避開日誌頁。Issue 中有使用者回報，重新啟動應用程式可讓已增加的記憶體用量回到正常起點。這只結束目前的應用程式工作階段，不能據此認定記憶體增加的原因，也不是永久修復。
恢復原設定並避開日誌頁
記下目前設定
記錄目前 Profile、代理模式、系統代理和 TUN 狀態，不刪除訂閱或覆寫。
從系統匣完整退出
關閉主視窗可能只是收進系統匣。使用系統匣退出選單，確認 Clash Party 及相關介面處理程序結束；若仍有處理程序停留，等待正常退出，不隨機結束其他系統處理程序。
重新啟動並恢復代理
若系統代理或 TUN 沒有自動恢復，按原設定關閉它們並確認直連正常，再啟動用戶端。使用原設定存取同一測試網頁，確認節點、規則和連線仍正常。
保持日誌頁關閉
在首頁、代理頁和連線頁完成日常操作，再觀察十分鐘，確認記憶體不再沿原趨勢增加。
日誌啟停變更已撤銷，更新時應看哪些依據？
v2.0.0 發布說明包含其他記憶體相關調整，但專案維護者在 2026 年 8 月 7 日明確說明：v2.0.0 尚未包含日誌頁的這項修復。看到「記憶體修復」字樣時，要繼續核對具體提交和發布版本。
截至 2026 年 8 月 10 日，穩定版仍為 v2.0.0。v2.0.1 於 2026 年 8 月 11 日發布，但 6cbd24e 已撤銷 5532a851 的變更。v2.0.1、v2.0.2 和 v2.0.3 標籤都未保留依日誌頁啟停的實作，不能只看提交歷史就認定已修復。
v2.0.1 的發布說明沒有單獨點名日誌頁記憶體問題。實際更新前保留設定備份；更新後仍按第二節的方法重新測試，不能只以新版本能啟動判斷恢復。
不同版本選擇的邊界
| 選擇 | 能解決什麼 | 需要接受的限制 |
|---|---|---|
| 升級到 v2.0.3 或後續穩定版 | 取得 rule-providers 安全修復及正式說明列出的資源洩漏修正；日誌頁相關現象仍須另外測試。 | 仍需用同一設定和負載完成前後對照 |
| 暫時無法升級 | 完整結束後重新觀察；只有對照顯示與日誌頁有關，才將避開該頁作為暫時處理。 | 這不能替代 v2.0.3 的安全更新；升級前避免匯入不可信設定 |
| 舊版 1.9.6 或 v2.0.2 | 不能作為建議的還原方案，也不能據此認定日誌頁問題已修復 | 也不包含 v2.0.3 的 rule-providers 安全修復 |
更新後的重新測試、異常處理與意見回饋
更新後沿用相同設定、節點、網路和代理模式，按第二節的方法比較日誌頁開啟前後的記憶體趨勢。
升級後的驗收結果
- 離開日誌頁後，Clash Party 應用側記憶體不再持續上漲
- 訂閱、策略群組、系統代理或 TUN 仍能完成實際網頁請求
- 使用時 Mihomo 轉發正常，完整退出後系統網路能夠恢復
如果升級後打不開、設定遷移異常或代理不可用，先完整退出並保留現有資料目錄；關閉系統代理與 TUN 恢復直連，再從 Clash Party 官方 Release 重新安裝 v2.0.3 或後續穩定版，匯入此前驗證過的設定備份。
不要為了恢復日誌頁行為降級到 v2.0.2 或更早版本：這些版本不能證明包含 rule-providers 命令注入修復。若仍無法執行，保持用戶端停用並記錄錯誤，等待官方相容修復。
繼續意見回饋時，提供作業系統、Clash Party 與 Mihomo 版本、是否開啟過日誌頁、兩段觀察時長，以及應用側和核心側的起止記憶體。不要用一張峰值截圖代替前後對照。
日誌和設定只分享脫敏片段，移除訂閱連結、節點密碼、控制器 secret 與私人網域，不公開完整日誌或設定。