Windows下自建网站监控：Uptime Kuma部署与告警配置指南

先给结论如果你有一台经常开机的 Windows 电脑或服务器想随时知道自己的网站、接口、数据库、甚至家里跑的小服务到底还活没活着Uptime Kuma 是我这两年用过最省心的自建监控方案。这个开源项目界面做得像 Uptime Robot但数据完全掌握在自己手里不用注册任何第三方账号部署成本低到可以忽略。它监控的不只是网页——HTTP 接口的返回码、TCP 端口的连通性、DNS 解析是否正常、SSL 证书还剩几天、域名什么时候到期甚至主机 Ping 的延迟和丢包都能统一在一个看板里展示。服务挂掉的一瞬间它可以通过 Telegram、邮件、钉钉、企业微信等多条渠道推送告警比人肉盯着页面刷新强一个量级。这篇文章按 Windows 环境来写核心目标三个把 Uptime Kuma 装起来、把监控和告警配置到位、打通外网访问。全程不依赖编程基础命令复制就能跑。同时我会把每条方案的适用场景和取舍讲清楚毕竟“能通”和“稳定、安全地通”是两码事。1. 整体设计与方案选型1.1 Uptime Kuma 核心能力拆解Uptime Kuma 本质上是一个“自托管的运维监控面板”作者是 louislam在 GitHub 上开源Star 数已经很高社区活跃度也不错。它用 Vue 3 Node.js 编写默认跑在 3001 端口浏览器直接访问就是一个响应式 Web 界面支持简体中文。它的核心能力可以归纳成四块多类型监控HTTP(S)、TCP 端口、Ping、DNS、MySQL、Redis、Docker 容器、游戏服务器等几十种监控类型远超一般人对“网站监控”的认知。实时推送前端用 WebSocket 和后台通信监控状态变化时页面自动更新不用手动刷新。多渠道告警Telegram、邮件、Server酱、钉钉、企业微信、Slack、Discord 等九十多种通知集成基本覆盖了主流触达渠道。公开状态页可以生成一个对外展示的状态页支持分组、暗色主题、自定义域名很多开源项目主页上的“status page”就是拿它搭的。我最初只觉得它是个“挂了发邮件”的小工具实际用下来才发现证书到期提醒和状态页才是长期运营里最值钱的功能。对个人站长、小团队、自托管爱好者来说这套组合拳已经够用了。1.2 Windows 下两条部署路线怎么选Uptime Kuma 在 Windows 上主要有两条路Docker 容器和 Node.js 原生安装。两条我都试过对比下来差异非常明显。Docker 路线安装 Docker Desktop然后一条命令拉镜像启动容器。优点是部署快、升级快、卸载干净容器的数据目录和运行环境完全隔离换机器迁移也方便。缺点是 Docker Desktop 依赖 WSL2初次配置略折腾且后台常驻一点资源占用。Node.js 原生路线装 Node.js LTS 版本克隆仓库npm install再npm run start。优点是没有 Docker 依赖缺点却很实际——Uptime Kuma 底层用的 SQLite 库在 Windows 上经常要编译原生模块缺少 Visual Studio Build Tools 时大概率报错另外后台进程管理需要自己配 pm2 或 nssm升级时要手动停进程、拉代码、再重启麻烦得多。两条路线我用表格做个直观对比对比项Docker 路线Node.js 原生路线部署速度一条命令搞定需装 Node.js 并编译依赖升级维护拉新镜像重启即可手动停服务、拉代码、装依赖数据隔离容器内目录清晰混在项目目录易污染Windows 兼容依赖 WSL2安装一次终身受益原生进程偶发编译报错开机自启restart 策略自动拉起需额外配置进程守护我的结论很明确没特殊理由就选 Docker。接下来整个实操都以 Docker 路线展开。2. 部署前置准备把 Docker 环境搞定2.1 为什么 Docker Desktop 必须依赖 WSL2Docker Desktop 在 Windows 上有两套后端老版本用 Hyper-V新版默认走 WSL2。WSL2 的优势是轻量、启动快而且 Docker 的命令行体验和 Linux 服务器上几乎一致踩坑资料也最多。在开始之前先确认三件事系统版本Windows 10 2004 及以上或者 Windows 11老版本跑 WSL2 会遇到各种兼容问题。虚拟化开关进 BIOS/UEFI 确认 Intel VT-x 或 AMD SVM 已开启没开的话 WSL2 起不来。系统组件以管理员身份打开 PowerShell执行wsl --install它会自动装好 WSL 内核并启用虚拟机平台。装完记得重启一次。注意如果 CPU 不支持虚拟化或者单位的电脑有安全策略锁死了相关组件Docker Desktop 基本跑不起来。这时只能退回 Node.js 原生路线别在虚拟化层面死磕浪费时间。2.2 Docker Desktop 安装与配置去 Docker 官网下载 Docker Desktop for Windows安装包大概几百 MB。安装过程没什么难点但有两个地方留意安装向导里会让你选后端确认勾选“Use WSL 2 instead of Hyper-V”。安装完成后 Docker Desktop 会自动启动首次启动可能会弹一个 WSL 内核更新提示照着点就是。装完后它会要求你接受许可协议。个人学习和个人项目使用是免费的这点不用太担心。提示如果你之前装过旧版 Docker Toolbox 或 Hyper-V 后端建议先卸载干净再装新版本避免两套虚拟化组件打架。我见过好几例“Docker Desktop 一直卡在 starting”的同事最后都是因为旧组件残留。2.3 验证 Docker 环境是否可用打开 PowerShell执行docker version能正常输出版本号说明客户端已经 OK。再跑一个官方测试镜像确认后端可用docker run hello-world看到一段 “Hello from Docker!” 的说明文字环境就没问题了。如果docker run卡住或者报连接错误多半是 Docker Desktop 没真正启动右击系统托盘的 Docker 图标确认引擎状态。另外强烈建议在用户目录下创建一个.wslconfig文件来限制 WSL2 的资源占用尤其是内存只有 8GB 的机器。文件内容如下[wsl2] memory4GB processors2保存后执行wsl --shutdown再重启 Docker Desktop 生效。不限的话WSL2 在默认配置下可能吃光一半物理内存Windows 主机反过来卡到没法用这个坑我踩过。3. Uptime Kuma 部署实操与初始化3.1 启动容器一行命令的事Docker 环境就绪后打开 PowerShell执行下面这条命令docker run -d --restartalways -p 3001:3001 --name uptime-kuma -v uptime-kuma:/app/data louislam/uptime-kuma:1拆开解释一下每个参数方便你以后自己改配置-d后台运行容器。--restartalwaysDocker 启动时自动拉起容器进程崩溃也会自动重启。这是长驻服务的基本要求。-p 3001:3001把宿主机的 3001 端口映射到容器内的 3001 端口前者是你浏览器访问的端口后者是 Uptime Kuma 的固定监听端口。--name uptime-kuma容器名字后面操作会用到。-v uptime-kuma:/app/data把容器内的/app/data目录挂载到一个名为uptime-kuma的 Docker 卷上。监控配置、用户账号、数据库都在这个目录里容器删了数据也还在。louislam/uptime-kuma:1官方镜像1标签表示跟踪最新的 1.x 版本。启动后确认状态docker ps docker logs uptime-kumadocker ps里看到 STATUS 是 Up日志没有报错就成功了一半。浏览器打开http://localhost:3001应该能进入设置管理员的初始化页面。3.2 数据持久化与备份策略上面命令用的uptime-kuma卷是 Docker 命名卷数据实际存在 WSL2 的虚拟磁盘里。好处是干净隔离坏处是你在 Windows 资源管理器里直接看不到文件备份要绕一下。如果你希望数据目录直接落在 Windows 硬盘上方便手动拷贝备份可以把命名卷改成 bind mount 目录。比如先在 D 盘建一个D:\docker\uptime-kuma文件夹然后把启动命令改成docker run -d --restartalways -p 3001:3001 --name uptime-kuma -v D:/docker/uptime-kuma:/app/data louislam/uptime-kuma:1注意路径要用D:/docker/uptime-kuma这种斜杠写法反斜杠在某些命令解析器里会出问题。备份最稳妥的方式就是把整个数据目录打包。用命名卷的话可以这样操作# 在容器内打 tar 包 docker exec uptime-kuma tar -czf /tmp/uptime-kuma-backup.tar.gz /app/data # 拷贝到当前目录 docker cp uptime-kuma:/tmp/uptime-kuma-backup.tar.gz .用 bind mount 的话就简单了直接压缩D:\docker\uptime-kuma整个文件夹即可。注意Uptime Kuma 的所有配置、用户、监控历史都存在data目录下的 SQLite 数据库文件里。备份时最好先把容器停一下或者至少避免在写入高峰期备份否则拷出来的数据库文件可能是脏的。恢复时把备份文件放回数据目录重新启动容器即可。3.3 初始化管理员账号与基础设置首次打开http://localhost:3001时页面会要求创建管理员账号填用户名、密码、再确认一次密码。这里特别注意两点密码一定要强口令因为后期如果对外暴露这个账号就是唯一的防线。自托管没有“忘记密码邮箱找回”的功能密码忘了只能去数据库里手动改哈希折腾得很。建议用密码管理器记好。登录后第一件事点右上角设置把界面语言切换成简体中文主题可以选深色或浅色。别看这个操作不起眼日常看监控面板顺不顺眼全靠它。如果需要调整容器时间尤其是通知里的时间戳和浏览器对不上检查一下容器内时区docker exec uptime-kuma date如果显示的不是北京时间就在容器启动参数里加环境变量TZAsia/Shanghai后面第四节会给出完整的 compose 配置。3.4 用 docker-compose 固化配置命令行跑一次容易但记不住那么长一串参数也不是事。更推荐的方式是写一个docker-compose.yml把配置固化下来以后升级、迁移都靠它。Docker Desktop 自带 docker compose 插件直接新建文件services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma restart: always ports: - 3001:3001 volumes: - D:/docker/uptime-kuma:/app/data environment: - TZAsia/Shanghai然后在文件所在目录执行docker compose up -d查看运行状态docker compose ps。以后升级镜像就两行命令docker compose pull docker compose up -d提示升级前一定先备份数据目录。Uptime Kuma 跨版本升级时 SQLite 会做迁移万一中断数据文件可能损坏。有备份在手降级也好、修复也好都还有退路。4. 核心功能配置监控、告警、状态页4.1 添加第一个监控项类型与参数怎么填登录后台点“添加新监控”可以看到一大排监控类型。我先说最常用的两类HTTP(S) 监控适合监控网站、API、任意 HTTP 服务。核心参数如下名称方便自己识别比如“博客首页”。URL完整的地址比如https://example.com/health建议精确到具体路径而不是只写域名。心跳间隔默认 60 秒。监控外部站点时不要设太短太频繁会被对方安全策略拉黑监控自己内网服务可以压到 10~30 秒。超时时间默认 30 秒普通网站建议改成 5~10 秒能更快暴露问题。重试次数默认 0代表第一次失败就告警。想减少误报就设 1~2等连续失败几次再触发。期望状态码默认 200~299 自动判断。关键词有些页面 200 但其实已经是错误页比如登录框消失、首页出现 500 文案。这里填一个预期包含的关键字可以用来做深度校验。TCP 端口监控适合监控数据库、SSH、Redis、游戏服务器等。只需要填主机地址和端口原理就是“能不能建立 TCP 连接”。比如家里 NAS 的 SSH 端口 22或者自建的 MySQL 3306。Ping 类型我一般用得少因为 ICMP 在部分云主机和家庭宽带上会被过滤容易产生假告警。DNS 类型则适合监控域名解析是否正常。新手先玩转 HTTP 和 TCP 两种已经覆盖 80% 场景。4.2 告警通知渠道配置与验证监控的意义在于“出事能第一时间知道”所以通知配置是重中之重。路径是“设置 - 通知 - 添加通知”支持的通知类型非常多。我挑三种最常用的说说Telegram先找 BotFather 创建机器人拿到 token再获取你的 chat ID给机器人发条消息后通过 getUpdates 查。填入 token 和 chat ID点测试手机收到消息就成功。SMTP 邮件国内用 QQ 邮箱或 163 邮箱比较多。以 QQ 邮箱为例SMTP 服务器是smtp.qq.com端口 465 选 SSL密码不是邮箱登录密码而是邮箱设置里生成的“授权码”。这一步经常有人填成真实密码然后一直认证失败。Server酱 / 钉钉 / 企业微信这类国内渠道基本都走 webhook填一个 URL 即可。Server酱绑定微信后直接在微信收告警个人用很方便。配置完成后一定要点“发送测试通知”亲自收到一条消息再算通过。然后要把通知挂到具体的监控项上——很多新手在后台配好了通知却忘了在监控项的“启用通知”里勾上结果服务挂了半天一条消息都没收到。4.3 公开状态页几分钟生成一个对外展示页面状态页是 Uptime Kuma 最容易给人留下印象的功能。你在后台点“状态页 - 新建状态页”填一个 slug比如status选好要展示的监控项按分组排好保存后访问http://localhost:3001/status/status就是一个干净漂亮的公共状态页。你可以决定它公开还是需要密码甚至能自定义 CSS。很多开源项目主页底部挂的绿色状态卡片其实就是这么来的。如果你希望状态页对外暴露但后台管理不暴露注意路径规划用反向代理或 Tunnel 时把status路径单独对外管理页面留在内网这是比较稳妥的做法。另外状态页还提供了 JSON 接口格式类似/api/status-page/heartbeat/slug可以把监控数据接到自己的监控大屏或者其他展示面板上。4.4 SSL 证书监控这个隐藏大杀器很多人用 Uptime Kuma 只盯着“网站挂没挂”忽略了它一个非常实用的功能证书到期提醒。现在全站 HTTPS 是标配而证书过期导致的站点“假死”事故比服务器宕机还常见。在 HTTP 监控项的高级设置里打开“证书过期”选项然后配置好通知渠道Uptime Kuma 就会在证书即将到期时提前推送提醒。我自己就把重要域名的证书监控都加上了提前 14 天收到告警邮件续期完全可控再也没有“半夜发现证书已经过期”的尴尬。5. 外部访问实操三种路线打通公网这一节是标题里的重头戏。“外部访问”在实际落地时有个前提条件要先搞清楚你家里宽带到底有没有公网 IP。没有这个前提端口映射做得再对也是白搭。5.1 有公网 IP路由器端口映射 DDNS第一步确认采集本机内网 IP。PowerShell 执行ipconfig找到当前上网网卡的 IPv4 地址类似192.168.1.100。然后登录路由器管理页看 WAN 口获取到的 IP 是不是公网地址。如果 WAN 口 IP 是100.64.x.x、10.x.x.x、192.168.x.x这类保留地址说明你被运营商放在了大型 NAT 后面属于大内网直接端口映射没戏需要打运营商客服申请公网 IP。第二步给本机固定内网 IP。在路由器 DHCP 设置里做 IP 绑定保证192.168.1.100这个地址不会因为重启而变。否则端口映射规则写死一个地址机器 IP 一变就全失效。第三步配置端口映射。路由器管理页一般叫“端口映射”或“虚拟服务器”。添加一条规则外部端口填 3001或自定义一个高位端口如 8600内部 IP 填192.168.1.100内部端口填 3001协议选 TCP。保存后从外网访问http://公网IP:8600即可到 Uptime Kuma。这里有个选择要不要把外部端口也设成 3001建议换一个不常用的高位端口能少挨点扫描器的问候。第四步Windows 防火墙放行端口。很多教程漏了这一步。以管理员身份打开 PowerShell执行New-NetFirewallRule -DisplayName Uptime Kuma 3001 -Direction Inbound -Protocol TCP -LocalPort 3001 -Action Allow不加这条规则端口映射配得再好Windows 防火墙也会把请求拦在系统外。第五步DDNS 绑定动态 IP。家庭宽带的公网 IP 大多不是固定的隔几天就变一次。解决办法是在路由器上开启 DDNS 功能绑定一个域名比如home.xxx.com。路由器内置支持花生壳、No-IP、DynDNS 等选一个注册好账号填进去之后就能用http://home.xxx.com:8600访问了。注意家庭宽带一般封了 80 和 443 端口所以别指望直接用域名不带端口访问 Web 服务。用高位端口映射是最省事的方案。另外直接用 IP 加端口访问会有 SSL 证书告警如果想让浏览器地址栏干净可以配合反向代理和域名来解。5.2 没有公网 IPCloudflare Tunnel 快速打通没公网 IP 也别急Cloudflare Tunnel官方工具叫 cloudflared是目前自托管圈最省心的解决方案。它的原理是你的 Windows 机器主动向外连接 Cloudflare 边缘网络形成一条隧道用户访问你的域名时流量先到 Cloudflare再从隧道转回本地。整个过程不需要路由器开任何端口也不依赖公网 IP。前提条件你需要一个域名并且把域名的 DNS 托管到 Cloudflare免费套餐即可。第一步下载 cloudflared。从 GitHub 的 cloudflared 仓库下载 Windows 64 位可执行文件重命名为cloudflared.exe放到比如C:\cloudflared目录里。第二步登录授权。在C:\cloudflared目录执行.\cloudflared.exe tunnel login浏览器会弹出 Cloudflare 登录页面授权后会在本机生成cert.pem证书文件。第三步创建命名隧道.\cloudflared.exe tunnel create uptime-kuma执行后会在C:\Users\你的用户名\.cloudflared\下生成一个tunnel-id.json先记下这个 tunnel ID。第四步写配置文件。在C:\cloudflared下新建config.ymltunnel: 你的tunnel-id credentials-file: C:\Users\你的用户名\.cloudflared\tunnel-id.json ingress: - hostname: kuma.example.com service: http://127.0.0.1:3001 - service: http_status:404第五步解析域名.\cloudflared.exe tunnel route dns uptime-kuma kuma.example.com这条命令会在 Cloudflare 里自动创建一条 CNAME 记录指向隧道地址不需要去控制台手动添加。第六步启动隧道.\cloudflared.exe tunnel run uptime-kuma看到Registered tunnel connection字样隧道就通了。浏览器访问https://kuma.example.comHTTPS 证书自动签发直接进入 Uptime Kuma。第七步做成开机自启。用管理员权限执行.\cloudflared.exe service install如果服务方式启动时报找不到配置文件把config.yml放到服务账户可访问的位置比如C:\Windows\System32\config\systemprofile\.cloudflared\再重新service install。不想折腾服务也可以用“任务计划程序”每次开机启动cloudflared tunnel run uptime-kuma这条命令效果一样还好排查。提示如果只是想临时测试可以不建命名隧道直接执行.\cloudflared.exe tunnel --url http://localhost:3001Cloudflare 会给你一个随机的xxx.trycloudflare.com地址有效期到进程结束。但这个地址每次重启都会变只适合演示不适合长期使用。5.3 域名加反向代理的进阶玩法如果你有公网 IP也有自己的域名我建议在 Uptime Kuma 前面加一层反向代理而不是裸奔式地暴露端口。反向代理解决两个问题一是提供标准的 443 端口 HTTPS 访问地址栏干净二是可以在代理层统一加访问控制。以 Caddy 为例它对个人用户特别友好配置简单自动申请和续期 HTTPS 证书。在 Windows 上把 caddy.exe 放在某目录写好Caddyfilekuma.example.com { reverse_proxy 127.0.0.1:3001 }然后执行caddy runCaddy 会自动把kuma.example.com的 HTTPS 证书搞定并把流量转发到本机 3001 端口。如果你更喜欢图形界面可以在 Docker 里再跑一个 Nginx Proxy Manager通过网页填表方式添加“代理主机”效果类似学习成本更低。缺点是多一个容器要维护但对不习惯写配置文件的人来说完全值得。5.4 外网暴露的安全加固清单Uptime Kuma 很强大但它本身是一个管理面板不像企业级产品那样自带 WAF 之类的防护。一旦对外暴露下面几条一定要做强密码加双因素认证后台开启 2FA用 TOTP 验证器如 Google Authenticator、Microsoft Authenticator绑定登录时需要动态验证码。优先用域名加 HTTPS 访问无论是 Cloudflare Tunnel 自动签发的证书还是反向代理签发的证书都比裸 IP 加明文 HTTP 安全得多。不要直接把 3001 管理端口暴露公网如果条件允许把管理页面限制在内网只把状态页路径对外。用 Cloudflare Tunnel 的话可以配合 Cloudflare Access 给管理路径再加一层身份验证。定期备份数据目录自托管服务的最大风险从来不是攻击而是磁盘损坏和误操作。备份到 U 盘、网盘或另一台机器都行。及时升级关注 Uptime Kuma 的 Release 页面有安全更新就执行docker compose pull docker compose up -d旧版本长期不升级是自找麻烦。6. 常见问题与排查技巧实录6.1 Docker 环境类问题问题一Docker Desktop 一直卡在 starting。先重启 Docker Desktop再不行就执行wsl --shutdown后重新打开。如果仍然卡住检查是否装了旧版 Docker Toolbox 或 Hyper-V 模块冲突卸载干净再装 Docker Desktop。问题二提示 WSL 2 installation is incomplete。管理员 PowerShell 执行wsl --update升级 WSL 内核后重启。问题三WSL2 吃内存太狠。按 2.3 节配置.wslconfig限制 memory 和 processors然后wsl --shutdown重启 WSL。问题四容器起来了但 localhost 打不开。先docker ps看容器状态再docker logs uptime-kuma看日志。最常见原因是宿主机的 3001 端口被其他程序占用改映射端口即可。判断端口占用可以执行netstat -ano | findstr :30016.2 访问与监控类问题问题一监控状态总是 Down但网站明明能开。很多站点套了 CDN 或 WAF会拦截 Uptime Kuma 的探活请求。解决办法是把心跳间隔调大一点或者重试次数调到 1~2降低误报几率。也可以把监控目标改成更稳定的健康检查路径比如首页换成/robots.txt或专门的/health接口。问题二告警从来没收到。按这个顺序排查监控项是否勾选了“启用通知”通知渠道是否保存成功是否点过“发送测试通知”并收到webhook 地址是否拼写错误Server酱的 key 是否失效。九成告警问题出在前两步。问题三通知消息时间差 8 小时。容器默认 UTC 时区在 compose 里加TZAsia/Shanghai后重启容器即可。6.3 外部访问类问题问题一端口映射配了外网还是不通。逐项检查运营商家宽是否大内网看 WAN IP路由器映射规则里内网 IP 是否写错Windows 防火墙是否放行对应端口外网测试是否用了手机 4G/5G 而不是同一 WiFi。特别是最后一条在同一 WiFi 下测试公网访问会因 NAT 回环问题出现假失败。问题二Cloudflare Tunnel 访问显示 502/522。502 多半是本地 Uptime Kuma 没起来或 config.yml 的 service 地址写错522 通常是隧道连接断了检查 cloudflared 进程是否还活着。命令行窗口直接跑的话日志会告诉你答案。问题三诊断本地防火墙放行了没。可以在另一台局域网机器上用手机浏览器访问http://内网IP:3001能打开说明端口没被防火墙拦问题出在公网侧打不开说明先解决防火墙或绑定问题。6.4 常见问题速查表症状可能原因处理建议localhost:3001 打不开容器未启动或端口占用docker ps检查换端口映射外网 IP:端口 不通大内网 / 防火墙 / 映射错误按 6.3 逐层排除监控总是误报 DownWAF 拦截或超时太短调大超时和重试次数添加通知没收到测试消息配置错误或未点测试重新核对 token / 授权码通知时间差 8 小时时区未设置compose 加 TZ 后重启容器重启后配置全丢数据卷未挂载检查-v参数是否正确隧道访问 502本地服务没起来检查容器状态和 config 指向写在最后我这一年多跑下来的真实体会Uptime Kuma 在我这边已经稳定跑了一年多监控对象从个人博客、API 服务到家里的 NAS 和旁路由加起来二十多个。最让我省心的不是那个绿油油的看板而是它“平时不说话、出事一嗓子”的告警体系——服务挂了五分钟内消息就到手机SSL 证书还剩两周就提前提醒这两件事直接帮我躲过了好几次原本要半夜爬起来处理的故障。外部访问的方案上我自己的宽带没有公网 IP所以最终选了 Cloudflare Tunnel 长期运行配合自己的域名做 HTTPS 访问。跑下来稳定性完全可以接受唯一要提防的是 tunnel 进程意外退出所以我用计划任务做了一层看护每五分钟检查一次进程没了就自动拉起。最后再分享一个小技巧Uptime Kuma 的迁移比你想象中简单。换机器时把数据目录整个拷走在新机器上跑同一条 docker 命令挂载同一个目录打开页面就是原来的配置和监控历史。所以备份别偷懒一个几百 MB 的目录就是整套监控系统的全部身家。