自己搭了网站或 NAS 服务，平时觉得一直好好的。直到有人发消息说“你那个页面怎么打不开”，才发现它可能已经停了几个小时。手动打开看看当然可以，问题是没人会隔几分钟看一次。
Uptime Kuma 可以代替你定时检查：访问一个网址、试一下某个端口，或者找页面里是否出现预期文字。检查失败时，再通过配置好的渠道提醒你。
它解决的是“及时知道异常”，不是“自动修好服务”。这篇先监测一个自己管理的网站，接通一条通知，再做一次不影响真实访客的故障演练。仪表盘上的绿色好看，但能不能收到提醒，才是这套东西有没有用的分界线。
先想好让谁来观察网站
监测放在哪里，会影响它能发现什么。网站和 Kuma 都在同一台机器上，应用单独退出时或许能被发现；整台机器断电，监测也一起停了，就没有谁来给你发通知。
起步可以先装在已有的 NAS 上，用它观察外面的个人网站。认真依赖告警时，再考虑独立设备、不同位置，或者补一个托管监测服务。没有必要第一天就买服务器，但要知道目前的观察点有什么盲区。
家里能访问，也不等于外面的人能访问。反过来，用公网 URL 检查一个只想在内网使用的服务，也可能是在检查错误的入口。先写下目标：你想知道“这台机器还在线”，还是“访客能打开这个页面”？两者应选不同的检查方法。
用 Docker 装一个 2.x 实例
以下面向全新安装，采用官方仓库推荐的 louislam/uptime-kuma:2 镜像。它跟随 2.x 更新，不是固定补丁版本；长期使用时应记录实际版本，更新前看发布说明并备份。旧的 1.x 实例先读迁移指南，不要直接覆盖。
机器需要装好 Docker 和 Compose。先检查版本：
docker --version
docker compose version新建 uptime-kuma 文件夹，在里面保存 docker-compose.yml：
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"./data 放实例数据，位于配置文件旁边，要保留在可靠的本地磁盘上。官方明确提醒 NFS 存储不受支持，不要为了方便把数据库目录直接挂到一个 NFS 网络共享。
端口映射先限制在本机。保存后，在同一文件夹运行：
docker compose up -d
docker compose ps
docker compose logs --tail=100 uptime-kuma确认服务启动，浏览器打开 http://127.0.0.1:3001，按初次配置页面建立管理账号，使用独立强密码。不要让还没设好管理员的入口暴露在公网。
NAS 上部署、其他内网设备要访问时，可以改为 "3001:3001"，用 NAS 内网地址访问，并限制来源。公网管理则需要另行配置 HTTPS 和访问保护。官方反向代理文档有不同服务器的示例；普通状态页和管理后台不是同一个安全边界。
添加第一个网站检查
在界面里找到添加监测项的入口，类型选择 HTTP(s)，先取个能分辨的名字，例如“个人博客首页”。URL 填自己管理的网站完整地址，包含 https://，不要只写域名。
第一次可以设为每 60 秒检查一次，再设置适量重试，例如 2 次。这是起步建议，不是对所有服务最合适的答案。频率越高，请求越多；重试、超时和网络条件也会影响什么时候判定故障，不能仅按“60 秒”承诺一分钟内一定收到通知。
保存以后，等至少一轮检查完成。先看当前状态，再看失败原因和响应信息。刚新建的监测没有过去一个月的数据，不能把一小段绿色记录当成长期稳定性的证明。
如果网站有登录、反爬或来源限制，自动检查得到的页面可能和普通浏览器不同。检查 URL 要选适合这种访问方式的入口；不要为让图标变绿而关闭正式站点的安全规则。
返回 200，未必是你想看的页面
HTTP 检查适合回答“这个地址能否按预期响应”。但网站可能错误地展示了一个默认页、维护页，甚至把错误内容包装成 200。仅靠状态码，它仍有可能被判为正常。
这时可以再建一个 HTTP(s) 关键字检查，使用该页面应该稳定包含的文字。例如自己的博客名称，前提是它确实出现在服务器返回的内容里，而不只是浏览器执行脚本后才显示。
别用经常改的文章标题、当天日期或访问量数字作关键字，否则正常更新也会报警。反过来，关键字在一个错误页里也存在，这个检查依旧可能漏掉问题。它只是进一步缩小误判，不是完整的功能测试。
对于只需要确认某个内网服务端口能连接的情况，可以用 TCP 检查。但“端口开着”不证明数据库能写入、用户能登录或付款流程成功。网站的重要业务流程，需要另外的端到端验证，不应都交给一个首页探测。
还有一个 Docker 常见坑：监测项里填 localhost 或 127.0.0.1，指的是 Kuma 容器自己，不是宿主机，更不是你正在操作的笔记本。监测另一台设备，应使用容器能够访问的设备地址；同一 Docker 网络的服务可按实际网络配置使用服务名和容器端口。先弄清网络位置，再改地址。
通知要走通，也要绑定到监测项
安装完成后最容易漏的是这一节。Kuma 支持多种通知方式，具体配置见官方通知文档。先选一个自己确实会看的渠道，例如邮箱、Telegram 或现有的消息服务，不用一口气配五种。
按当前界面的字段填凭据和目标，再用测试功能发一条消息。确认真实收到，而不是只看页面提示请求发出了。然后回到刚才的监测项，确认已经选择这个通知渠道；“创建了通知配置”和“这个监测会使用它”是两件事。
令牌、Webhook 地址和邮箱应用密码都属于凭据。别把完整配置截图放博客，也不要把它们提交到公开仓库。测试通知里有些信息同样会进入第三方平台，敏感服务的名称应当有所节制。
有些通知平台还依赖机器人权限、聊天对象初始化或网络出口。测试失败时，先按照那个平台的官方要求检查，不要把真实令牌发给陌生人“帮忙试试”。
做一次不会影响访客的故障演练
不要为了测试告警直接把正式网站关掉。更稳妥的方式是额外建立一个临时监测，先指向你自己控制、正常可访问的测试页面，绑定同一通知渠道，确认它能通过检查。
然后只修改这个临时监测的目标，改到自己测试环境里一个已经确认不可达的地址或未监听端口。不要拿别人的网站做故障实验。等当前的检查、超时和重试流程结束，看状态是否转为故障，以及消息是否确实到达。
最后把目标改回原来的测试页面，再核对恢复状态和恢复通知。演练结束后暂停或删除这个临时监测，保留正式项目。这样测试的是整条告警链，不只是消息平台能不能收一条“测试成功”。
这一套仍不能证明所有故障都会被发现。Kuma 自己断网、通知平台异常、整台监测机器停机，都是额外的情况。重要服务需要第二个独立观察点，而不是把一条告警配置当成保险。
状态页、维护和备份，别留到出事再管
想给朋友或用户看服务状态，可以建立公开状态页，只加入适合公开的监测项。参考官方状态页说明，先检查显示名称与分组，别把 NAS 内网地址、管理入口或带令牌的 URL 暴露出去。
准备维护时，可以按维护功能说明安排维护时段，减少已知停机造成的干扰。维护结束也要确认监测恢复，别把所有项目长期暂停后忘了打开。
更新前备份 data 和 Compose 配置。对这份本地目录配置，先 docker compose stop uptime-kuma，复制完整目录到独立备份位置，再 docker compose start uptime-kuma；不要在数据库正在写入时随意只拷一个文件。恢复时使用副本和兼容版本，在独立测试环境验证，不覆盖唯一原数据。
项目采用 MIT 许可证。它适合个人网站、小团队和家用服务的基础检查，尤其是你需要自己控制监测与通知配置的时候。若需求是全球多个地区探测、有人值守的告警响应或完整业务验证，单个自托管实例并不够。先把一个目标、一条通知和一次故障演练做完整，再慢慢加项目，比先铺满仪表盘有用。
https://github.com/louislam/uptime-kuma
