海外云服务器搭建 Uptime Kuma 轻量监控告警 + 公网状态页完整教程（2026最新版）

Meta Description: 海外云服务器搭建 Uptime Kuma 完整教程：Docker 一条命令部署轻量级可用性监控告警系统，覆盖 HTTP/TCP/Ping/DNS/关键词/推送/Steam 游戏服等 10 类监控项、Telegram/飞书/钉钉/企业微信/Bark 等 90+ 通知渠道、公网状态页（Status Page）与自定义域名、Nginx 反向代理 WebSocket 与 Let's Encrypt HTTPS 配置，另含 v1 升 v2 破坏性变更避坑、data 目录备份恢复、服务器配置推荐表、服务商价格参考表、自建与商业监控服务成本对比表，以及 8 条常见问题 FAQ。

> 关键词：Uptime Kuma 搭建教程、Uptime Kuma Docker 部署、海外云服务器监控、网站可用性监控、服务器宕机告警、公网状态页、Uptime Kuma 通知配置、Telegram 告警、Nginx 反向代理 WebSocket、Prometheus 和 Uptime Kuma 区别

前言：你缺的往往不是"更多指标"，而是"服务挂了立刻知道"

一句话答案：Uptime Kuma 是一个开源自托管的"可用性监控 + 告警 + 公网状态页"工具，用一条 Docker 命令就能在海外云服务器上装好，默认监听 3001 端口；它支持 HTTP、TCP、Ping、DNS、关键词、JSON 查询、WebSocket、推送（Push）、Steam 游戏服、Docker 容器共 10 类监控项，能以最快 20 秒的间隔探测，并把告警推送到 Telegram、飞书、钉钉、企业微信、Slack、邮件等 90 多种渠道，同时对外发布一个可自定义域名的公开状态页。

很多人第一次做服务器监控，会直接上手 Prometheus + Grafana。那套东西很强大，但有个前提：你已经知道自己要监控什么指标，并且愿意为它维护一整套采集、存储、查询、告警链路。 而现实中更常见、也更疼的需求其实非常朴素：

- 我的网站 502 了，是刚才开始挂的，还是已经挂了三个小时？ - 我的 VPS 到底有没有在半夜重启过？是网络抖动还是进程崩了？ - 客户问"你们服务是不是挂了"，我能不能甩一个状态页链接过去，而不是自己先去 ping 一圈？ - 证书还有 7 天到期，有没有人提前告诉我？

这四件事有个共同点：它们都是"可用性"问题，不是"指标"问题。 用 Prometheus 去做也能做（黑盒探针 + Alertmanager 规则），但配置量是 Uptime Kuma 的十倍以上，而 Uptime Kuma 只干这一件事，干得很顺：Web 界面点几下加监控，通知渠道选一个填进去，状态页勾选要公开的监控项，完事。

它最讨喜的地方是轻。 一个 Node.js 进程 + 一个 SQLite 文件，1 核 1G 的入门 VPS 就能跑；一台专门用来做监控的 1 核 1G 小机器，月费往往只要几美元，却能替你盯着十几台业务机。代价是它不替代 Prometheus/Grafana：它回答"服务活着吗、响应快不快"，不回答"CPU 为什么飙到 90%、内存被谁吃了"。这一点本文第一节会一次性讲清楚，避免你装完才发现选错了工具。

本文给出可直接复制执行的完整命令，以 Ubuntu 22.04（Docker 方式）为主线，覆盖：买服务器 → 装 Docker → 一条命令拉起 Uptime Kuma → 首次登录与开启 2FA → Nginx 反向代理 + Let's Encrypt 自动 HTTPS（含唯一一个必踩的 WebSocket 坑）→ 添加第一组监控项 → 配置 Telegram 等通知渠道 → 发布公网状态页 → 备份与升级（v1 升 v2 的破坏性变更）→ 安全加固，最后附服务器配置推荐表、服务商价格参考表、自建与商业监控服务成本对比表，以及 8 条常见问题。

> 🚀 还没有海外云服务器？通过 5.chengzicloud.cloud 选购阿里云/AWS/腾讯云国际版，享专属折扣和中文技术支持。

一、先分清边界：Uptime Kuma、Prometheus、云监控、商业 SaaS 各管什么

在动手前先做一次选型。监控工具的选型错误不是"多花点钱"，而是整篇文章的命令都不适用——因为它们的定位根本不同。本站已经有一篇 Prometheus + Grafana 监控告警系统完整教程，不少读者会问"这和 Uptime Kuma 有什么区别、我要装哪个"。下面这张边界表一次说清，本文只负责 Uptime Kuma 这一层。

