Uptime Kuma：自架網站監控與通知，備份還原與安全設定實測

內容概述

Uptime Kuma 是一個開源（MIT 授權）的自架監控工具，可以定時檢查網站、網頁關鍵字、TCP 連接埠等服務是否正常，出問題時透過 Webhook、Telegram、Email 等管道通知您，也能建立對外公開的狀態頁。

對個人站長和中小企業來說，它解決的是「網站掛了，要等客戶來說才知道」的問題：軟體免費、資料留在自己的主機上，成本只有一台小主機。本文以 Uptime Kuma 2.5.8（2.5.8-slim 映像檔、SQLite） 在 Docker Compose 上實際安裝、製造故障、備份再還原，把花費的時間、資源和資安注意事項都記錄下來。

測試方式說明：本文的安裝、監測、通知、狀態頁、備份與還原皆為實測（2026-10-28），並用全新環境把整套步驟重跑一次確認可行；標示「查核」的內容來自官方文件或原始碼，標示「未實測」的項目（升級、雙因素驗證、UPTIME_KUMA_DB_TYPE）只依官方文件說明。

什麼規模才需要 Uptime Kuma

Uptime Kuma 解決的是「自己掌握服務是否正常、出事馬上知道」的問題，不是每個人都需要自架。可依下列情況判斷：

• 一兩個網站、不想多顧一台機器：用現成的監控 SaaS 免費方案通常就夠，不必自架。
• 有幾個到幾十個網站或內部服務、已經有一台 VPS 或 NAS：很適合，Kuma 本身約 120 MB 記憶體（實測）。
• 需要監測內網服務（不對外的資料庫、內部系統）：SaaS 從外面看不到，自架的 Kuma 放在內網才看得到。
• 需要多地點監測、SLA 報表、多人分權管理或高可用：Kuma 只有單一管理員帳號、不支援叢集，請改評估商用方案。

最重要的一點：Kuma 不能和被監測的服務放在同一台主機。主機一掛，Kuma 也跟著停，就沒有人發通知了。至少要把 Kuma 放在另一台機器、另一個機房或另一家雲端。

應用場景

Uptime Kuma 適用於「有服務需要有人盯著」的情境，例如：

• 公司官網與電商網站：每 20～60 秒檢查一次首頁，掛掉時通知負責人。
• 檢查頁面內容是否正確：用關鍵字監測確認頁面真的有出現「加入購物車」之類的文字，而不只是回傳 200。
• 內部服務與資料庫：用 TCP 連接埠監測確認 PostgreSQL、Redis 等服務還連得上。
• 對客戶公開服務狀態：建立公開狀態頁，客戶不必登入就能看到服務是否正常。
• 串接自動化流程：用 Webhook 把告警送進 n8n 等工具，再決定要通知誰、要不要開工單。

技術特點

以下依官方 README（查核日期 2026-10-29）整理；本文實測過的項目另外標示：

• 多種監測類型：HTTP(s)、TCP 連接埠、HTTP(s) 關鍵字、JSON 查詢、WebSocket、Ping、DNS 記錄、Push、Docker 容器等。本文實測 HTTP、關鍵字、TCP 三種。
• 多種通知管道：Telegram、Discord、Slack、Email（SMTP）等，官方列出 90 種以上。本文實測 Webhook。
• 檢查間隔最短 20 秒：本文實測使用 20 秒。
• 多個狀態頁：可以把狀態頁對應到自己的網域。本文實測建立一個公開狀態頁。
• 雙因素驗證（2FA）：官方列為內建功能（未實測）。
• 其他：回應時間圖表、憑證資訊、Proxy 支援、多語系介面（含繁體中文）。
• 資料庫：2.x 可用 SQLite、內建 MariaDB 或外部 MariaDB／MySQL；-slim 映像檔沒有內建 MariaDB（查核，Docker Tags 文件）。本文使用 SQLite。

測試環境

2.5.8 是本文撰寫時的最新穩定版（2026-10-27 發佈，2026-10-29 再次查核仍是最新），請以 Releases 頁面的最新版本為準。

安裝步驟

