✨ Beszel 深度開箱：10MB 記憶體打天下的監控神器，還是你不該碰的 Docker Socket 未爆彈？

🔥 一句話總結懶人包：

Beszel 是 2026 年在自架圈竄紅的輕量伺服器監控工具，Agent 只吃 10-25MB 記憶體、Hub 也才 30-45MB，GitHub 已累積 23.5k 顆星星，用 MIT 授權完全免費開源。它用五分鐘部署、零學習曲線的姿態，把「一台平價 VPS 該不該裝監控」這個長年被 Prometheus 高門檻勸退的問題直接解決掉。但它同時也曾經爆出Docker API 路徑穿越與底層框架認證繞過兩個高風險 CVE，加上預設要求掛載 /var/run/docker.sock，適合個人與小團隊自架，企業要導入核心生產環境前務必三思 ⚠️

你是不是也這樣過：VPS 上跑了七、八個 Docker 容器，某天網站突然變得像牛步一樣慢，你火急火燎地 SSH 進去，一個指令一個指令下 docker stats、htop、df -h，像在夜市攤位前東問西問，才終於抓到是哪個容器把記憶體吃光了。等你搞定，客戶的 Line 已經連環叩了三次 🤬

這種「事後救火」的窘境，幾乎是每個自架玩家的共同記憶。網路上最常被推薦的解法是 Prometheus 搭 Grafana，聽起來很專業，但真正動手架設過的人都知道，那套系統光是 scrape_configs、node_exporter、cadvisor 這些名詞就足以讓一個週末泡湯，架好之後監控系統本身還要吃掉 500MB 以上的記憶體——比你要監控的服務本身還肥 🤦‍♂️

Beszel 的出現，就像是專門為「只有三到三十台機器、沒有專職 SRE 團隊」的個人與小團隊量身打造的解方。今天這篇文章，會把官方文件、GitHub Issues、Reddit 討論串跟資安機構的 CVE 紀錄一次爬梳清楚，讓你在動手安裝前，先搞懂它的能耐與地雷藏在哪裡 💪

🌐 Beszel 官方 GitHub 專案 ^[26]

^[27]

---

📌 Beszel 到底是什麼？先搞懂 Hub 跟 Agent 這對搭檔

Beszel 是一位獨立開發者 henrygd（社群暱稱 Hank）主導的開源專案，用 Go 語言寫成，底層資料庫仰賴同樣走紅的開源框架 PocketBase。它解決的問題非常單純：讓你在不學 PromQL 查詢語法、不啃厚厚說明書的情況下，一眼看出「我的伺服器現在正不正常」🤠

相較於 Prometheus 動輒五百 MB 起跳的資源消耗，Beszel 的閒置 CPU 佔用甚至低於 0.1%。這種「克制」正是它在 2026 年能從幾千顆星快速衝到 23.5k 顆星的原因——它沒有想取代 Prometheus，而是專心把「小規模自架的日常監控需求」做到極致 😎

💡 碎碎念：為什麼 Prometheus 對小規模 VPS 是殺雞用牛刀？

Prometheus 的設計目標是「服務數量隨時在變動、指標動輒上百萬條」的動態容器化叢集場景。如果你只有幾台固定的 VPS，根本用不到服務探索（Service Discovery）、也不需要 PromQL 跑高維度聚合分析，更不需要三十天以上的高解析度歷史資料。這就像叫一台貨櫃輪去載你去便利商店買飲料，馬力用不完，油錢倒是燒得心疼 📉

^[28]

---

🛡️ 核心功能全解析：官方宣傳 vs 實際能耐

Beszel 的功能可以拆解成四大主軸：系統基礎資源監控、容器深度解析、硬體進階感測，以及自動化警報推播。以下用表格把「說了什麼」與「實際做不做得到」攤開來看：

但別被官方文宣沖昏頭，我們也挖出了三個「跟新手期待有落差」的地方：

• ⭐ 缺乏外部站點監控能力：Beszel 只能監控主機內部的資源耗用，它無法告訴你「網站是否從外部無法連線」。很多新手誤把它當成 Uptime Kuma 的替代品，結果網站已經對外 502 了，Beszel 儀表板上卻是一片綠燈，因為主機本身好好的，只是網站服務掛了 🛑
• ⭐ 沒有日誌聚合功能：Beszel 是純粹的「指標（Metrics）」收集器，收到 CPU 過載警報後，你沒辦法點進去看應用程式的錯誤日誌。要查日誌得另外搭配 Dozzle 或 Loki 📝
• ⭐ S.M.A.R.T. 資料有滯後性：預設每小時才收集一次硬碟健康度，硬碟溫度異常的警報可能會有長達一小時的延遲 🚨