| 既有 / 相邻方案 | 它回答的问题 | 与本文的关系 | |---|---|---| | Prometheus + Grafana（本站已有专文） | "服务器的 CPU/内存/磁盘/连接数现在是多少、趋势如何" | 它是指标层：Node Exporter 采集、时序库存储、Grafana 画图。本文是可用性层，两者是互补关系，不是二选一 | | 云厂商自带监控（CloudWatch / 腾讯云云监控） | "我这台云主机的基础指标和告警" | 免费、开箱即用，但只盯自家资源，且从境外站点发告警常有延迟；跨厂商、跨地域的统一视图做不了 | | 商业 SaaS（UptimeRobot / Pingdom / Better Stack） | "多地点可用性探测 + 告警" | 省心但按监控点收费，监控项一多就涨价，且探测数据在别人手里；本文是它的自托管替代 | | 网站统计（本站 Umami 篇） | "有多少人来了、看了哪些页" | 它是流量分析，不管服务是否在线，与本文无重叠 | | Nginx 反向代理 + Let's Encrypt SSL（本站已有专文） | "怎么给 Web 服务加域名和 HTTPS" | 本文第五节会用到它，但只讲 Uptime Kuma 特有的 WebSocket 配置，其余直接复用那篇，不重复 | | Uptime Kuma（本文） | "服务活着吗、响应多久、挂了通知谁、要不要对外公示状态" | 只讲这一层 |

一张表判断你该装哪个：

| 你的情况 | 推荐方案 | |---|---| | 只有 1～3 台机器，只想"挂了知道、并有个状态页" | Uptime Kuma（本文，1核1G 就够，月费 $4 级别） | | 要排查性能瓶颈、看历史趋势、做容量规划 | Prometheus + Grafana（本站另一篇） | | 两者都要 | 两套一起跑：Prometheus 管指标，Uptime Kuma 管可用性与对外状态页（这也是真实运维中最常见的组合） | | 完全不想运维、只要 SLA 报告 | 商业 SaaS（按监控点付费，年费通常 $100 起） |

一个必须提前说清的能力边界：Uptime Kuma 是单点探测——它从你部署它的那台机器出发去探测目标。也就是说，如果探测机和被监控服务在同一个机房，机房整体断网时，它可能"看不到"故障（因为它自己也断了）；而"从多个地理位置探测"恰恰是商业 SaaS 的核心卖点。正确的自托管做法是：把 Uptime Kuma 装在一台与业务机不同机房的轻量 VPS 上，或者用它的 Push 模式让业务机主动上报（第六节），这两种方式都比"和业务挤在同一台机器上"可靠得多。把这条边界说在前面，比装完才发现"监控和监控对象一起挂了"要有价值。

二、Uptime Kuma 到底能监控什么：10 类监控项 + 90 多种通知渠道

先把能力摊开，你才知道它能不能覆盖你的场景。以下能力清单来自官方仓库 README，版本以官方最新发布为准（本文写作时的最新版为 2.5.5，请以官方 Releases 页为准）。

支持的监控类型

| 监控类型 | 典型用途 | 说明 | |---|---|---| | HTTP(s) | 网站首页、API 接口 | 最常用；可按状态码或响应时间判定成功/失败 | | HTTP(s) Keyword | 页面内容检查 | 响应里必须出现（或不出现）某个关键词才算正常，能抓到"页面 200 但内容是错误页"这种假活 | | HTTP(s) Json Query | JSON API 断言 | 用 JSON 路径取字段判断，例如检查 {"status":"ok"} | | TCP | 数据库、Redis、SSH 端口 | 只测端口通不通，不涉及协议内容 | | Ping | 整机可达性 | ICMP 探测，判断机器是否在线 | | DNS Record | 域名解析 | 检查 A/AAAA/CNAME/MX 等记录是否与预期一致，能提前发现解析被改 | | Websocket | 实时推送类服务 | 检查 WS 握手与通信是否正常 | | Push | 反向心跳（强烈推荐） | 由业务机定时"报到"，超过设定时间没报到就告警——最适合监控备份任务、爬虫、定时脚本 | | Steam Game Server | 游戏服 | 直接查 Steam 游戏服务器状态，配合本站游戏服务器教程使用 | | Docker Containers | 容器存活 | 直接盯 Docker 容器状态，适合配合本站 Docker + Portainer 篇 |

几个容易被忽略但很值钱的点：① 检测间隔最快可到 20 秒，比大多数免费商业方案的 5 分钟快一个量级；② 自动记录证书信息，HTTPS 证书到期前能在界面上看到，配合通知渠道就能做续期提醒；③ 支持代理——探测目标在国内、探测机在海外时，可以走代理出站；④ 支持 2FA 登录，暴露到公网的监控面板不至于被暴力破解；⑤ 支持把状态页绑定到指定域名，可以让 status.yourdomain.com 只显示状态页。

通知渠道：不止 Telegram

官方通知组件覆盖 90 多种服务。对中文用户最有用的几类：