官方沒有公布最低硬體需求；本文實測 Kuma 閒置約 118 MiB 記憶體，下載的映像檔約 185 MB（解壓後 860 MB）。需要先安裝 Docker 與 Docker Compose v2。

1. 建立資料夾與 compose.yaml。以下是本文實測設定中 Kuma 的部分（測試用的 nginx、PostgreSQL、Webhook 接收器已拿掉）：

name: jslab-kuma
services:
  uptime-kuma:
    # tag + digest 固定版本；不要用 latest（latest 指向已淘汰的 v1）
    image: louislam/uptime-kuma:2.5.8-slim@sha256:3e0ae13fa92d0a1108b7e4133eaa25b2bc4e26d2f5d8691a5cb01ee1fe5c95f1
    restart: unless-stopped
    ports:
      - "127.0.0.1:18010:3001"   # 只綁本機；官方範例 "3001:3001" 會綁所有網路介面
    volumes:
      - kuma-data:/app/data       # 資料都在這裡；官方說明不支援 NFS
    mem_limit: 512m
volumes:
  kuma-data:

• latest 是 v1：官方 Docker Tags 文件說明 latest 已淘汰且永遠指向 v1，請用 2、2-slim 或固定的 2.x.x(-slim)。
• 只綁 127.0.0.1：官方 README 的範例會綁所有網路介面，在還沒設定好管理員前就等於對外開放（見下方「對外開放前的安全設定」）。
• 連接埠 18010 是本文測試用的：您可以改成自己的本機連接埠，但建議保留 127.0.0.1: 前綴。

2. 啟動並確認服務回應：

docker compose -f compose.yaml up -d
curl -sf -o /dev/null http://127.0.0.1:18010/api/entry-page && echo "Kuma HTTP OK"

實測 up -d 1.2 秒完成，2.8 秒後 HTTP 回 200，6.6 秒後容器狀態變成 healthy。注意：healthy 不代表已經設定完成，此時還停在選資料庫的頁面。

3. 用瀏覽器開啟 http://127.0.0.1:18010 完成首次設定（手動操作）：

• 第一頁會問要使用哪個資料庫（MariaDB/MySQL 或 SQLite），選「SQLite」，實測約 2.8 秒後進入建立管理員頁面。
• 建立管理員帳號與密碼。Uptime Kuma 沒有預設帳密，第一個完成這一步的人就是管理員。
• 密碼請用密碼管理器產生，或用 openssl rand -base64 30 產生一組隨機字串，不要寫進指令紀錄或共用文件。

依官方環境變數文件，也可以用 UPTIME_KUMA_DB_TYPE=sqlite 跳過選資料庫的頁面（未實測）。

存取和操作

登入後依序建立通知、監測器和狀態頁（皆為手動在網頁介面操作）。

設定 Webhook 通知

• 進入「設定 → 通知」，新增通知，類型選「Webhook」，填入接收網址，方法 POST。
• 「請求主體」一定要選（本文選 JSON）：實測沒選時按「儲存」完全沒反應，但「測試」按鈕仍會成功，很容易誤以為已經存好。
• 勾選「啟用預設」，之後新建的監測器會自動套用這個通知。

建立監測器

本文建立 4 個監測器，間隔都設 20 秒：

• 逾時：HTTP 與關鍵字監測的逾時會自動帶入「間隔 × 0.8」（20 秒間隔就是 16 秒）；TCP 監測沒有逾時欄位。
• 重試次數：v2 新建監測器的預設重試由 1 改為 0（官方遷移文件）。建議設為 1 以上，避免網路瞬斷就誤報；本文測試為了讓計時清楚，使用 0。

故障偵測要多久（實測）

用 docker compose stop 停掉被監測的容器，記錄 Webhook 接收器收到通知的時間（重試 0、間隔 20 秒）：

• 偵測時間 ≈ 等到下一輪檢查（0～間隔秒數）＋這次檢查花的時間。HTTP 停掉的容器不會回應，要等滿 16 秒逾時；TCP 約 5 秒就判定失敗。
• 依此推估，20 秒間隔時 HTTP 最慢約 36 秒才會通知，TCP 約 25 秒（推估）。
• 監測器變成 DOWN 與收到 Webhook 的時間差不到 0.01 秒，通知本身幾乎沒有延遲。

