本文将帮助你搭建一套可直接落地的 Uptime Kuma 自托管监控方案：用 Docker Compose 部署服务，配置 HTTP、TCP、DNS（域名解析系统）等监控项，接入通知渠道，并补上状态页、备份和上线验收清单。它适合网站、接口、业务后台已经上线，但不想把所有可用性数据都交给外部 SaaS 的团队。
根据 Uptime Kuma 官方说明，它支持 HTTP(s)、TCP、Ping、DNS Record、Push、Docker Containers 等多种监控类型，也支持多状态页和 90+ 通知服务。本文以一台 VPS（虚拟专用服务器）主机 为例，完成从部署、反向代理、监控项、通知、状态页到备份的闭环。
先判断：Uptime Kuma 适合监控什么，不适合替代什么
Uptime Kuma 的核心价值是“外部视角的可用性检查”。它会按固定间隔访问目标地址或端口，并记录成功、失败、响应时间和故障持续时间。对于中小网站、外贸站、轻量 API 和内部门户来说，这类检查往往更容易落地。
不过，它不应该被当成所有监控问题的答案。Uptime Kuma 能告诉你 HTTP 接口返回异常、TCP 端口不通、DNS 记录不符合预期，但它不会直接解释数据库慢查询、PHP-FPM 队列堆积、磁盘 I/O 抖动或应用代码错误。更完整的做法是：用 Uptime Kuma 做可用性入口，用系统级监控和日志分析解释故障原因。
如果你已经在整理服务器运维规范，可以把它和 服务器配置与运维内容 放在同一套上线清单里：应用部署完成后先验证首页、登录页、API 健康检查和关键端口，再把告警通知接入团队渠道。
部署前准备：一台小规格 [VPS](https://cn.hostease.com/vps/) 就能起步
Uptime Kuma 对资源要求不高，个人站点或小团队起步时，一台 1 vCPU、1GB 内存的 VPS 通常就能承载少量监控项。真正需要提前规划的是网络位置和数据持久化：监控节点最好与业务服务器分开；数据目录必须落盘，否则容器重建后历史记录和配置都会丢失。
建议准备以下条件：
- 一台 Linux VPS，开放 80/443 给反向代理，管理后台只通过 HTTPS 访问。
- 已安装 Docker Engine 和 Docker Compose Plugin，用于快速部署和升级。
- 一个独立子域名，例如
status.example.com或monitor.example.com。 - 一个通知渠道，例如邮件、Telegram、企业聊天工具或 Webhook。
这些要求决定后续维护成本。把 Uptime Kuma 放在独立节点上，哪怕规格很小，也能提供外部视角。
用 Docker Compose 部署 Uptime Kuma
官方 README 给出的 Docker Compose 安装方式很直接：下载 compose.yaml，执行 docker compose up -d，服务默认监听 3001 端口。为了便于长期维护，建议把配置固定在 /opt/uptime-kuma，并把数据挂载到独立 volume。
先创建目录：
sudo mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma
写入 compose.yaml：
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: always
ports:
- "127.0.0.1:3001:3001"
volumes:
- uptime-kuma:/app/data
volumes:
uptime-kuma:
这里把端口绑定到 127.0.0.1:3001，目的是避免管理后台直接暴露在公网。后续由 Nginx 或其他反向代理负责 HTTPS、访问控制和证书续期。启动服务：
docker compose up -d
docker compose ps
确认容器状态为 running 后，在服务器本机验证：
curl -I http://127.0.0.1:3001
如果返回 HTTP 响应头，说明应用已经启动。第一次访问网页时，Uptime Kuma 会要求创建管理员账号。密码应使用随机生成器创建，并单独保存在密码管理器中。
用反向代理保护管理入口
监控工具一旦能访问你的站点清单、通知渠道和状态页配置，就不应该裸露在公网端口上。最基础的做法是：只让本机 3001 接受连接，再用 Nginx 反向代理到 HTTPS 域名。
一个最小化 Nginx 配置可以这样写：
server {
listen 80;
server_name monitor.example.com;
location / {
proxy_pass http://127.0.0.1:3001;
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 X-Forwarded-Proto $scheme;
}
}
证书可以使用现有自动续期方案。正式使用前，建议再加三层保护：后台域名不要和公开状态页共用；管理路径只允许固定办公 IP 或 VPN 访问；通知 Token 不写入公开文档。对于运行 WordPress 或业务站点的团队，也可以参考 WordPress 运维相关文章，把监控后台、网站后台和服务器面板分开管理。
配置第一个 HTTP 监控项
Uptime Kuma 的 HTTP(s) 监控适合检查首页、登录页、健康检查接口和关键回调地址。不要只监控网站首页，因为首页可用不代表所有核心路径都可用。更实用的做法是从 3 个目标开始：公网首页、应用健康检查接口、一个必须登录前可访问的关键页面。
创建监控项时，可以先使用这些参数：
- 类型选择 HTTP(s)，URL 填写完整地址，例如
https://www.example.com/health。 - Heartbeat Interval 设为 60 秒，Retries 设为 2，避免短暂网络抖动立刻告警。
- Accepted Status Codes 保持
200-299，如果业务有 301 跳转，应明确确认跳转目标正确。 - Keyword 检查只用于稳定页面，动态页面不要依赖一段经常变化的文案。
保存后观察 5 到 10 分钟，确认响应时间曲线稳定、可用率正常，再加入通知。先让监控项稳定，再开启告警，可以减少配置阶段误报。
补充 TCP、Ping 和 DNS 监控
HTTP 监控能覆盖网页层，但很多故障发生在更底层。TCP 监控适合检查 22、25、443、3306 这类端口是否可连接；Ping 适合观察主机是否基本在线；DNS Record 适合检查域名解析是否仍指向预期记录。配置时要根据目标风险选择，而不是把所有服务器端口都加进去。
例如一个外贸站点可以这样拆分：
首页 HTTPS：检查访客是否能打开网站
健康检查接口：检查应用服务是否正常
443 TCP：检查 TLS 服务端口是否可连接
DNS A 记录：检查主域名是否解析到预期地址
如果你使用 TTFB 与主机优化 相关方法做性能排查，Uptime Kuma 的响应时间曲线可以作为早期线索：它无法替代真实用户监测，但能帮你发现“最近 24 小时外部访问是否明显变慢”。
设置通知：先小范围测试，再接入团队渠道
监控系统最容易被忽略的一步是通知验证。Uptime Kuma 支持邮件、Telegram、Slack、Gotify、Pushover、Webhook 等 90+ 通知服务。你可以选团队已经稳定使用的渠道，不必为了监控单独引入新工具。
配置通知时建议遵循两个原则。第一，测试阶段只发给维护者本人，不要直接接入大群；第二，消息要能让人判断下一步动作，例如包含监控项名称、故障开始时间、目标 URL 和当前状态。通知渠道创建完成后，在 Uptime Kuma 中点击测试按钮，再人为制造一次低风险故障，例如临时监控一个不存在的测试路径，确认恢复通知也能收到。
如果使用邮件通知，要关注 SMTP 账号权限和发信限制。不要使用个人主邮箱的长期密码，优先使用专用发信账号或应用密码。对于对外业务站点，Hostease 可以作为主机和基础环境规划的参考，但告警收敛、响应人和升级路径仍需要按团队值班方式制定。
备份与升级：别让监控系统成为单点风险
Uptime Kuma 的配置和历史数据存放在 /app/data 对应的数据卷中。使用 Docker volume 时，可以通过临时容器导出备份；也可以把 volume 挂载改为宿主机目录，便于纳入现有备份系统。公开状态页只展示主站访问、API 服务、客户后台这类名称，不暴露内部 IP、端口或后台路径。
一个简单的 volume 备份命令如下：
docker run --rm \
-v uptime-kuma_uptime-kuma:/data:ro \
-v "$PWD":/backup \
alpine \
tar czf /backup/uptime-kuma-data.tar.gz -C /data .
升级前建议先执行三件事：导出数据备份；记录当前镜像版本；在低峰期执行 docker compose pull && docker compose up -d。升级后不要只看容器是否启动，还要检查至少一个 HTTP 监控项、一个通知渠道和一个状态页是否正常。
上线验收清单：从“能跑”到“能用”
部署完成后，不要急着把它视为完成。监控工具只有在故障发生时能及时、准确、少噪音地提醒你，才算真正可用。下面这份清单可以作为上线验收：
- 管理后台只通过 HTTPS 访问，3001 端口没有直接暴露到公网。
- 至少有 3 个核心监控项：主站 HTTP、健康检查接口、关键 DNS 记录。
- 通知渠道已经测试过故障和恢复两种消息，不只测试“发送成功”。
- 状态页名称不包含内部 IP、端口、服务器代号或后台路径。
- 数据目录已纳入备份，并完成过一次恢复演练或测试导入。
如果你正在规划新站或业务迁移，可以把这份清单放到服务器交付流程里。先完成域名、证书、应用部署和日志轮转，再补上 Uptime Kuma 监控与通知。更多主机方案也可以从 Hostease 中文站 继续了解。
总结：自托管监控的重点是闭环，而不是免费两个字
Uptime Kuma 的吸引力在于免费、自托管、界面直观、部署门槛低。但真正让它产生价值的，不是少付一笔 SaaS 费用，而是把可用性检查、告警通知、状态页展示和数据备份串成闭环。它适合从一台 VPS、几个关键 URL、一个通知渠道开始，小范围验证后再扩展到更多服务。
对中小团队来说，推荐的落地路径是：先用 Docker Compose 部署；用反向代理保护后台；添加 3 到 5 个关键监控项；测试故障和恢复通知；最后再开放经过脱敏的状态页。这样搭建出来的监控系统不复杂，但足够实用，也更容易长期维护。