| 类别 | 渠道举例 | |---|---| | 即时通讯 | Telegram、Discord、Slack、飞书（Feishu）、钉钉（DingDing）、企业微信（WeCom）、Rocket.Chat、Nextcloud Talk、Mattermost、Matrix、Signal、VK | | 国内推送 App | Bark、ServerChan（Server 酱）、PushDeer、WxPusher（微信推送）、PushPlus | | 通用 Webhook | Webhook（可对接任意自建系统，如本站 n8n 自动化篇） | | 邮件 / 短信 | SMTP 邮件、阿里云短信（AliyunSms）、Twilio、SendGrid、Resend | | 值班响应 | PagerDuty、Opsgenie、Splunk、AlertNow、Grafana OnCall |

建议至少配两条渠道：一条即时通讯（Telegram 最快）+ 一条邮件（作为兜底）。只有一个渠道时，渠道自己抽风就等于没有告警——这是最隐蔽的单点故障。

官方明确的能力边界（这些"做不到"必须提前知道）

- 不支持子目录部署。 官方的原话是 Uptime Kuma does not support a subdirectory——你不能把它挂在 https://example.com/uptimekuma 下面，必须给它一个独立域名或子域名（例如 status.yourdomain.com）。这是新手最常踩的第一个坑，配置反向代理前就要规划好。 - 数据卷不支持 NFS 等网络文件系统。 官方警告：SQLite 需要 POSIX 文件锁，NFS 常见锁问题会导致数据库损坏。请务必把 /app/data 映射到本地目录或本地卷。 - 它是单进程单实例设计。 没有官方集群/高可用模式，监控量极大时应横向部署多套，而不是指望单套扛住一切。

三、服务器怎么选：这是一台"常年开着的哨兵"，稳定比性能重要

Uptime Kuma 的资源画像和 GitLab 那种"内存吃货"完全相反：它几乎不吃资源，但它必须 7×24 小时在线。选型的核心不是核数，而是"别断、别被回收、别和业务一起死"。

第一，配置够用就好，1 核 1G 起步。 一个 Node.js 进程 + SQLite，个人使用（几十个监控项）1 核 1G 完全够；监控项上百、探针间隔 20 秒级别时，建议 1 核 2G 或 2 核 2G。不要在这台机器上再跑别的重服务——监控机最怕的就是被同机的业务把内存打满。

第二，磁盘 20GB 就够，但要理解数据增长点。 历史心跳数据会持续累积（每一次探测就是一条记录），监控项越多、间隔越短、保留越久，SQLite 文件越大。20～40GB 系统盘对个人场景绰绰有余，长期跑可以定期在界面里清理历史，或在 v2 里利用新的聚合存储。

第三，机房位置决定"你能不能发现故障"。 强烈建议把 Uptime Kuma 放在与业务机不同的机房（例如业务在硅谷，监控放香港或新加坡）。同一机房内，机房级断网会让监控和业务同时失联，你收到的是"一切正常"的假象。

第四，一定要开自动重启与自动备份。 容器用 restart: unless-stopped；./data 目录做定时快照或异地同步（本站有专门的数据备份与容灾恢复教程）。

服务器配置推荐（按监控规模）

| 使用场景 | 推荐配置 | 为什么够用 | |---|---|---| | 个人自用，10～30 个监控项 | 1核 1G + 20GB SSD | Node.js + SQLite，常驻内存几百 MB，最省钱 | | 小团队，50～100 个监控项 | 1核 2G 或 2核 2G | 监控项多、探针密集时留出余量，跑得更稳 | | 多站点/多机房统一监控 | 2核 4G，独立一台 | 同时开多个状态页、通知渠道多，避免与业务争资源 | | 只要对外状态页 | 1核 1G（最低配即可） | 状态页是轻量静态渲染，配置要求最低 |

> ⚠️ 不要把 Uptime Kuma 和它要监控的业务装在同一个"小机器"上。 这不是省钱的优化，而是自欺欺人：业务机内存打满时，监控进程往往第一个被杀，你会收到"没有告警"——而那恰恰是最需要告警的时刻。

服务商价格参考

下面按"1核1G / 1核2G"这一实际推荐档整理公开官网参考区间（价格采集于 2026 年 9 月，仅为公开官网参考区间，请以官网实时价格为准）：

| 服务商 | 1核1G 月付 | 1核2G 月付 | 数据中心 | 优点 | |---|---|---|---|---| | 阿里云国际版 ECS（突发性能型） | 约 $9～$14 | 约 $13～$20 | 新加坡/香港/硅谷 | 中文面板、支持支付宝、生态完整 | | AWS Lightsail | 约 $5（1GB 档） | 约 $7（2GB 档） | 全球 20+ 区域 | 固定月费、含流量额度、开箱即用 | | 腾讯云国际版 CVM（轻量型） | 约 $6～$10 | 约 $10～$16 | 香港/新加坡/东京 | 低延迟到国内、微信支付 | | Vultr | 约 $5～$6（1GB 档） | 约 $10～$12（2GB 档） | 全球 32 个 | 按小时计费、随时销毁重建 | | DigitalOcean | 约 $6（1GB 档） | 约 $12（2GB 档） | 全球 14 个 | 文档完善、社区教程多 |