^[29]

---

📜 系統需求與依賴風險：輕量的代價是什麼？

先看硬體需求，這是 Beszel 最亮眼的招牌：

但身為部落客，我們不能只講好聽的。以下是資安層面必須嚴肅指出的三個風險：

🧑‍🔧 DevOps 小知識：Docker Socket 掛載的潛在威脅

為了讀取容器狀態，Agent 容器部署時預設要求掛載宿主機的 /var/run/docker.sock。在資安實務上，把 Docker Socket 唯讀權限交給任何容器，等同開了一扇直通宿主機核心的後門。若 Agent 遭遇 0-day 漏洞利用，攻擊者理論上可繞過容器隔離，直接操縱宿主機的 Docker 守護行程。若特別在意這一點，官方社群討論串建議在 Agent 與 Docker Daemon 之間插入 docker-socket-proxy 容器，並封鎖 POST 等寫入權限，物理閹割 Agent 惡意修改宿主機的能力 ⚠️

另外，S.M.A.R.T. 硬碟監控在 Linux 環境下，Agent 必須取得 CAP_SYS_RAWIO（針對 SATA 硬碟）與 CAP_SYS_ADMIN（針對 NVMe 硬碟）的核心特權，或強制修改 udev 規則。這種過度膨脹的權限設定，某種程度上違反了「最小權限原則」，也是後面會提到的真實使用者痛點之一 😖

值得肯定的是，Beszel 的通訊認證機制設計得相當聰明：它採用非對稱的 Ed25519 SSH 金鑰搭配 WebSocket 通用令牌進行雙向認證。Hub 產生一組公私鑰對，只把「公鑰」交給 Agent，即使單一伺服器上的 Agent 被駭客攻陷，駭客也拿不到能控制中控 Hub 的私鑰 🔑

^[30]

---

🛡️ 兩種連線模式：Hub 主動連 vs Agent 主動連

裝 Agent 之前，先在 Hub 介面點「Add System」，畫面會給出公鑰、Token 與 Agent 預設監聽的 45876 埠。接下來有兩種部署模式，差別在「誰主動連誰」：

• ❶ 模式一：Hub 主動連 Agent（適合公開 IP 環境）：Agent 開 45876 等 Hub 來連，需要設定 network_mode: host，否則 Agent 抓到的網卡會是 Docker 虛擬橋接，流量數字會全部算錯。防火牆規則務必只放行給 Hub 的 IP，不要開給全世界 ✨
• ❷ 模式二：Agent 主動連 Hub（WebSocket，適合 NAT 後方機器）：Agent 卡在 NAT 後面、沒公開 IP 的情境用這個，加一個 HUB_URL 環境變數即可，所有流量走 443 通過任何企業防火牆都沒問題 💯

比較進階的細節是：Agent 實際上會同時維護「WebSocket 主連線」與「SSH 備援通道」雙路徑。當 WebSocket 因為反向代理重啟等原因斷線時，Agent 會自動在 45876 埠開啟 SSH 監聽，讓 Hub 改用備援路徑連回來，指標不會中斷。這個備援機制搭配 Ed25519 金鑰互相驗證與伺服器指紋比對，確保只有原本配對的 Hub 跟 Agent 能夠對話 💡

🫂 新手求助：安裝卡關先看這裡

官方文件（Agent Installation ^[31]）列出了 Docker、Podman、單一執行檔、Homebrew、WinGet/Scoop 五種安裝方式，多數自架玩家用 Docker Compose 最省事。若卡在「找不到系統」，優先檢查 network_mode: host 有沒有設對，以及防火牆是否放行 45876 埠給 Hub 的 IP。GitHub Discussions 區的社群回覆速度相當快，遇到冷門硬體或作業系統問題也可以先去搜尋既有討論串 🫶

^[32]

---

🚀 四種真實使用情境：你該不該裝？

💪 一般輕量使用者（Homelab 玩家）——適合度：高

情境：你在家裡客廳擺了一台安裝 Proxmox 的微型主機，裡面跑著 Nextcloud、Jellyfin 等數十個容器。不需要企業級的 SLA 追蹤，只想每天下班後打開手機瀏覽器，確認硬碟沒快壞掉、CPU 溫度沒有飆破警戒線 📌

