这是什么
Uptime Kuma 是一款自建监控工具,可检测网站、API、TCP 端口、DNS 记录和容器的可用性,一旦出现故障即可通过 90 多种通知渠道向你发出告警。它提供简洁的网页控制台,并可发布公开或私有状态页面,所有数据均由内置的单一 SQLite 数据库支撑。
为何选择离岸托管
监控服务器掌握着你整套基础设施的完整地图——每一个被监控的主机名、IP、端口和 API 密钥——因此它部署在哪里、谁能对其发出传票调取数据都至关重要。将 Uptime Kuma 部署在无需 KYC、支持加密货币支付的离岸 VPS 上,可以让这份监控清单远离第三方 SaaS 控制台,也不落入生产环境所在的司法管辖区,而不限流量的带宽更让持续轮询检测毫无成本负担。
部署过程
一套可用的参考配置
将其复制到全新的 ChainVPS 实例中。替换占位符后即可启动。
# 1) Install Docker + compose plugin (Ubuntu 24.04)
# curl -fsSL https://get.docker.com | sh
#
# 2) docker-compose.yml — Uptime Kuma behind Caddy for automatic HTTPS
# Replace status.example.com with your domain (A record -> this VPS).
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- ./uptime-kuma-data:/app/data
# Bound to loopback: only Caddy reaches it, never the public internet.
ports:
- "127.0.0.1:3001:3001"
caddy:
image: caddy:2
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy-data:/data
- caddy-config:/config
volumes:
caddy-data:
caddy-config:
# 3) Caddyfile (same directory) — TLS is issued automatically:
# status.example.com {
# reverse_proxy uptime-kuma:3001
# }
#
# 4) docker compose up -d
# Open https://status.example.com and create the admin user
# on first visit (do this immediately — the setup screen is unauthenticated).
防火墙
需开放的端口
| 端口 | 协议 | 用途 |
|---|---|---|
| 3001 | TCP | Uptime Kuma 网页管理界面 / WebSocket——请始终绑定在 127.0.0.1,切勿公开暴露 |
| 443 | TCP | 通过反向代理(Caddy/nginx)提供的 HTTPS 服务——用户唯一需要开放的入站端口 |
| 80 | TCP | HTTP,仅用于 ACME/Let's Encrypt 证书签发及跳转至 443 端口 |
按需调配规格
您需要哪种套餐
VPS Nano / Small(1 vCPU,1-2 GB RAM)
个人使用场景,最多约 50 个监控项,检测间隔为 60 秒。Uptime Kuma 闲置时内存占用仅为数百 MB。
VPS Pro(2-4 vCPU,4-8 GB RAM)
适合小型团队,可支持数百个监控项、多个公开状态页面以及更频繁的检测。
VPS Pro(大规格)或入门级独立服务器
1000 个以上监控项且检测间隔较短的场景。此时 SQLite 的写入争用会成为瓶颈——应配备高速 NVMe 存储和完整的 CPU 核心,并优先延长检测间隔,而非单纯增加内存。
最佳地区: 请选择隐私友好级别的机房位置(NL、CH、RO、IS、MD、LU),让存储完整监控端点清单的服务器落在对隐私友好的司法管辖区——NL 和 CH 的网络连接质量也十分出色,能有效降低探测延迟,减少误报告警。如果你监控的目标集中在某一地区,选择靠近该地区且连接良好的机房位置能获得最准确的在线/离线状态信号。
全面加固安全
安全加固清单
- 切勿将 3001 端口暴露在公网上。请按上文所述将其绑定到 127.0.0.1,并仅通过 TLS 反向代理访问管理界面;同时添加 UFW 规则,只放行 80/443 端口和 SSH。
- 在执行 `up -d` 后请立即首次访问并创建管理员账户——初始设置页面没有任何身份验证,任何人只要抢先加载该界面就能接管这个实例。随后请在 Settings > Security 中启用双重验证(2FA)。
- 请定期备份 ./uptime-kuma-data 目录(它是一个单一的 SQLite 数据库)。在复制之前请先停止容器,或使用 Uptime Kuma 内置的备份功能,以避免复制到写入中途的数据库文件,并将备份副本存放在监控服务器之外。
- 公开状态页面上的信息应保持精简——它们可能泄露内部主机名和 IP 地址。请使用私有状态页面或按页设置访问权限,并为监控项设置通用的显示名称,而非真实的服务器主机名。
- 请通过不会关联到你身份的渠道接收告警(例如专用的 Telegram 机器人,或自建的 Apprise/ntfy),而非个人邮箱,并将数据库中的通知令牌视为敏感信息妥善保管。
- 请将镜像固定在 `1` 主版本标签,并定期执行 `docker compose pull && up -d`;由于 Uptime Kuma 仍在积极开发中,请持续关注项目的发布说明。
问题
主机服务 Uptime Kuma — 常见问题
Uptime Kuma 需要单独的数据库服务器吗?
不需要。它使用存储在 /app/data 中的内置 SQLite 数据库,因此单个容器加一个数据卷就是完整的技术栈。这也是为什么在监控项数量较多时,高速磁盘比大内存更重要。
为什么要把它放在 Caddy 或 nginx 之后,而不是直接开放 3001 端口?
Uptime Kuma 在 3001 端口上仅提供纯 HTTP 服务,本身并不具备 TLS 能力。反向代理可以自动提供 HTTPS、让应用始终保持在回环地址上运行,并允许你添加访问控制——如果直接暴露 3001 端口,你的管理员登录信息将以未加密的 HTTP 明文传输。
能否从 ChainVPS 服务器监控其他国家/地区的服务器?
可以。监控是出站发起的——VPS 会通过 HTTP(S)、TCP、ICMP ping、DNS 等方式主动连接你的监控目标。不限流量的带宽意味着频繁检测不会产生额外成本,而网络连接良好的机房位置也能减少因延迟引起的误报告警。
它实际会占用多少资源?
在单个 vCPU 上,一个只有少量监控项的闲置实例通常只需约 200-400 MB 内存即可流畅运行。资源占用会随监控项数量及检测频率增加,因此在升级硬件之前,不妨先尝试延长检测间隔。
我的状态页面和监控端点列表能否保持私密?
这完全由你自己掌控。状态页面是可选启用的,并且可以设为私有;监控项列表只保存在 VPS 上你自己的 SQLite 数据库中。在无需 KYC 的离岸主机上,不会有任何第三方 SaaS 保留你的监控数据副本,账户也不会与任何身份信息绑定。