> 💡 监控机优先选便宜、稳定、离业务机不同机房的节点。个人场景下，一台 $5/月 的 1核1G 足够盯住十几台业务机；如果业务和用户都在国内，监控机放香港通常能兼顾"到国内延迟低"和"到海外业务可达"。通过 5.chengzicloud.cloud 购买以上平台还可享额外折扣。

> 声明：本文价格数据采集于 2026 年 9 月，仅为公开官网参考区间。云服务器价格随区域、计费方式和活动浮动，请以各厂商官网实时价格为准。除特别标注外，金额单位均为美元（USD）。

四、部署：从裸机到能看到登录页，大约 5 分钟

以 Ubuntu 22.04 + Docker 为主线（Debian 12 同样适用）。全程命令可直接复制。

第 1 步：系统初始化与防火墙

先更新系统并装好基础工具：

`bash apt update && apt upgrade -y apt install -y curl wget vim ufw ca-certificates `

配置防火墙。注意 3001 端口不要对全网开放——它是 Uptime Kuma 的默认端口，暴露出去等于把后台挂到公网上：

`bash ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw enable ufw status `

如果暂时需要通过公网 IP 完成首次设置，可以临时放行 3001，设置完成后立刻回收（第五节会改成只监听本机）：

`bash ufw allow 3001/tcp `

第 2 步：安装 Docker 与 Compose 插件

`bash curl -fsSL https://get.docker.com | sh systemctl enable --now docker docker version docker compose version `

看到 Docker 与 Compose 的版本号输出即安装成功。如果 docker compose 报 "command not found"，说明只装了旧版 docker-compose，先补装插件：

`bash apt install -y docker-compose-plugin `

第 3 步：准备目录并写 compose 文件

一个关键原则：/app/data 必须映射到本地目录。 官方明确警告 Uptime Kuma 的 SQLite 依赖 POSIX 文件锁，NFS 等网络文件系统会导致数据库损坏，而数据目录就是你的全部家当（账号、监控项、通知配置、历史数据）。

`bash mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma `

在 /opt/uptime-kuma 下创建 compose.yaml，内容如下：

`yaml services: uptime-kuma: image: louislam/uptime-kuma:2 container_name: uptime-kuma restart: unless-stopped volumes: - ./data:/app/data ports: - "3001:3001" `

这里用官方推荐的主版本标签 :2（而不是 :latest），既能自动获得 2.x 的小版本修复，又不会误升到未来可能不兼容的 3.x。启动服务：

`bash docker compose up -d docker compose logs -f --tail=50 `

看到日志出现监听提示后，按 Ctrl+C 退出日志跟随（不会停止容器）。确认容器状态：

`bash docker compose ps curl -sI http://127.0.0.1:3001 | head -3 `

能返回 HTTP 响应头即部署成功。此时在浏览器访问 http://你的服务器IP:3001，会看到首次设置界面。

第 4 步：创建管理员账号并立刻开启 2FA

这一步请在 1 分钟内完成，中间不要离开。 首次访问时系统会要求你创建管理员用户名与密码——在完成创建之前，任何能访问到 3001 端口的人都能抢先注册成为管理员。

创建完成后立刻做三件事：

1. 进入 设置 → 安全，开启双重验证（2FA），用 Google Authenticator / Authy 扫码，并把恢复码抄到离线的地方； 2. 把界面语言切到中文（Settings → Appearance → Language）； 3. 在 设置 里确认时区正确（后续告警时间、状态页时间都依赖它）。

做完这三步，就可以按第五节把 3001 端口关回内网了。

`bash ufw delete allow 3001/tcp `

第 5 步：验证与常见启动失败排查

| 现象 | 原因 | 处理 | |---|---|---| | 容器反复重启 | 数据目录权限或文件锁问题 | docker compose logs 看报错；确认 ./data 在本地磁盘而非 NFS | | 页面能开但一直转圈 | 通过反向代理访问时缺 WebSocket 头 | 见第五节，这是最高频的原因 | | port is already allocated | 3001 被别的服务占用 | 改端口，或先停掉占用进程 | | 数据"消失" | 建了容器但没映射 ./data | 数据在容器内，容器一重建就没了；务必按上面的 compose 挂载 |

五、反向代理 + HTTPS：Uptime Kuma 唯一一个"必踩的坑"

到这一步，监控面板还只是"能用了"。要让它安全地对外提供服务（尤其是第六节的公网状态页），标准做法是：Nginx 反向代理 + Let's Encrypt 免费 HTTPS，同时把容器端口收回内网。

坑：Uptime Kuma 基于 WebSocket，反代必须带两个头

这是新手最容易卡住的地方：配置好 Nginx 之后，页面能打开、界面能显示，但数据不刷新、一直转圈、监控项状态不动。原因不是装错了，而是 Uptime Kuma 与普通 Web 应用不同——它基于 WebSocket，官方原文要求反向代理额外传递 Upgrade 和 Connection 两个头，否则连接建立不起来。