Beszel 消耗不到 50MB 記憶體，五分鐘就能部署完成，是這類情境的完美解方。完全免費、MIT 授權，小資族完全不用擔心荷包縮水 😎

💬 獨立開發者與自架玩家（DevOps）——適合度：中

情境：你維護著二十台散佈於不同雲端廠商的 VPS 節點，用 Ansible 腳本搭配 Beszel 的通用令牌，實現一鍵派發 Agent 並自動於 Hub 註冊。某台客戶機器 CPU 異常飆高時，Discord 頻道自動跳出警報，讓你在客戶抱怨前先行處理 💡

部署複雜度不高，跟現有 Docker 技術棧完全相容，值得自架。但一定要做好反向代理 HTTPS，並考慮用 docker-socket-proxy 降低容器逃逸風險 ⚠️

🏢 企業商業用途——適合度：低（需嚴格條件）

情境：一間中小型公司想用 Beszel 監控客戶伺服器，MIT 授權讓商業使用沒有法律障礙，也可以直接包裝成付費監控服務對外銷售 📌

但基於 缺乏細顆粒度權限管控（RBAC），難以符合 SOC2 稽核追蹤要求，加上底層 PocketBase 框架曾爆發供應鏈漏洞，不建議將 Beszel 部署於需符合 SOC2、HIPAA 或嚴格金融法規的核心生產環境。若一定要用，務必透過內部 VPN 限制存取，絕不對外公開 IP，並封鎖容器名稱中出現客戶個資（例如 db_client_xyz_production 這種命名方式，本身就有洩漏 PII 的風險） 🚨

🚨 高風險誤用場景：忘記設密碼的未爆彈

🚨 畫重點！千萬別踩雷：部署完 Beszel Hub 之後，請立刻開啟網頁完成初始管理員帳號設定，且強烈建議不要直接暴露 8090 通訊埠，一律透過 Caddy 或 Nginx Proxy Manager 反向代理並加上 HTTPS 加密 💣

^[33]

---

🔐 隱私與資料安全：曾經爆發過的三個 CVE

Beszel 會巨細靡遺蒐集主機的底層指紋：完整的 CPU 型號、系統核心版本、每個網路介面的 MAC 與 IP 數據、硬碟精確分割區大小，以及所有運作中 Docker 容器的精確名稱與狀態。這代表如果你的容器名稱裡包含客戶名稱，這些商業機密也會被集中蒐集儲存在 Hub 的 SQLite 資料庫中 🤧

經查證國家弱點資料庫（NVD）與 GitHub 安全公告，Beszel 及其底層依賴曾爆發過三起具實質威脅的漏洞：

💡 碎碎念：資安漏洞處置態度值得肯定

當 CVE-2026-27734 被回報時，維護者 henrygd 在極短時間內於 v0.18.4 釋出修補程式，並進一步強化格式驗證邏輯。查無任何維護者信任危機、道德爭議或內部團隊分裂紀錄的跡象，社群成員甚至主動協助分類數百個 Issues，整體生態圈相當健康 👍

企業機密資料適合透過此工具處理嗎？基於上述頻繁出現的權限繞過與路徑穿越漏洞，以及掛載 Docker Socket 的架構設計，強烈不建議將 Beszel 部署於需符合 SOC2、HIPAA 或嚴格金融法規的核心生產環境 🆖

^[34]

---

📜 授權條款與法律合規：MIT 對商業極度友善

Beszel 及其官方 Agent 元件均採用極度寬鬆的 MIT License 授權條款：

• 個人自架：無任何合規負擔，可自由修改原始碼、移除官方 Logo 或深度客製化儀表板 ✨
• 商業 SaaS 對外提供：極度友善，企業可將 Beszel 部署在雲端環境並作為「加值付費服務」販售，只要保留原作者版權聲明與 MIT 許可證副本即可 💯
• 整合進閉源產品：完全合法。與有傳染性的 GPL／AGPL 不同，硬體製造商可將 Agent 內嵌在自己的黑盒一體機韌體中出貨，不必開源自家商業程式碼 💡

法律灰色地帶主要出現在 歐盟 GDPR 與台灣個資法 這一塊：如果開發者習慣把客戶姓名或可識別性個人資料當成 Docker 容器命名規則（例如 database_john_doe），這些個資會被未經驗證地集中傳輸並儲存在 Hub 的 SQLite 資料庫中，在嚴格的資料稽核中可能被判定為未授權的 PII 傳輸 ⚠️

