VPS 家庭实验室仪表盘搭建指南：用 Labby 实时监控 Docker 容器状态

家里有一台 NAS 或者几台服务器的人，慢慢都会遇到一个麻烦：跑了好几个 Docker 容器，哪个在正常工作、哪个内存快爆了、哪个静悄悄挂了你完全不知道。每次都要 SSH 进去敲 docker ps 和 docker stats，看两眼再退出来，次数多了真挺烦的。而且如果服务部署在远程 VPS 上，你还得先连 VPN 或者跳板机才能查，半夜被报警吵醒更是折磨。

Labby 就是专门解决这个问题的工具。它本质上是一个轻量级的 Docker 容器状态仪表盘，通过 SSE（Server-Sent Events）实时推送数据，不用轮询，CPU 和内存占用极低。配置好之后，打开浏览器就能看到所有容器的 CPU、内存、状态、运行时长，而且可以部署在公网 VPS 上远程访问，不用每次都敲命令。

这篇文章会从零带你走完完整的部署流程，包括环境准备、Docker Compose 编排、Nginx 反向代理配置、HTTPS 证书、访问鉴权，以及在常见故障下怎么排查。读完你就能自己搭一个家庭实验室监控页，出门在外也能随时看到容器状态。

环境准备：一台装了 Docker 的 VPS 就够了

Labby 本身也是容器化的，所以 VPS 只需要满足两个条件：

• 安装了 Docker Engine（20.10+）和 Docker Compose（v2 或 v1）
• 能够通过 HTTP/HTTPS 对外暴露一个端口

配置方面要求极低。我自己在 HostEons 的 1 核 1G VPS 上跑过，同时跑 Labby 外加三个容器（Nginx、MariaDB、一个 Python Bot），Labby 本身只占 50~80MB 内存，CPU 在空闲时基本为 0，更新时也只在 1%~5% 浮动。哪怕是最便宜的年付 $20 左右的入门套餐也完全带得动。

VPS 硬件要求与实际性能测试

下面这个表格整理了我用不同规格 VPS 跑 Labby 时的实际资源占用数据（测试场景：同时监控 15 个容器）。不过实际占用会受你运行的其他容器数量、Labby 的 SSE 推送频率影响，下表只能作为参考。

从数据来看，1 核 1G 是性价比最高的选择，既能跑 Labby 还能跑两三个业务容器。如果你只是监控三五台机器，512MB 内存也能搞定。但如果你计划同时监控 20 个以上的容器，建议用 2 核 2G 的机器，避免因内存竞争导致 SSH 响应变慢。

Docker 版本兼容性注意事项

Labby 依赖 Docker SDK，我测试过 Docker 20.10 和 24.0 两个大版本，都能正常运行。但如果你用的是极老的版本（比如 19.03 以下），建议先升级，否则 socket 通信可能出问题。Docker Compose 方面，v2 和 v1 都兼容，但 v2 的 docker compose（没有连字符）命令更推荐，因为 v1 的 docker-compose 已经进入维护期。

基础安装

# 更新系统并安装 Docker（Debian/Ubuntu 示例）
sudo apt update && sudo apt upgrade -y
sudo apt install docker.io docker-compose-v2 -y
sudo systemctl enable --now docker

确认 Docker 正常运行：

docker --version
docker compose version

使用 Docker Compose 部署 Labby

Labby 官方提供了 docker-compose.yml，结构非常简洁。

version: '3'
services:
  labby:
    image: ghcr.io/mazzzystar/labby:latest
    container_name: labby_dashboard
    ports:
      - "3000:3000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped

用以下命令部署：

mkdir labby && cd labby
nano docker-compose.yml   # 粘贴上面的内容
sudo docker compose up -d

启动后访问 http://你的VPS_IP:3000，就能看到仪表盘了。第一次打开可能会直接显示一个空列表，如果当前 VPS 上已有运行中的容器，它们会立刻出现在卡片列表里。

观察仪表盘界面

Labby 的 UI 非常直观，分为几块：

• 顶部统计栏：总容器数、运行中数量、已停止数量。
• 容器卡片：每个容器一张卡片，显示名称、镜像标签、状态（绿色/红色圆点）、CPU 百分比、内存占用（含数值和百分比）、端口映射、创建时间。
• 实时更新：数据通过 SSE 长连接自动推送，不需要手动刷新页面。关闭浏览器连接后，VPS 端不会残留任何进程。

如果你跑了一大堆容器，这个页面比 docker stats 清晰一百倍——你可以在一个页面里扫完所有容器的健康状态，而且手机上用浏览器打开也很友好。

反向代理配置：Nginx + 域名访问

直接暴露 IP 加端口不安全，而且不便于记忆。推荐用 Nginx 做反代，绑定一个子域名，再配上免费 SSL 证书。

安装 Nginx

sudo apt install nginx -y

配置虚拟主机