第二个坑：不支持子目录。 官方明确说明 Uptime Kuma 不支持 example.com/uptimekuma 这种子目录部署，必须给它一个域名或子域名。所以请先在 DNS 里加一条 A 记录，例如 status.yourdomain.com 指向你的服务器 IP（用你自己的域名替换即可）。

第一步：让容器只监听本机

把 compose.yaml 的端口映射改成只绑定回环地址，然后重建：

`yaml services: uptime-kuma: image: louislam/uptime-kuma:2 container_name: uptime-kuma restart: unless-stopped volumes: - ./data:/app/data ports: - "127.0.0.1:3001:3001" `

`bash cd /opt/uptime-kuma && docker compose up -d `

这样 3001 端口只在服务器内部可见，外部访问一律经过 Nginx + HTTPS。

第二步：写 Nginx 站点配置

在 /etc/nginx/conf.d/uptime-kuma.conf 写入下面的配置。注意 proxy_set_header Upgrade 与 Connection "upgrade" 这两行不能少——它们就是 WebSocket 的通行证：

`nginx server { listen 80; server_name status.yourdomain.com;

location / { proxy_pass http://127.0.0.1:3001; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } `

检查并重载：

`bash nginx -t && systemctl reload nginx `

第三步：签发 Let's Encrypt 证书

`bash apt install -y certbot python3-certbot-nginx certbot --nginx -d status.yourdomain.com `

Certbot 会自动改好上面的配置、加上 443 监听与 HTTP→HTTPS 跳转，并配置自动续期。验证一下：

`bash curl -sI https://status.yourdomain.com | head -3 certbot renew --dry-run `

第四步：开启 Trust Proxy，让日志显示真实 IP

如果 Uptime Kuma 完全跑在反向代理之后（本方案就是如此），官方建议在面板里开启可信代理头，这样访问日志里显示的才是客户端真实 IP，而不是 127.0.0.1：

进入 设置 → 反向代理（Reverse Proxy）→ HTTP 头（HTTP Headers），把 Trust Proxy 设为 Yes。

> 💡 更省心的替代方案：如果你已经在用 Cloudflare，可以开启 Cloudflare 的免费防护与 WAF，或者用 Cloudflare Access 给监控面板再加一层身份校验——状态页公开、管理后台锁死，是安全与便利的最佳平衡。也可参考本站网站安全加固教程里的 fail2ban 方案兜底。

六、添加第一组监控：先加 3 条，再把"定时任务"接进来

Uptime Kuma 的界面逻辑很直白：监控项（Monitor）是"盯什么"，通知（Notification）是"怎么告诉你"，状态页（Status Page）是"给谁看"。 建议按下面的顺序，10 分钟搭完一套真正有用的最小集合。

第 1 步：加站点可用性（HTTP）

点 + 新建监控项，类型选 HTTP(s)：

| 字段 | 建议值 | 说明 | |---|---|---| | 名称 | 官网首页 | 状态页上显示的就是这个名字 | | URL | https://你的域名/ | 要探测的地址 | | 心跳间隔 | 60 秒 | 个人站点够用；核心接口可设 20 秒 | | 重试次数 | 2～3 | 避免网络瞬抖造成误报（注意 v2 更新后，新建监控项的默认重试次数改为 0，即不重试，需要自己调） | | 请求超时 | 10 秒 | 超过即判定失败 | | 接受的状态码 | 200-299 | 默认；有特殊重定向需求再改 |

第 2 步：加端口存活（TCP）

数据库、Redis、内部服务的"通不通"用 TCP 更直接。类型选 TCP，填 你的业务机IP + 端口（如 3306 / 6379）。这比装一个客户端去连更快，也不会产生业务日志噪音。

第 3 步：加机器可达性（Ping）

类型选 Ping，填业务机 IP。它能告诉你"是整台机器没了"还是"只是 Web 服务挂了"——这两个结论对应的处置完全不同。

第 4 步（最值钱的一步）：用 Push 监控你的定时任务

"备份跑了没跑成功"是自托管用户最容易漏掉、也最危险的一环：备份脚本默默失败几个月，直到真正需要恢复时才发现没有可用备份。Uptime Kuma 的 Push 类型专门解决这个问题——它反过来：由业务机定时来"报到"，超过设定时间没报到就告警。

在界面新建一个类型为 Push 的监控项，名称填"每日备份"，心跳间隔设为 26 小时，然后把界面给出的上报 URL 复制出来。在业务机的备份脚本末尾加上一行：

`bash // 把 URL 换成监控项页面里给出的 Push URL（含你的 Token） curl -fsS --max-time 10 "https://status.yourdomain.com/api/push/你的TOKEN?status=up&msg=backup-done" `

再配好定时任务。下面的 crontab 表示每天凌晨 3 点执行备份脚本，只有备份成功（脚本返回 0）才会报到：

