前言
如果你也是 Proxmox VE 的長期使用者，大概都有過這樣的經驗：打開 Proxmox 的 Web 管理介面，剛開始一切正常，記憶體佔用看起來很健康。但過了幾天、甚至幾個小時之後，那個分頁的記憶體使用量就像吹氣球一樣——從 200MB 慢慢膨脹到 1GB、2GB，甚至有人回報飆到 4GB 以上。
這個問題從 2013 年就被回報過，到現在 2026 年還沒被官方正式修復。今天我們就來仔細聊聊這個「長青問題」，以及目前能找到哪些解法。
問題全貌：一個從 2013 年延續至今的記憶體黑洞
原始回報（2021 年）
Proxmox 官方論壇上有一個標題為「Proxmox web UI memory leak - starts at 200MB, gradually increases to gigabytes」的討論串（連結 ），由使用者 marcosscriven 於 2021 年 12 月提出。
他的回報重點如下：
- 瀏覽器影響範圍：在 Safari 和 Firefox 上都觀察到同樣的問題
- 作業系統：macOS 和 Windows 都有發生
- 增長幅度：從初始約 200MB，幾天內增長到超過 1GB
- 最嚴重的頁面：Console 和 Summary page 是重災區
- 使用情境：喜歡把這個分頁固定在瀏覽器上，方便隨時監控
Proxmox 的官方員工 dcsapak 回應時，詢問了具體是哪個頁面，並建議用瀏覽器的 DevTools（F12）做 memory allocation profile 來分析記憶體洩漏的具體位置。
Firefox 使用者的災情報告
另一位使用者 rdmitry0911 在 2024 年 3 月補充了一個更驚人的數據：
在 Firefox 上，只開了 Proxmox 的分頁，3 個小時內從 200MB 飆到 2.5GB。但他同時提到，用 Google Chrome 開啟同一個 Proxmox 介面，就沒有這個問題。
這個發現非常關鍵——它暗示了問題可能不是 Proxmox 後端造成的，而是跟特定瀏覽器的 JavaScript 引擎或渲染機制有關。
最新的災情（2025-2026）
到了 2025 年，這個問題依然活躍：
- Ember（2025/04）：在 disks 頁面也觀察到了同樣的記憶體增長
- VivienM（2025/08）：確認 Chrome 上正常，推斷是 Firefox 特定問題
- ReenigneArcher（2026/06 最新回覆）：Firefox 記憶體飆到 4GB+ 依然發生
更早的歷史（2013 年）
這個問題其實可以追溯到 Proxmox 2.2 時代。2013 年 2 月，使用者 mir 在另一個論壇 thread 中回報：
- Chrome 24 上，25 分鐘內從 120MB 飆到 800MB+
- 登入後才會開始洩漏（未登入時維持在 91MB）
- 推測跟 ExtJS framework 和 rickshaw 圖表庫 有關
從 2013 到 2026，跨越了 13 年，這個記憶體洩漏問題依然存在于 Proxmox 的 Web UI 中。
根因分析：到底是什麼在洩漏？
ExtJS 框架的圖表元件
Proxmox 的 Web UI 基於 ExtJS 框架開發，這個框架負責了整個管理介面的渲染。其中最可能的洩漏來源是即時監控圖表（CPU、記憶體、網路、磁碟 I/O 等）。
這些圖表會持續從後端 API 輪詢（polling）最新的系統狀態資料，並在前端不斷更新 DOM 元素。如果圖表元件在更新時沒有正確清理舊的 DOM 節點或事件監聽器，就會造成記憶體洩漏。
為什麼 Firefox 特別嚴重？
多位使用者一致反映 Chrome 沒有這個問題。可能的原因包括：
- V8 引擎的記憶體回收機制更積極，能更有效地回收不再使用的 DOM 元素
- Firefox 的 Gecko 引擎在處理 ExtJS 的某些特定 DOM 操作時，可能有未最佳化的記憶體管理
- Proxmox 的圖表渲染（可能基於 Canvas 或 SVG）在 Firefox 上有已知的效能問題
Console 頁面是重災區
使用者回報，開啟 VM 或 Container 的 Console（終端機）頁面時，記憶體增長最為明顯。這跟 VNC/noVNC 的渲染機制有關——Console 頁面需要持續接收並渲染來自虛擬機端的文字輸出，如果前端沒有正確地截斷過長的輸出歷史，記憶體就會持續增長。
目前找到的解法
解法一：改用 Chrome / Chromium（最推薦）
這是目前最簡單、最有效的解法。多位使用者回報，在 Chrome 或 Chromium-based 瀏覽器（Edge、Brave 等）上，Proxmox Web UI 的記憶體使用量非常穩定，不會有明顯增長。
操作方式：安裝 Chrome 或 Edge，用這個瀏覽器開啟 Proxmox Web 管理介面即可。
解法二：定期重新整理分頁
如果你必須使用 Firefox（比如某些企業環境只部署了 Firefox），可以定期重新整理分頁來釋放記憶體：
- 建議每 2-4 小時重新整理一次
- 或者關閉不需要的 Console 分頁，只保留 Summary page
解法三：減少同時開啟的 Console 數量
每個開啟的 Console 分頁都會持續消耗額外記憶體。如果你同時監控多台 VM 的 Console，記憶體增長會更快。
建議做法：只在需要操作時開啟 Console，用完就關閉。
解法四：用 DevTools 做 Memory Profile
如果你想知道具體是哪些 JavaScript 物件在洩漏記憶體，可以用 Chrome DevTools 的 Memory 面板：
- 開啟 Chrome DevTools（F12）
- 切換到 Memory 標籤
- 點擊 Take heap snapshot
- 等一段時間後再拍一次
- 比較兩次 snapshot 之間的差異
這可以幫你找出到底是哪個元件在持續佔用記憶體。
解法五：等待 pve-manager 更新
Proxmox 的 Web UI 原始碼在 GitHub 上開源。雖然目前沒有專門針對這個 memory leak 的 issue 被標記為已修復，但官方持續在更新 pve-manager。
追蹤方式：定期檢查 pve-manager 的 release notes，看是否有相關修復。
補充：PVE 6.8.12-13 Kernel 的記憶體洩漏
需要特別注意的是，Proxmox 論壇上還有一個不同的記憶體洩漏問題，發生在 kernel 層級：
- 問題：PVE 6.8.12-13 版本的 kernel 會隨著時間持續消耗記憶體，直到系統當機
- 解法：downgrade 到 6.8.12-11 版本即可解決
- 狀態：這是 kernel 層級的問題，跟 Web UI 的記憶體洩漏無關
如果你遇到的是系統整體記憶體持續增長（不只是瀏覽器分頁），建議檢查一下 kernel 版本。
總結
Proxmox Web UI 的記憶體洩漏是一個從 2013 年延續至今的長青問題，已經超過 13 年還沒被官方正式修復。雖然 Proxmox 的開發團隊持續更新 pve-manager，但這個問題似乎因為「影響範圍有限」（只有部分使用者、特定瀏覽器）而沒有被優先處理。
目前最實在的建議：
- Firefox 使用者：考慮安裝 Chrome 或 Edge 來開啟 Proxmox Web UI
- Chrome 使用者：恭喜，你目前沒有這個問題
- 長期開啟 Console 的使用者：用完就關，不要讓它一直開著
- 追求完美的使用者：用 DevTools 做 memory profile，追蹤最新 pve-manager 版本是否有修復
希望 Proxmox 團隊未來能正式修復這個問題，畢竟一個管理介面不應該因為開啟幾天就吃掉好幾個 GB 的記憶體。