Uptime Kuma 部署实战：极空间监控网站、SSL 与 TCP 端口，再配置远程访问

前言

监控这件事最容易踩的坑，不是“不会装”，而是装完以后就以为自己已经安心了。

Uptime Kuma 页面能打开，只代表监控工具本身跑起来；真正有用，还得继续做几件事：加监控项、确认探测正常、看清到底监控的是网站还是端口，再考虑自己不在家时怎么查看这套监控。

这几层如果混在一起，很容易出现一种假安全感：仪表盘是绿的，但真正关心的服务根本没被监控；或者监控本身正常，可一离开局域网就看不到页面。

所以这次不把 Uptime Kuma 写成“装上就能告别宕机焦虑”的万能工具，而是按实际操作把链路拆开：

极空间 SSH / Docker → Uptime Kuma → 3005 管理页面 → HTTP(s) + SSL 过期提醒 → TCP 端口监控 → cpolar → 3005 随机公网访问 → Uptime-Kuma 固定二级子域名。

这套流程更适合一种偏谨慎的运维习惯：

宁可多确认一次，也不要把“监控工具在线”误当成“所有业务都被监控好了”。

1. Uptime Kuma 真正负责什么？

Uptime Kuma 是一套自托管的可用性监控工具。

它可以用来监测网站、API、端口、Ping、DNS 等服务是否可达，并在界面中查看状态和响应时间。文章里还介绍了 Docker、Steam、gRPC、MySQL、PostgreSQL、Redis，以及大量通知渠道等能力。

不过这次真正实际演示出来的内容很集中：

• Uptime Kuma Docker 部署；
• 创建登录账号；
• HTTP(s) 网站监控；
• SSL 证书过期提醒；
• TCP 端口监控；
• MySQL 3306；
• Redis 6379；
• cpolar 远程访问 Uptime Kuma 页面；
• 固定二级子域名。

因此，更准确的定位是：

先把“服务现在到底通不通”这件事变得可见。

至于 90+ 通知渠道、资源占用、80k GitHub 星标、高可用、多用户权限等信息，可以帮助了解项目，但并不是这次环境里逐项测出来的结果。

2. 部署前先确认 SSH 和 Docker

2.1 SSH 连接极空间

先开启 SSH 服务，然后从 Windows PowerShell 或 Mac Terminal 登录：

ssh root@IP

如果还没有配置 SSH，可以参考对应的极空间 SSH 教程。

2.2 检查 Docker

继续确认 Docker 是否可用：

docker -v
systemctl status -v

这里的 systemctl status -v 按现有命令记录保留，不自行改写。

这一步的目的很简单：

容器环境先确认正常，再往上放监控工具。

3. 两种方式部署 Uptime Kuma

3.1 Docker Compose

先创建目录：

mkdir -p /docker/Uptime Kuma
chmod -R 777 /Uptime Kuma

这里有一个明显的路径写法需要照原记录保留：

• mkdir -p /docker/Uptime Kuma
• chmod -R 777 /Uptime Kuma

路径中包含空格，而且两条命令使用的目录也并不完全一致。这一版不擅自替换。

接着创建并编辑：

docker-compose.yml

vi docker-compose.yml

Compose 配置如下：

version: "3.8"

services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
– "3005:3001"
volumes:
– ./data:/app/data
environment:
– TZ=Asia/Shanghai

这里使用的是：

• 镜像：louislam/uptime-kuma:2
• 容器名：uptime-kuma
• 重启策略：unless-stopped
• 端口：3005:3001
• 数据目录：./data:/app/data
• 时区：Asia/Shanghai

然后启动：

docker-compose up -d

3.2 docker run

如果不使用 Compose，也可以直接执行：

docker run -d –restart=always -p 3005:3001 -v uptime-kuma:/app/data –name uptime-kuma louislam/uptime-kuma:1

这里又出现一个需要保留的版本差异：

• Compose 镜像：louislam/uptime-kuma:2
• docker run 镜像：louislam/uptime-kuma:1

两种方式的镜像标签不同，本版不擅自统一。

部署完成以后，浏览器打开：

http://极空间IP:3005

看到 Uptime Kuma 页面，只能说明监控平台已经跑起来。

真正的监控还没开始。

4. 先把 Uptime Kuma 本身管理好

常用容器管理命令如下：

# 查看容器状态
docker ps | grep uptime-kuma

# 查看日志
docker logs -f uptime-kuma

# 停止容器
docker stop uptime-kuma

# 启动容器
docker start uptime-kuma

# 重启容器
docker restart uptime-kuma

# 删除容器（数据不会丢失）
docker rm -f uptime-kuma

接着创建用户名和密码。

登录以后进入 Uptime Kuma 主界面。

到这里第一层结束：

Uptime Kuma 已经能正常启动、登录和管理。

接下来才是最重要的部分——建立真实监控项。

5. 先监控一个 Web 服务，再加 SSL 过期提醒

这次使用网站做 HTTP(s) 监控示例。

操作路径是：