server {
    listen 80;
    server_name labby.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 86400s;
    }
}

proxyreadtimeout 设得长一点是关键，因为 Labby 用的是 SSE 长连接，默认 60 秒的超时会导致连接频繁断开，仪表盘就会一直显示“断开重连”。86400 秒（24 小时）基本上可以覆盖日常使用。

然后启用站点并申请 SSL：

sudo ln -s /etc/nginx/sites-available/labby /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d labby.yourdomain.com

现在你就可以通过 https://labby.yourdomain.com 安全地访问仪表盘了。

访问安全和鉴权：别让仪表盘裸奔在公网

暴露到公网的仪表盘一定要加一层保护，否则谁扫到你的域名就能看到你所有容器的名字、资源占用，甚至端口映射——这些信息对于攻击者来说很有价值。

方案一：Nginx Basic Auth（最简单）

sudo apt install apache2-utils -y
sudo htpasswd -c /etc/nginx/labby.htpasswd admin  # 创建用户 admin，输入密码

在 server block 的 location / 里添加：

location / {
    auth_basic "Labby Dashboard";
    auth_basic_user_file /etc/nginx/labby.htpasswd;
    # … 其余的 proxy_pass 配置保持不变
}

重载 Nginx 后，再次访问就会弹出浏览器登录框。

方案二：Cloudflare Access（零信任，推荐）

如果你已经用 Cloudflare 管理域名，可以打开 Cloudflare Zero Trust 面板，创建一个自托管应用：

1. 进入 Zero Trust → Access → Applications → Add an application。
2. 选择 Self-hosted，填入你的域名 labby.yourdomain.com。
3. 设置访问策略：比如“任何人使用邮箱+一次性验证码登录”。注意，这里的“任何人”指的是你允许通过邮箱验证的人，并不是开放给全网。你还可以在 Policy 中限定特定邮箱域名，比如只允许 @yourcompany.com 或你自己的 Gmail。
4. 保存后，所有未认证的访问都会被 Cloudflare 拦截，直接跳转到登录页。

这种方案的优点是不需要在 VPS 上配置任何额外的软件，而且支持多因素认证。如果你的域名已经托管在 Cloudflare，这个方案最省心。

方案三：Tailscale（纯内网访问）

如果平时只有你自己用 Labby，可以完全不让它暴露在公网。配置方法：

1. 在 VPS 上安装 Tailscale：curl -fsSL https://tailscale.com/install.sh | sh 并登录。登录时会自动打开浏览器授权，或者你也可以在无头机器上用 tailscale up --authkey YOURAUTHKEY 方式。
2. 修改 Labby 的监听地址为 127.0.0.1，即 ports: "127.0.0.1:3000:3000"。
3. 在你的笔记本或手机上同样安装 Tailscale 并登录同一账号。
4. 通过 Tailscale 分配的内网 IP（比如 100.x.x.x）加上端口访问 Labby。

这种方案最省心，也最安全——没有公网入口，连密码都不需要。不过需要注意，Tailscale 在部分低配 VPS 上（256MB 内存）安装后可能会占用 30-50MB 额外内存，但 1GB 内存的机器几乎无感。关于 VPS 安全配置的更多细节，可以参考我们的《VPS 安全配置入门》一文。

常见问题与排错：结合日志的实操

Q1：Labby 启动后页面空白，没有容器数据

检查日志：

sudo docker compose logs labby

常见的错误是 Got permission denied while trying to connect to the Docker daemon socket。原因是当前用户没有 docker 组权限。解决：

sudo usermod -aG docker $USER
# 然后重新登录或执行 newgrp docker
sudo docker compose down && sudo docker compose up -d

另一个可能的原因是 docker socket 路径不对。有些系统用 containerd.sock 而非 docker.sock，检查 /var/run/docker.sock 是否存在，如果不存在，可以用 sudo find / -name docker.sock 找到真实路径。

实际日志可能像这样：

labby_dashboard | 2026/07/11 12:34:56 Failed to dial gRPC: connection error: desc = "transport: error while dialing: dial unix /var/run/docker.sock: connect: permission denied"
labby_dashboard | 2026/07/11 12:34:56 Retrying in 5 seconds...

看到 permission denied 就说明是权限问题。如果是路径错误，错误里会显示 no such file or directory。

Q2：SSE 连接频繁断开

打开浏览器开发者工具（F12），查看网络请求，如果看到 labby 的 SSE 请求每隔 60 秒左右就重新建立一次，说明 Nginx 的 proxyreadtimeout 不够长。按前面配置改为 86400s 即可。

如果 VPS 背后还有一层 CDN（比如 Cloudflare），要确保没有缓冲 SSE 请求。在 Cloudflare 仪表盘中，为 labby.yourdomain.com 添加一条页面规则：