🩵 荷包試算：完全免費，但隱形成本不是零

Beszel 本身 0 元、MIT 授權沒有訂閱費用，這點跟需要付費雲端方案的 Netdata（超過 5 台節點需付費）比起來佛心很多。但自架仍需計算 VPS 租金（NT$150-300／月起跳，視規格）與你自己的維護時間成本。若只是想要「裝了就不用管」的體驗，記得把反向代理與 HTTPS 設好，否則多出來的資安事件善後成本，遠比省下的訂閱費用還貴 📉

^[35]

---

😤 真實使用者痛點：GitHub Issues 挖出來的四大摩擦點

剝去「輕量、好用」的行銷包裝，我們深入挖掘 GitHub Issues 與 Reddit 社群討論，整理出使用者在真實部署中遭遇的痛苦：

• ㊀ S.M.A.R.T. 硬碟權限地獄：這是被無數進階使用者抱怨的痛點。為了解析硬碟底層資訊，Agent 必須以極高特權運行，但在啟用 SELinux 的 Fedora、TrueNAS 或 Unraid 等高度鎖定系統上，經常導致 Permission denied 或 exit status 2 的報錯。使用者被迫手動編寫 udev 規則更改 /dev/nvme0 的群組擁有權，對不熟悉 Linux 核心機制的人是一場災難 😖
• ㊁ Windows 生態系支援粗糙：官方提供的 .exe 執行檔未經微軟數位簽署，常遭 Windows Defender 攔截。當使用者試圖用 WinGet 搭配 Ansible 自動化佈署時，安裝腳本仍強制要求互動式輸入 SSH Key，導致自動化部署流程卡死 🚫
• ㊂ Kubernetes 叢集逾時斷線：當 Hub 部署在 Kubernetes 叢集並透過 Nginx Ingress 暴露服務時，Agent 與 Hub 的 WebSocket 連線會頻繁中斷，出現大量假警報。官方文件把解法（手動添加 proxy-read-timeout: “3600” 標記）深埋在進階部署章節，導致初期除錯極為困難 🚨
• ㊃ 記憶體計算跨平台差異：在某些非主流架構（如 aarch64 的 OpenWrt 路由器），環境變數 MEM_CALC=htop 會被無聲忽略，顯示的記憶體使用量與實際狀態脫節，說明開發者在邊緣架構上的測試還不夠周全 📉

^[36]

---

🔄 替代方案冷酷比較：該選誰？

🌳 選擇建議決策樹

• ✨ 需要追蹤 Kubernetes 叢集微服務、處理百萬級指標、有專職 SRE 團隊 → 選 Prometheus + Grafana 🎯
• ✨ 只在乎「網站現在外部連得上嗎」→ 選 Uptime Kuma 💡
• ✨ 家中或雲端幾台平價 VPS，只想用最少資源確認硬碟沒壞、Docker 容器沒卡死 → 選 Beszel 📌

2026 年自架圈的最佳實踐，其實是組建「輕量鐵三角」：用 Beszel 監控硬體、用 Uptime Kuma 監測外部連線、用 Dozzle 查閱容器日誌，整體資源消耗極低且完美互補 💪

^[37]

---

🛡️ 綜合風險評級：不同族群該注意什麼

^[38]

---

🏆 總結評分

🔥 加權綜合分數：約 7.9／10

最終建議：【強力推薦，但企業級應用請三思】

Beszel 完美體現了「少即是多」的系統設計哲學。在一個監控軟體動輒吞噬數百 MB 記憶體、需要花半天學查詢語法的年代，它用不到 25MB 的極致輕盈姿態，優雅解決了多數個人與小團隊在日常監控上的核心需求。只要妥善設定反向代理、立刻完成初始帳號設定，並視需求導入 docker-socket-proxy 降低風險，Beszel 絕對值得放進你的自架工具箱。但若你的組織需要符合 SOC2、HIPAA 等嚴格合規要求，這款工具目前還不是你該選的答案 🧐

^[39]

---

💪 附錄：安裝步驟完整教學

📝 第一步：部署 Beszel Hub（控制中心）

挑一台有對外網域、有反向代理的 VPS 當 Hub，建立工作目錄後建立 docker-compose.yml：

services:</code>
<code>  beszel:</code>
<code>    image: henrygd/beszel:latest</code>
<code>    container_name: beszel</code>
<code>    restart: unless-stopped</code>
<code>    ports:</code>
<code>      - 8090:8090</code>
<code>    volumes:</code>
<code>      - ./beszel_data:/beszel_data</code>
<code>      - ./beszel_socket:/beszel_socket</code>
<code>    environment:</code>
<code>      APP_URL: https://beszel.example.com