`cron 0 3 * /root/backup.sh && curl -fsS "https://status.yourdomain.com/api/push/你的TOKEN?status=up&msg=backup-done" > /dev/null `

这样任何一次备份失败或卡死，26 小时后都会触发告警。同样的模式可以套在爬虫、数据同步、证书续期脚本上——凡是"应该周期性发生、但没人盯着"的任务，都值得挂一个 Push 监控。

七、通知配置：以 Telegram 为例（附国内渠道对照）

Telegram 机器人（响应最快）

1. 在 Telegram 里搜 @BotFather，发送 /newbot，按提示起名，拿到形如 123456789:AA... 的 Bot Token； 2. 给新机器人发一条任意消息（否则它无法主动给你发消息）； 3. 搜 @userinfobot 或把消息转发给 @getidsbot，拿到你的 Chat ID； 4. 回到 Uptime Kuma，设置 → 通知 → 新建通知，类型选 Telegram，填入 Bot Token 与 Chat ID； 5. 点 测试（Test），手机上收到消息即配置成功。

> ⚠️ 服务器在国内、Telegram 不可用的情况：Uptime Kuma 的 Telegram 通知是由监控机出站去请求 Telegram API 的。如果监控机在国内且无法直连，需要在 设置 → 代理 里配置 HTTP 代理，或者改用下面的国内渠道。

国内常用渠道对照

| 渠道 | 需要什么 | 适合谁 | |---|---|---| | 飞书（Feishu） | 群机器人 Webhook 地址 | 团队用飞书协作，告警直接进群 | | 钉钉（DingDing） | 群机器人 Webhook（建议加关键词校验） | 国内团队最常见的选择 | | 企业微信（WeCom） | 应用或群机器人 | 企业内部通知、有审计需求 | | Bark | iOS 应用生成的 Key | 个人 iOS 用户，推送零延迟 | | Server 酱 / PushDeer / WxPusher | 各自的服务 Key | 想推送到微信的个人用户 | | Webhook | 一个能收 POST 的地址 | 想接入自建系统（如 n8n、自建工单） |

配置纪律：至少两条渠道。 一条即时通讯 + 一条邮件。原因很简单——渠道本身也会挂，而"告警渠道挂了"这件事没有任何工具会替你告警。

八、发布公网状态页：把"我们服务正常"变成一条链接

状态页（Status Page）是 Uptime Kuma 相对同类自托管工具最突出的能力：你可以挑几个监控项公开出去，生成一个干净的状态页面，客户、同事、自己都能一眼看到"哪个服务正常、哪个在故障、过去 90 天可用率是多少"。

创建与配置

1. 进入 状态页 → 新建状态页，填名称（如"服务状态"）和 slug（如 status，最终形如 status.yourdomain.com/status/status，也可以在下一步绑定独立域名）； 2. 在监控项分组里，把想公开的监控项加进去——只放对外可见的，内部的数据库、管理后台端口之类一律不要勾； 3. 自定义域名：在状态页设置里填 status.yourdomain.com。官方支持把状态页映射到指定域名，这样访问 https://status.yourdomain.com 直接就是状态页，而不是监控后台； 4. 可选：开启事件公告（Incident），故障时在状态页顶部写一段说明；也可以对历史事件做归档。

可用率徽章（Badge）

状态页可以给每个监控项生成一张 SVG 徽章，直接把"在线率/响应时间"贴到 README、官网或文档里。官方提供的接口形如：

` https://status.yourdomain.com/api/badge/监控项ID/uptime/24h https://status.yourdomain.com/api/badge/监控项ID/ping/24h `

注意 v2 的一个破坏性变更：徽章的 :duration 参数在 v2 里只接受 24、24h、30d、1y 这类格式，并且有上限（小时最多 720h、分钟最多 1440m、天最多 365d）。如果你从 v1 升级上来，旧链接里的自定义时长会失效，需要改回标准值。

九、备份、升级与加固：三件事按顺序做

备份：只有一个正确做法——备份 data 目录

这是 v2 里必须重新学习的规则。 官方在 v2 的迁移说明里移除了"从 JSON 备份/恢复"这个旧功能，明确写着：备份 data 目录是目前唯一被支持的备份方式。

`bash // 备份：把数据目录打包，存到异地（建议配合定时任务） cd /opt/uptime-kuma && tar czf /root/uptime-kuma-$(date +%F).tar.gz data/ `

恢复时反向操作即可：停容器 → 还原 data 目录 → 启动。注意数据库文件属于"热文件"，最好在容器停止状态下打包，或者用文件系统快照保证一致性。

升级：先备份，再看是不是跨大版本

日常小版本升级很简单：

`bash cd /opt/uptime-kuma docker compose pull docker compose up -d `

但如果是从 v1 升级到 v2，务必先读官方迁移说明，它有明确的破坏性变更：