建立公開狀態頁

• 在「狀態頁」新增一頁，加入要公開的監測器。
• 實測用未登入的瀏覽器開啟，可以看到各服務狀態與可用率；管理頁面仍需要登入。
• 實測狀態頁的公開 API 只提供監測器名稱與類型，預設不公開被監測的網址，失敗心跳的錯誤訊息也是空的。但名稱會公開，所以監測器名稱不要寫內部主機名或 IP。

實測踩坑紀錄

以下是實測時真的遇到、和 Uptime Kuma 本身有關的問題（環境或測試工具本身的問題不列入）：

對外開放前的安全設定

• 先設定管理員，再開放連接埠（實測）：完成首次設定前，設定頁面不需要任何驗證，誰先連上誰就是管理員。
• 只綁本機，對外走反向代理加 HTTPS（實測＋查核）：本文只綁 127.0.0.1；Kuma 沒有內建自動 HTTPS。依官方反向代理文件，代理必須轉送 WebSocket（Upgrade、Connection 標頭），且不支援放在子目錄，請用子網域。
• Trust Proxy 只在完全位於代理後方時開啟（查核）：官方建議如此，開啟後登入失敗紀錄才會記到真實 IP。
• 保留 WebSocket 來源檢查的預設值（查核）：預設是 cors-like，不要為了方便改成略過。
• 容器以 root 執行（實測）：映像檔沒有設定一般使用者。請不要再加 --privileged，也不要掛載多餘的主機目錄。
• 不要掛載 docker.sock（查核）：官方說明監測 Docker 容器需要掛 docker.sock，但這等於把主機的控制權交給 Kuma；如果一定要用，就不要讓 Kuma 對外。
• 開啟雙因素驗證（查核，未實測）：對外開放的話建議啟用。登入限流依原始碼是全程序共用每分鐘 20 次，不是每個 IP 分開計算（查核，未實測），密碼仍要夠強。
• /metrics 需要登入（實測）：未登入回 401。
• 登入失敗會留下紀錄（實測）：紀錄包含使用者名稱與來源 IP。
• 固定版本並跟著修漏洞（查核）：近 12 個月官方公開 5 則安全公告，2.5.8 又修正 1 則需管理員權限的遠端執行程式碼漏洞（細節未公開）。請使用 2.5.8 以上，並追蹤安全公告。
• 會主動對外連線檢查新版（查核）：依原始碼每 48 小時連到官方網站檢查版本，可以在設定中關閉。
• 備份檔是機敏資料（實測）：裡面有管理員密碼雜湊（bcrypt）和通知設定（Webhook 網址、Token 等），權限設 600，不要放在公開空間。

升級與備份

官方說明 v2 已移除 JSON 匯出／匯入，備份資料目錄是目前唯一支援的方式，而且要先停止 Uptime Kuma 再備份（官方遷移文件）。

停機備份（實測）

docker compose -f compose.yaml stop uptime-kuma
mkdir -m 700 -p backup
docker run --rm --user "$(id -u):$(id -g)" --memory 64m --network none \
  -v jslab-kuma_kuma-data:/data:ro -v "$PWD/backup:/backup" \
  python:3.14.10-alpine@sha256:cfe4b5079e5852da965ae14f74a6e2b137ece05b918d27c575fb70de3c85db2b \
  tar czf /backup/kuma-data.tar.gz --numeric-owner -C /data .
docker compose -f compose.yaml start uptime-kuma
chmod 600 backup/kuma-data.tar.gz
sha256sum backup/kuma-data.tar.gz > backup/kuma-data.tar.gz.sha256

