如果你的 WordPress 网站在凌晨宕机，多数情况下你要等到第二天客户投诉才会知道——这中间流失的订单和搜索排名，往往比修复本身代价更大。本文教你如何用开源监控工具 Uptime Kuma 搭建自己的网站状态页，帮助你在 1 分钟内发现站点异常、自动记录可用率，并把服务状态透明地展示给用户。整个过程只需要一台独立的 VPS（虚拟专用服务器）加上 Docker 环境，不需要付费订阅任何监控服务。
为什么 WordPress 网站需要状态页
很多站长的监控方式是”自己隔几天打开网站看看”，这种方式有两个明显缺口：一是发现滞后，二是无法回答”最近 30 天整体稳不稳定”这类问题。外部拨测平台虽然能发告警，但状态数据存在别人的账号里，你既不能自定义展示，也不能把历史可用率直接给客户看。
状态页解决的是”透明度”问题：把探测结果、在线率、故障公告集中在一个公开页面上。对做外贸站点的团队来说，当客户询问”昨天网站是不是挂了”，你直接甩出一个带时间线的状态页链接，比翻聊天记录解释高效得多。
如果你还在为基础环境的稳定性发愁，可以先把主机层选对——我们建议参考 Hostease 的 虚拟主机方案，把服务器可用性交给专业运维，再用本文的方法做第二层主动监控。
Uptime Kuma 是什么：一台独立机器上的自托管监控
Uptime Kuma 是一个开源（MIT 协议）的自托管监控工具，在 GitHub 上长期保持 6 万以上 star，核心能力包括：
- 支持 HTTP(s)、TCP、Ping、DNS（域名解析服务）、关键词匹配等多种探测类型
- 探测间隔可低至 20 秒，失败时按设定次数重试再告警
- 内置告警通道：Telegram、邮件 SMTP、Discord、Webhook 等几十种
- 自带对外状态页（Status Page）功能，可绑定独立域名
- 数据全部存在本地，可用率报表默认保留可查
部署上有一条铁律：Uptime Kuma 必须运行在与被监控网站不同的机器上。如果你把它装在 WordPress 所在的同一台服务器，站点宕机时监控进程会一起挂掉，告警就成了摆设。常见的做法是买一台最低配的 VPS 或云服务器（云端租用的虚拟化独立主机）专门跑监控，这类轻量负载月成本很低。关于服务器上线前的基础检查，可以对照这篇云服务器上线检查清单逐项确认。
部署准备：一台[独立服务器](https://cn.hostease.com/dedicated-server/)加 Docker 环境
上一节说到监控机必须独立，这一节把准备工作列清楚。你需要一台至少 1 核 512MB 内存的小型服务器（推荐 1 核 1GB 起步，留出系统余量），操作系统选 Ubuntu 22.04 或 Debian 12 这类主流发行版，并提前做好两件事：
- 安装 Docker 和 Docker Compose：官方一键脚本
curl -fsSL https://get.docker.com | sh可以在 1-2 分钟内完成安装 - 配置防火墙只放行 SSH 和后续状态页要用的 80/443 端口，Uptime Kuma 默认的 3001 端口不要直接暴露公网
为什么强调”独立机器”？实际案例里曾有网友把监控装在网站同机，结果 WordPress 因为插件冲突整机卡死，监控和站点同时失联，等发现时已经停了 6 个小时。监控机本身负载极低（内存占用通常不到 100MB），所以选择入门配置即可，不必为它单独买高配方案。
用 Docker 部署 Uptime Kuma：5 分钟完成安装
环境就绪后，部署本身非常简单。推荐用 Docker Compose 方式，便于后续升级和数据迁移。在服务器上创建一个目录，写入如下 docker-compose.yml：
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
然后执行 docker compose up -d 启动。这里有两个细节值得注意：
- 端口映射写成
127.0.0.1:3001:3001，让服务只监听本机回环地址，之后用 Nginx 反代并加 HTTPS 再对外，比直接暴露 3001 端口安全得多 - 数据目录
./data挂载到宿主机，将来升级镜像时只需docker compose pull && docker compose up -d，监控历史不会丢
启动后浏览器访问 http://服务器IP:3001（本机测试时）或反代域名，首次进入会要求创建管理员账号，设置用户名和至少 8 位的密码即可进入主界面。
配置监控项：让每个关键服务都有探针
装好只是第一步，真正的价值在监控项配置。对 WordPress 网站来说，建议至少建 3 个探针，覆盖不同层次：
- HTTP 关键词监控：类型选 HTTP(s) – Keyword，填网站首页 URL，关键词设为首页特有的文字（比如品牌名）。它比普通 HTTP 200 探测更可靠——页面返回 200 但内容变成报错占位页时也能抓到
- TCP 监控：探测数据库所在主机的 3306 端口（如果数据库和 Web 分离），数据库挂了而前端还有缓存的场景靠它兜底
- HTTP 监控后台登录页：探测
/wp-login.php，确认管理入口可用
探测间隔建议 60 秒起步，失败重试 2-3 次再触发告警，避免运营商网络抖动造成误报。每个监控项建好后，可以先手动点”暂停”再恢复，验证状态切换和图表记录是否正常。
关于服务器层面的深度可用性问题（比如进程被 OOM 杀掉、磁盘写满导致的 502），单纯外部探测只能看到现象，排查思路可以参考这篇VPS 故障应急响应指南。
告警通知与对外状态页发布
探针只负责”发现问题”，”通知到人”要靠告警通道配置。在 Uptime Kuma 的”设置 → 通知”里添加渠道，以最常用的 Telegram 为例：找 BotFather 创建一个 bot 拿到 token，把自己的 chat id 发一条消息后通过 API 获取，填入 Uptime Kuma 测试发送，30 秒内手机收到”Down”通知就说明链路通了。邮件 SMTP 和 Discord Webhook 的配置思路相同，都建议先点测试按钮验证，再绑定到监控项。
对外状态页是 Uptime Kuma 区别于一般拨测工具的关键功能。操作路径是”状态页面 → 新建”，起一个名字后勾选要展示的监控项，发布后会得到一个形如 https://status.你的域名.com/status/pagename 的公开链接。可以把这个链接放进网站页脚”服务状态”入口，故障时在上面发一条公告，客户就不用反复来问。
状态页域名建议用独立子域名并通过 Nginx 反代到 3001 端口，配上 Let’s Encrypt 证书。整个过程里网站本身的可用率数据（90 天报表）会自动累积，续约客户谈判、故障复盘时都拿得出手。
常见问题与排障
部署后最容易踩的坑集中在三处，遇到问题时按这个顺序排查：
- 探测全部显示 Down 但网站明明正常：九成是监控机到目标站点的网络路由问题（比如境外监控机探测国内站点被拦截），换个探测点或加
--resolve测试即可定位 - Docker 容器反复重启：执行
docker logs uptime-kuma --tail 100看日志，多数是数据目录权限不对，chown -R 1000:1000 ./data后重启容器 - 状态页打不开但监控正常：检查 Nginx 反代配置里 WebSocket 升级头是否遗漏，状态页实时刷新依赖 WebSocket 连接
总结：把监控变成运维习惯
回顾整条链路：独立小服务器跑 Docker 部署的 Uptime Kuma，配置关键词探针盯住首页、数据库和管理后台，Telegram 告警把故障推到手机，状态页把可用率透明地展示出去。整套方案零订阅费用，搭建时间加起来不超过半小时，却能把”客户先发现宕机”的被动局面彻底扭转。
如果你需要一套开箱即用的高可用底座，可以考虑把 WordPress 本身迁移到专业托管的 虚拟主机上，配合本文的自建监控形成双保险。建议今天就动手：先把监控机开起来、加上首页探针，哪怕只监控一个 URL，也比完全没有探测强。后续可以逐步把证书到期、域名解析也纳入监控范围，让整个站点的关键依赖都处于注视之下。