- 必须、必须、必须备份 data 目录（官方原文把这句话重复了三遍）； - 迁移过程不能中断——它要把心跳数据聚合成新格式，官方一位作者 20 个监控项 + 90 天数据迁移了约 7 分钟，硬件慢或数据多时可能要几个小时；中断就必须从备份回滚重来； - 非 Docker 安装的最低 Node.js 版本提升到 20.4（不再支持 14/16/18）； - Docker 的 Alpine 镜像已被移除；同时官方提醒，rootless 镜像不建议用于 v1→v2 升级，容易启动失败； - SMTP 邮件通知的模板引擎换成了 LiquidJS，变量大小写敏感、不匹配的变量会被忽略，升级后如果邮件内容是空的，就是这一条导致的。

加固清单

- [ ] 3001 端口只监听 127.0.0.1（第五节已改） - [ ] 面板开启 2FA，恢复码已离线保存 - [ ] 全站 HTTPS，用 Certbot 自动续期 - [ ] 必要时在 Nginx 层再加 basic auth，或用 Cloudflare Access 兜底 - [ ] 定期导出并异地保存 data 目录备份 - [ ] 只把该公开的监控项放进状态页，内部服务不放

十、自建 vs 商业监控服务：算清这笔账

"免费 SaaS 就够用，为什么要自建？"这是个好问题，答案取决于三件事：监控点数量、探测频率、数据归属。

| 方案 | 成本量级 | 探测频率 | 数据归属 | 主要代价 | |---|---|---|---|---| | Uptime Kuma 自建（本文） | 服务器约 $60～$170/年（1核1G～1核2G） | 最快 20 秒，可自设 | 完全在你自己机器上 | 要自己运维、自己备份、单点探测 | | 商业 SaaS 免费档 | $0 | 通常 5 分钟 | 厂商 | 频率低、监控点数量受限、无 SLA | | 商业 SaaS 付费档 | 按监控点阶梯计费，年费量级通常在百美元上下并随监控数与频率上浮 | 1 分钟或更快 | 厂商 | 监控越多越贵；数据不在自己手里 | | 商业 SaaS + 自建组合 | 自建成本 + 少量 SaaS | 混合 | 混合 | 配置两套通知逻辑 |

结论：如果你只有少数几个站点、能接受 5 分钟粒度的告警，免费 SaaS 完全够用，自建是"杀鸡用牛刀"。但只要出现下面任一情况，自建就开始划算：① 监控项超过 20 个；② 需要 20～60 秒级探测（很多故障在 5 分钟里已经损失了真实订单）；③ 需要公开状态页并自定义域名；④ 不想把"我有哪些服务、什么时候挂过"这类信息交给第三方。 一台 $5/月 的轻量 VPS，就能换来不限监控点数、不限探测频率、数据自主的监控体系——这也是本系列反复出现的那笔账：自托管的成本是一台固定机器，SaaS 的成本是随规模线性上涨的订阅费。

常见问题 FAQ

Q1：Uptime Kuma 和 Prometheus + Grafana 到底怎么选？两个能一起用吗？

能，而且强烈建议一起用，它们回答的是两个不同问题。 Uptime Kuma 回答"服务活着吗、响应快不快、挂了通知谁"——它是可用性层，配置成本极低；Prometheus + Grafana 回答"CPU/内存/磁盘/连接数现在是多少、趋势如何"——它是指标层，配置成本高但能看到根因。真实运维里最常见的组合正是：Uptime Kuma 负责"第一时间报警 + 对外状态页"，Prometheus 负责"报警之后去哪找原因"。本站另有一篇 Prometheus + Grafana 完整教程，两篇可以搭配着读。

Q2：反向代理配好了，页面能打开但一直转圈、监控状态不刷新，是什么问题？

九成是 WebSocket 头没传。 Uptime Kuma 与普通 Web 应用不同，它基于 WebSocket，官方要求反向代理必须额外传递 Upgrade 和 Connection "upgrade" 两个头，并且 proxy_http_version 要设为 1.1。请对照本文第五节的 Nginx 配置逐行检查这两行；如果用 Nginx Proxy Manager，则要勾选 "WebSockets Support"。第二个可能原因是把它部署在了子目录（如 /uptimekuma）下——官方明确不支持子目录部署，必须用独立域名或子域名。

Q3：1 核 1G 的服务器能跑多少个监控项？

个人场景（10～30 个监控项、60 秒间隔）1核1G 绰绰有余，常驻内存通常只有几百 MB。当监控项上百、或大量使用 20 秒间隔时，建议升到 1核2G / 2核2G，主要不是 CPU 不够，而是探测并发和 SQLite 写入带来的瞬时内存峰值需要余量。另外记住一条：监控机不要和它监控的业务挤在同一台小机器上，否则业务内存打满时监控进程会第一个被杀。

Q4：数据会丢吗？正确的备份方式是什么？