• jslab-kuma_kuma-data 是 Compose 依專案名稱 jslab-kuma 自動產生的 volume 名稱；專案名稱不同就要跟著改（可用 docker volume ls 查）。
• 這裡借用一個小型 Python 映像檔裡的 tar 來打包，任何有 tar 的映像檔都可以；以唯讀（:ro）掛載、不接網路。
• 實測數字：停止 4.55 秒、打包 0.20 秒、重啟到可連線 2.28 秒，總停機約 7 秒；4 個監測器加上測試期間累積的資料，壓縮後的備份檔只有約 23 KB。停機期間 Kuma 不會監測，也不會發通知。

還原（實測）

在新主機（或新的 Compose 專案）放好同樣的 compose.yaml 和備份檔，先建立容器與空的 volume，再解壓縮、啟動：

sha256sum -c backup/kuma-data.tar.gz.sha256
docker compose -f compose.yaml create
docker run --rm --memory 64m --network none \
  -v jslab-kuma_kuma-data:/data -v "$PWD/backup:/backup:ro" \
  python:3.14.10-alpine@sha256:cfe4b5079e5852da965ae14f74a6e2b137ece05b918d27c575fb70de3c85db2b \
  tar xzpf /backup/kuma-data.tar.gz --numeric-owner -C /data
docker compose -f compose.yaml start

• 本文實測是還原到另一個 Compose 專案（新的 volume、127.0.0.1:18012），和原本的實例並排比對。
• 實測數字：解壓 0.34 秒、啟動到可連線 2.29 秒，還原總計約 2.6 秒，直接跳過首次設定。
• 還原後檢查：原管理員帳號能登入；4 個監測器和歷史紀錄都在；通知設定還在，按「測試」能送達；公開狀態頁正常顯示。
• 整套流程（安裝、設定、檢查、備份、還原）在全新環境重跑一次，共 44 秒全部通過。

升級（依官方文件，未實測）

依官方升級文件，Docker Compose 的升級方式是：

docker compose pull
docker compose up -d --force-recreate

• 本文用 tag＋digest 固定版本，所以要先把 compose.yaml 裡的 image 改成新版本，再執行上面兩行。
• 升級前先照上面的方式備份。官方 SECURITY.md 說明各版本都可以直接升級到最新版。
• 從 v1 升到 v2 會做資料庫遷移，官方說明可能要花上數小時，過程中不能中斷，請先讀完遷移文件。

適用規模與維運成本

• 授權費：0 元。MIT 授權，可商用；官方沒有付費版或雲端 SaaS，專案靠 GitHub Sponsors 與 Open Collective 贊助維持（查核）。
• 資源（實測）：Kuma 閒置 118 MiB、4 個監測器（20 秒間隔）運作中約 121 MiB，CPU 0.3～1.1%；資料目錄在約 10 分鐘內從 1.4 MB 成長到 2.2 MB。心跳資料預設保留 365 天，可以在設定中調整（查核）。
• 主機（推估）：1 vCPU／1 GB RAM／10 GB 磁碟的最小規格 VPS，應足以跑幾十個 60 秒間隔的監測器；512 MB 的機器也能跑，但比較吃緊。實際費用依主機商而定。
• 維護時間：安裝約 5 分鐘（實測）；每次備份停機約 7 秒（實測），可以排程；近 12 個月發佈 23 個版本，建議每月檢查一次新版與安全公告（推估）。

自架與監控 SaaS 怎麼選

• 自架 Uptime Kuma：沒有監測器數量限制、看得到內網服務、資料在自己手上；代價是要自己負責主機、HTTPS、備份與升級，而且要另外準備一台主機。
• 監控 SaaS：不用維護，通常有多地點監測；免費方案有監測器數量與間隔限制，看不到內網服務。各家價格請以官方定價頁為準。

簡單來說：已經有一台獨立的小主機、又想監測內網服務，選自架；只有一兩個公開網站、沒有人力維護，選 SaaS 的免費方案。

優缺點分析

優點

• 安裝快：一個容器、一個 volume，約 5 分鐘就能開始監測（實測）。
• 資源少：約 120 MB 記憶體，最小規格的主機就能跑（實測＋推估）。
• 完全免費：MIT 授權，沒有功能鎖在付費版（查核）。
• 備份還原簡單：停機約 7 秒完成備份，約 2.6 秒還原，資料完整（實測）。
• 狀態頁預設不外流網址：公開 API 只給名稱與類型（實測）。
• 通知管道多：官方列出 90 種以上，Webhook 可接自動化工具（查核＋實測 Webhook）。