• URL：labby.yourdomain.com/*
• 缓存级别：绕过
• 或者关闭代理（仅 DNS）。

此外，如果 VPS 本身有防火墙（如 ufw），要确保 3000 端口（或你映射的其他端口）在内部放行。

Q3：端口 3000 被其他服务占用

修改 docker-compose.yml 中的端口映射，比如 "3001:3000"，然后重新部署。注意 Nginx 反代的 proxy_pass 也要改成对应的端口。

Q4：Labby 容器正常，但页面看不到某个容器

检查那个容器是否运行在同一个 Docker 守护进程下。Labby 只能读取它挂载的 socket 对应的 Docker 实例，如果你有多台机器，每台都需要单独部署一个 Labby。

与同类工具的详细对比和配置差异

市面上类似工具不少，但侧重点不同。下面从部署复杂度、功能范围和配置步骤上做个对比。

从实际配置步骤来看，Labby 胜在极简。Cockpit 虽然功能更全，但需要开启系统级别的服务，而且默认不带容器视图插件，需要额外安装 cockpit-podman 或 cockpit-docker。安装命令：sudo apt install cockpit cockpit-podman，然后访问 https://VPS_IP:9090。不过 Cockpit 的 Web 界面偏系统管理，对于只看容器的人来说过于重了。

Glances 的 Web 模式需要加 -w 参数，docker run -d --name glances -p 61208:61208 -v /var/run/docker.sock:/var/run/docker.sock:ro docker.io/nicolargo/glances:latest -w。页面风格停留在早期 Bootstrap 时代，手机端适配不好。而 Labby 走到哪都是同一套卡片式 UI，手机端适配也做得不错。

如果你只需要一个纯粹的容器状态看板，Labby 是最省事的选择。如果你需要同时监控系统级的 CPU、磁盘、网络，Cockpit 可能更合适。如果是大规模生产环境，Grafana + Prometheus 仍是不可替代的。

增加实时报警：让 Labby 与外部监控联动

Labby 本身没有内置报警功能，但你可以结合 Uptime Kuma 或 Healthchecks.io 来实现。

用 Uptime Kuma 监控 Labby 是否可达

Uptime Kuma 是一个开源监控工具。你可以创建一个监控项，指向 Labby 的域名，如果 Labby 服务挂了，它会通过 Telegram、邮件等方式通知你。但注意：Uptime Kuma 只能判断 Labby 本身是否在线，无法监控 Labby 里每个容器的状态。

用 Healthchecks.io 监控特定容器

更实用的做法是写一个简单的 shell 脚本，定期检查特定容器是否运行，然后向 Healthchecks.io 发送心跳。如果容器挂掉，Healthchecks.io 会在指定时间后报警。

1. 在 Healthchecks.io 上注册账号，创建一个检查项目，获得一个 UUID。
2. 在 VPS 上编写脚本，比如 /usr/local/bin/check_container.sh：

#!/bin/bash
# 检查 my-nginx 容器是否在运行
if docker ps --format '{{.Names}}' | grep -q "my-nginx"; then
    # 容器运行正常，发送成功信号
    curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/YOUR_UUID
else
    # 容器未运行，发送失败信号
    curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/YOUR_UUID/fail
fi

1. 赋予执行权限：chmod +x /usr/local/bin/check_container.sh。
2. 添加到 crontab，每 5 分钟执行一次：

crontab -e
*/5 * * * * /usr/local/bin/check_container.sh

这样，当 my-nginx 容器意外停止时，Healthchecks.io 会在 5 分钟后检测到没收到心跳，从而发送报警。如果需要监控多个容器，可以在脚本里循环检查。

你还可以扩展这个思路，利用 Docker 的 --health-cmd 来实现容器级别的健康检查，然后配合 Healthchecks.io 的“钟表”机制。但那样就复杂了，目前这个方案已经能覆盖大部分家庭实验室场景。

注意事项

无认证功能：Labby 本身没有认证机制，请确保在反向代理后面运行，或仅在局域网/VPN 内访问 目录权限：config/ 目录必须对容器运行的用户可写，否则会出现 SQLITE_READONLY 错误。如果遇到权限问题，可以在 docker-compose.yml 中添加 user: "<uid>:<gid>" 配置 数据持久化：所有配置和数据都保存在 config/labby.db 文件中，定期备份此文件即可完整备份 Labby 数据 端口冲突：确保本地端口 8425 没有被其他服务占用，如有冲突请修改端口映射 安全建议：不要将 Labby 暴露到公共 互联网，除非有网络级别的访问控制

总结

Labby 是一个用完几乎感觉不到负担的 Docker 仪表盘。部署十分钟，配置反代和鉴权再加十分钟，之后你就能在任何地方打开浏览器检查所有容器的状态。

适合这几类人：

• 家庭实验室里跑了一堆容器，想有个集中视图快速排查。
• 用 VPS 挂 Bot、博客、下载等多项服务，怕某个容器挂了没人知道。
• 刚开始学 Docker，想直观理解各个容器的资源占用变化。