所有系统运行正常 21 支持的加密货币 · 欢迎使用 Monero 无需 KYC 政策
ChainVPS

监控 · 无需 KYC

在离岸VPS上部署 Uptime Kuma

在离岸 VPS 上运行属于自己的可用性监控与公开状态页面,无需任何第三方 SaaS 服务掌握你的监控端点列表或身份信息。

这是什么

Uptime Kuma 是一款自建监控工具,可检测网站、API、TCP 端口、DNS 记录和容器的可用性,一旦出现故障即可通过 90 多种通知渠道向你发出告警。它提供简洁的网页控制台,并可发布公开或私有状态页面,所有数据均由内置的单一 SQLite 数据库支撑。

为何选择离岸托管

监控服务器掌握着你整套基础设施的完整地图——每一个被监控的主机名、IP、端口和 API 密钥——因此它部署在哪里、谁能对其发出传票调取数据都至关重要。将 Uptime Kuma 部署在无需 KYC、支持加密货币支付的离岸 VPS 上,可以让这份监控清单远离第三方 SaaS 控制台,也不落入生产环境所在的司法管辖区,而不限流量的带宽更让持续轮询检测毫无成本负担。

部署过程

一套可用的参考配置

将其复制到全新的 ChainVPS 实例中。替换占位符后即可启动。

docker-compose.yml
# 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).

防火墙

需开放的端口

端口协议用途
3001TCPUptime Kuma 网页管理界面 / WebSocket——请始终绑定在 127.0.0.1,切勿公开暴露
443TCP通过反向代理(Caddy/nginx)提供的 HTTPS 服务——用户唯一需要开放的入站端口
80TCPHTTP,仅用于 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 保留你的监控数据副本,账户也不会与任何身份信息绑定。

立即创建 Uptime Kuma
在接下来的 60 秒内。

不限流量带宽 · 包含 DDoS 防护 · 21 种加密货币 · 无需 KYC。