正确且唯一的官方支持方式是备份 /app/data 目录——Uptime Kuma 的账号、监控项、通知配置、历史数据全在这个目录里（数据库是 SQLite）。特别注意：v2 已经移除了旧版"从 JSON 备份/恢复"的功能，网上很多老教程还在教你导出 JSON，那在 v2 上已经不可用。备份命令见本文第九节；建议在容器停止状态下打包，或配合文件系统快照，避免拷到不一致的数据库文件。备份本身也推荐用 Push 监控兜底（第六节），否则"备份默默失败"这件事没人会告诉你。

Q5：能监控国内的服务吗？监控机应该放在哪里？

能，但要考虑网络路径。最佳实践是把监控机放在与业务机不同的机房——同一机房断网时，监控和业务一起失联，你收到的是"一切正常"的假象。如果业务在国内、你希望告警及时，监控机放香港通常能兼顾到国内的延迟与到海外的可达性；如果业务在海外，监控机放另一个海外区域（例如业务在硅谷、监控在香港或新加坡）。如果从海外监控机探测国内目标不稳，可以在 设置 → 代理 里配置出站代理。

Q6：既然有免费的 UptimeRobot，为什么还要自建？

免费 SaaS 的价值在于"零维护"，代价是频率与数据归属：免费档通常只有 5 分钟探测间隔（很多故障在这段时间里已经造成了真实损失），监控点数量有上限，而且你的服务清单、故障历史都存在别人的数据库里。自建换来的三样东西是：探测频率可以调到 20 秒、监控点数量不受限、数据完全自主。如果这三样对你都不重要，那免费 SaaS 是更理性的选择——诚实地说，这个判断没有标准答案。

Q7：状态页会不会暴露我的服务器 IP 或内部信息？安全吗？

状态页只显示你主动勾选进去的监控项名称、状态、响应时间与可用率，不会显示 IP、端口或内部拓扑——但前提是你只把该公开的监控项放进去。请遵守两条纪律：① 数据库、Redis、管理后台端口这类内部监控项一律不要加入状态页，尤其是监控项名称不要写成"数据库 3306 端口"这种暴露结构的名字；② 状态页对应的是独立域名，而管理后台要走 HTTPS + 2FA，必要时在 Nginx 层再加 basic auth 或 Cloudflare Access。这样"状态页公开、后台锁死"，才能兼顾对外透明与自身安全。

Q8：监控项涨到 100+、要覆盖多个机房，怎么扩展？

Uptime Kuma 是单进程单实例设计，没有官方集群模式，扩展方式只有两条：① 纵向——升配置（2核4G）、拉长心跳间隔、定期清理历史数据；② 横向——在不同机房各部署一套 Uptime Kuma，各自负责本区域目标，状态页分别对外发布，再用一个总揽页面（或商业 SaaS 的免费档）做统一入口。不要指望单套 Uptime Kuma 扛住所有机房的探测，因为"探测机和被监控服务同机房"这个结构性缺陷无法靠加配置解决。

十一、总结

用海外云服务器搭建 Uptime Kuma，整条链路其实就是十步：买一台便宜的轻量 VPS → 系统初始化并收敛端口 → 装 Docker → 写 compose 挂好 ./data 卷 → 一条命令拉起服务 → 创建管理员并立刻开 2FA → Nginx 反向代理（记得 WebSocket 两个头）+ Certbot 自动 HTTPS → 加监控项（HTTP/TCP/Ping + Push 心跳）→ 配通知渠道（至少两条）→ 发布公网状态页 → 定期备份 data 目录。一台 $5/月 的小机器，换来的是"服务一挂你就知道"和一条可以发给客户的状态页链接。

真正决定这套监控能不能在关键时刻救你的，不是命令，而是三个判断：第一，监控机要和业务机分开，否则断网时监控和业务一起消失，你买到的是虚假的安心；第二，通知渠道至少配两条，因为"告警渠道自己挂了"没有任何工具会替你兜底；第三，备份必须备 data 目录（v2 已不再支持 JSON 备份），而且最好用 Push 心跳监控把备份本身也盯上——备份默默失败是自托管里最贵的一种故障。

最后回到一个诚实的边界：Uptime Kuma 是可用性监控，不是性能监控。它告诉你"服务挂了、响应变慢了"，但不会告诉你"为什么"。把它和 Prometheus + Grafana 组合起来——一个负责第一时间发现和公示，一个负责事后定位根因——才是一套完整、且成本仍然可控的自托管监控体系。把它的边界说清楚，比把它吹成万能工具更有价值。

延伸阅读： - Prometheus + Grafana 监控告警系统完整教程：从指标采集到可视化告警 - Nginx 反向代理 + Let's Encrypt 免费 SSL 证书配置完整教程 - Docker + Portainer 容器管理平台搭建完整教程 - 数据备份与容灾恢复完整教程：快照 + 异地备份 + 恢复演练 - 接入 Cloudflare CDN 免费加速 + 全站 HTTPS 完整教程 - 网站安全加固完整教程：fail2ban + ModSecurity + 安全响应头

> 本文由 5.chengzicloud.cloud 提供，点击访问首页了解更多海外云服务器部署方案和专属优惠。