示例监控的是：

首页

保存以后，监控状态正常。

这一层验证的其实是两件事：

• 网站 HTTP(s) 可用性监控已经建立；
• SSL 证书过期提醒选项已经配置。

这并不等于“已经模拟过一次 SSL 真过期并收到通知”，因为这次没有做这样的故障演练。

6. 网站能打开，不代表数据库端口也正常

这是监控里很容易忽略的一点。

一个 Web 页面还在线，不代表后端数据库或中间件一定正常。

所以这次又增加了 TCP Port 监控。

配置方式是：

保存以后，TCP 监控状态正常。

到这里，Uptime Kuma 的监控范围已经不只是“一个网站有没有响应”，还加入了具体端口可达性。

但要注意：

TCP 端口可达，不等于数据库业务逻辑完全正常。

它只能说明目标端口当前能够建立对应探测，这个边界不要写过头。

7. cpolar 在这里到底解决哪一个问题？

这篇有一个很容易混淆的地方。

前面提到，当被监控服务在内网时，可以通过内网穿透让外部监控系统访问内部资源。

但后面的实际 cpolar 配置，并不是在穿透某个“被监控的数据库或网站”，而是在穿透：

Uptime Kuma 自己的 3005 管理页面。

所以这次真正完成的是：

人在外面也能打开 Uptime Kuma 监控面板。

而不是“已经通过 cpolar 把所有内网目标逐个暴露出来让 Uptime Kuma 探测”。

这个区别很重要。

8. 安装 cpolar

执行安装命令：

sudo curl https://get.cpolar.sh | sh

安装完成后查看服务状态：

sudo systemctl status cpolar

cpolar 服务起来以后，通过主机 IP + 9200 进入 Web 管理界面。

显示文字使用：

http://ip:9200

Markdown 链接目标则是：

http://localhost:9200/

这两种记录不一致，因此继续按现有内容保留，不自行统一。

登录以后即可为 Uptime Kuma 建立公网入口。

9. 先用随机域名验证 3005

进入【隧道管理 → 创建隧道】，配置如下：

• 隧道名称：Uptime-Kuma
• 协议：http
• 本地地址：3005
• 域名类型：随机域名
• 地区：China Top

创建以后，在在线隧道列表中可以看到生成的公网地址。

换到其他电脑或移动端访问。

页面能够正常打开。

这一步真正能确认的是：

Uptime Kuma 的 3005 管理页面已经可以通过公网地址访问。

先确认随机地址能通，再处理固定域名，会比一开始就把两件事揉在一起更容易排查。

10. 长期使用时，再换固定二级子域名

随机地址适合测试，但作为长期监控面板入口，固定地址更方便。

进入 cpolar 预留功能。

地区选择：

china Top

这次使用的二级子域名是：

Uptime-Kuma

然后回到 cpolar Web UI，在隧道列表中找到对应隧道并编辑。

修改为：

• 域名类型：二级子域名
• Sub Domain：填写保留成功的二级子域名
• 地区：China Top

点击更新。

最后使用固定公网地址访问。

页面能够正常打开。

到这里，固定远程监控面板入口配置完成。

总结

Uptime Kuma 真正解决的，不是“从此不会宕机”。

它解决的是：

服务出了问题以后，你能不能更早看到。

而这次实际跑通的是一条很明确的链：

极空间 → Docker → Uptime Kuma → 3005 → HTTP(s) 监控 → SSL 过期提醒 → TCP Port → MySQL 3306 / Redis 6379 → cpolar → 随机公网监控面板 → Uptime-Kuma 固定二级子域名。

能够确认的操作包括：

• ssh root@IP
• Docker 环境检查
• Docker Compose 部署
• louislam/uptime-kuma:2
• docker run 部署
• louislam/uptime-kuma:1
• 3005:3001
• ./data:/app/data
• uptime-kuma:/app/data
• TZ=Asia/Shanghai
• 创建用户名密码
• HTTP(s) 网站监控
• https://www.cpolar.com
• SSL 证书过期提醒
• 7 天
• 60 秒心跳
• TCP Port
• MySQL 3306
• Redis 6379
• 安装 cpolar
• 9200 Web UI
• 隧道名 Uptime-Kuma
• 本地地址 3005
• China Top
• china Top
• Sub Domain
• 固定二级子域名 Uptime-Kuma

这篇没有强行编“凌晨被用户叫醒”的第一人称事故。

更适合它的是一种踩坑共情型的运维视角：监控最大的坑，不是没有工具，而是把不同层次的“正常”混成一件事。

监控平台在线 ≠ 被监控服务一定正常。 TCP 端口可达 ≠ 数据库业务一定正常。 公网能打开 Uptime Kuma ≠ 所有内网监控目标都已经被穿透。 配置了 SSL 过期提醒 ≠ 已经实际演练过一次证书过期告警。

把这些边界分清楚，才比“2026 最强监控神器”“7×24 小时完全守护”“彻底告别宕机焦虑”更接近真正有用的监控经验。