啟動容器：

docker compose up -d

開瀏覽器到 http://伺服器IP:8090，第一個註冊的帳號會自動成為管理員。請務必立刻完成這一步，不要拖延 🚨

📚 第二步：部署 Agent（模式一：Hub 主動連 Agent）

適合 Hub 與 Agent 都在同機房、或 Agent 有公開 IP 的情境：

services:</code>
<code>  beszel-agent:</code>
<code>    image: henrygd/beszel-agent:latest</code>
<code>    container_name: beszel-agent</code>
<code>    restart: unless-stopped</code>
<code>    network_mode: host</code>
<code>    volumes:</code>
<code>      - ./beszel_agent_data:/var/lib/beszel-agent</code>
<code>      - /var/run/docker.sock:/var/run/docker.sock:ro</code>
<code>    environment:</code>
<code>      LISTEN: 45876</code>
<code>      KEY: "從 Hub 介面複製的公鑰"</code>
<code>      TOKEN: "從 Hub 介面複製的 Token"

📝 第三步：部署 Agent（模式二：Agent 主動連 Hub，WebSocket）

適合 Agent 卡在 NAT 後面、沒有公開 IP 的情境，只需多加一個 HUB_URL 變數：

environment:</code>
<code>  HUB_URL: "https://beszel.example.com"</code>
<code>  KEY: "從 Hub 介面複製的公鑰"</code>
<code>  TOKEN: "從 Hub 介面複製的 Token"

💡 第四步：用 Caddy 設定反向代理與 HTTPS

不建議直接讓 8090 埠裸露在公網，用 Caddy 處理反向代理與自動憑證：

beszel.example.com {</code>
<code>    request_body {</code>
<code>        max_size 10MB</code>
<code>    }</code>
<code>    reverse_proxy 127.0.0.1:8090 {</code>
<code>        transport http {</code>
<code>            read_timeout 360s</code>
<code>        }</code>
<code>    }</code>
<code>}

設定完成後把 Docker 埠映射也收緊，只讓 Beszel 監聽本機：

ports:</code>
<code>  - 127.0.0.1:8090:8090

📌 第五步：加上 Docker 健康檢查（選用，進階）

beszel:</code>
<code>  healthcheck:</code>
<code>    test: ["CMD", "/beszel", "health", "--url", "http://localhost:8090"]</code>
<code>    interval: 120s</code>
<code>    timeout: 5s</code>
<code>    retries: 3</code>
<code>    start_period: 5s</code>

<code>beszel-agent:</code>
<code>  healthcheck:</code>
<code>    test: ["CMD", "/agent", "health"]</code>
<code>    interval: 120s</code>
<code>    timeout: 5s</code>
<code>    retries: 3</code>
<code>    start_period: 15s

📌 第六步：設定告警規則（預設值等於沒設）

每台機器加進 Hub 後，告警閾值預設都是空的，代表機器爆掉也沒人通知。至少要設這幾條基本規則：

• CPU 持續 10 分鐘超過 80%
• 記憶體使用率超過 90%
• 磁碟使用率超過 85%
• 系統離線超過 2 分鐘

通知管道支援 SMTP，以及 Shoutrrr 相容的各種第三方服務（Telegram、Discord、Slack、Gotify 等）。一個容易踩的雷：磁碟告警會分別計算根目錄與每個被掛載的卷，如果 Docker 資料卷掛在獨立分割區，那條警報得單獨開啟，光設根目錄不會自動涵蓋 📂

^[40]

---

📚 參考資料與延伸資源

• 📌 Beszel 官方 GitHub 專案 ^[26]
• 📌 Beszel 官方文件：What is Beszel ^[41]
• 📌 Beszel 官方 Agent 安裝文件 ^[31]
• 📌 Beszel 環境變數說明文件 ^[42]
• 📌 Beszel 通知與警報設定文件 ^[43]
• 📌 CVE-2026-27734 官方紀錄（NVD） ^[44]
• 📌 CVE-2026-40077 官方紀錄（NVD） ^[45]
• 📌 CVE-2026-44166 漏洞詳情（SentinelOne） ^[46]
• 📌 Beszel Unfinished Installation 漏洞紀錄 ^[47]
• 📌 Beszel 發布討論串（Reddit r/selfhosted） ^[48]