缺點

• 預設設定偏寬鬆：官方範例綁所有網路介面、首次設定前不需要驗證、容器以 root 執行（實測＋查核）。
• 沒有內建 HTTPS：要自己架反向代理（查核）。
• 單一管理員、不支援高可用：不適合需要分權或叢集的團隊（查核）。
• 更新與漏洞修補頻繁：近 12 個月 23 個版本、6 則安全公告，要有人定期升級（查核）。
• 核心維護集中在作者一人：社群很大，但專案方向與審核主要靠作者（查核）。
• 備份要停機：時間很短，但無法做到零停機（實測＋查核）。

綜合評價

以下依 2026-10-28／29 的實測與官方資料評分（1～5 顆星）：

小技巧

• 監測器名稱寫給人看：狀態頁會公開名稱，用「官網」「訂單系統」這類名稱，不要寫內部主機名或 IP。
• 重試至少設 1：本文為了計時用 0，正式使用建議 1 以上，避免網路瞬斷就半夜被叫醒。
• Webhook 時間用 localDateTime：heartbeat.time 固定是 UTC。
• 定期更新：每月看一次 Releases 與安全公告；升級前先備份資料目錄。
• 備份後實際還原一次：本文還原到另一個專案只花 2.6 秒，確認備份真的能用再刪舊檔。

NotebookLM 互動問答

想針對本文或官方文件提問，可以使用我們整理的 NotebookLM 筆記：Uptime Kuma 互動問答（NotebookLM）。筆記的來源只收錄 Uptime Kuma 官方網站、官方文件與 GitHub 儲存庫，回答內容仍請以官方文件為準。

參考連結

• Uptime Kuma 官方網站
• Uptime Kuma GitHub 儲存庫
• 2.5.8 版本說明（Release notes）
• 官方安裝文件（How to Install）
• 從 v1 遷移到 v2（含備份說明）
• 反向代理設定（Reverse Proxy）

本文寫作方式：本文的測試計劃與審稿由強哥負責，實測操作、紀錄整理與初稿由 AI 助理協作完成，所有數字皆來自實測紀錄或官方來源；文中插圖為 AI 生成。

成本與風險摘要

• 適用對象與規模：個人站長、部落客、中小企業 MIS，監測幾個到幾十個網站或內部服務；需要多地點監測、SLA 報表、多人分權或高可用時，請改用商用方案。
• 成本（硬體、訂閱、授權）：MIT 授權，軟體免費、沒有付費版；實測 Kuma 約 120 MB 記憶體；推估 1 vCPU／1 GB RAM 的最小 VPS 即可，費用依主機商而定。
• 維護時間：安裝約 5 分鐘；備份停機約 7 秒、還原約 2.6 秒；版本更新頻繁，建議每月檢查新版與安全公告並先備份再升級。
• 資安注意事項：完成首次設定前不要開放連接埠；只綁 127.0.0.1，對外用反向代理加 HTTPS；開啟 2FA；不要掛載 docker.sock；使用 2.5.8 以上；備份檔含密碼雜湊與通知 Token，權限設 600。
• 常見誤區：以為 latest 是最新版（其實是 v1）；照官方範例 3001:3001 綁所有介面；運作中直接複製 kuma.db；把 Kuma 和被監測的服務放在同一台主機。
• 不建議使用的情況：只有一台主機、沒有別處可以放 Kuma（主機掛了就沒人通知，改用監控 SaaS）；需要高可用或多人分權；沒有人會定期升級。
• 測試日期與版本號：測試日期：2026-10-28；Uptime Kuma 2.5.8（2.5.8-slim、SQLite）（測試環境：Debian 13、8 vCPU／15 GB RAM、Docker 29.9.2、Docker Compose 5.6.1）。升級、2FA、UPTIME_KUMA_DB_TYPE 依官方文件說明，未實測。