用 Cloady 搭建 Beszel：把云服务器和家里的 R4S 放进同一个监控面板

2026年11月8日网络教程

我最初关注 Cloady，只是想弄清楚：这个平台提供的云端资源，除了部署网站，还能用来做什么？

后来，我给它找到了一个很实用的位置——运行 Beszel 监控中心，把云服务器和家里的 NanoPi R4S 集中起来看。

云服务器上有 WordPress，家里的 R4S 则同时承担旁路由、音乐服务、云盘等工作。过去要看设备状态，通常需要分别登录不同的后台。现在，一个页面就能查看主机负载、内存、磁盘、网络，以及各个 Docker 容器的资源占用。

这篇文章按实际沟通过程，把 Cloady 的用途、Beszel 的结构、云端部署、VPS 接入、R4S 检查与安装，以及自定义域名、刷新频率和回滚方法串起来。

实施时间为 2026 年 11 月 7 日，整理于 11 月 8 日。R4S 部分依据实际检查和安装记录；云端部分结合此前已确认的运行结果与官方文档整理为复现流程。域名绑定、通知等可选内容单独说明，不代表本次全部执行过。文中的域名、地址和凭据均为示例；平台套餐和界面以使用时为准。

一、先认识 Cloady：它适合拿来做什么？

Cloady 是一个云应用托管平台。对使用者来说，主要工作是选应用、配置资源、设置数据卷和环境变量，然后部署。平台负责底层运行环境，并提供应用入口、HTTPS、日志等管理能力。

它支持从 GitHub 仓库、Docker 镜像、上传的项目目录或应用模板部署。因此，除了网站，也可以运行数据库、工具类应用和监控中心。Cloady 官方介绍

我这次选择的用途就是：让 Cloady 运行 Beszel Hub，作为统一的监控入口。

它与普通 VPS 的使用体验有什么区别？

使用普通 VPS 时，往往需要自己安装运行环境、配置服务管理和反向代理。使用 Cloady 这类平台，更多操作围绕“应用”进行：选镜像、设置端口、绑定数据卷、查看日志、配置域名。

这种方式适合希望尽快运行一个独立应用的人。相应地，应用部署、存储和网络也需要遵循平台规则，不能直接套用一台完整 Linux 主机的管理方式。

免费额度要怎样理解？

截至本文整理时，官方入门文档列出了部分地区可用的免费额度，包括 0.5 vCPU、1 GB 内存和 5 GB SSD；免费额度与试用资格有地区等条件限制。部署前应检查控制台给出的资源和费用预览。Cloady 入门文档

我没有把它理解成一台可以无限增加服务的免费服务器。Beszel Hub、数据库和其他应用都会消耗工作区资源，监控历史也会持续增长。适合轻量应用，并不意味着可以忽略容量和备份。

二、Beszel 怎样把不同地方的机器连接起来？

Beszel 的部署可以分成两部分：

组件	放在哪里	负责什么
Hub	本次放在 Cloady	提供网页、保存历史、展示各台设备的数据
Agent	每台被监控设备	采集当前设备的指标并与 Hub 通信

这次的结构是：

txt

浏览器 ── HTTPS ──→ Cloady 上的 Beszel Hub
                           ↑
                  HTTPS / WebSocket
                    ↑             ↑
             云服务器 Agent    家庭 R4S Agent
                                  │
                          主机指标 + Docker 指标

这里有两个容易混淆的地方。

第一，云服务器上运行 WordPress，不代表要把 Beszel 安装成 WordPress 插件。Agent 运行在服务器上，采集的是服务器状态。

第二，R4S 上已经有 Docker，新增 Agent 只需增加一个容器，不需要再安装一套 Docker，也不需要重新部署现有音乐、云盘服务。

家里没有公网 IP，能接入吗？

可以。本次采用 Agent 主动发起的 WebSocket 连接：R4S 通过 HTTPS 访问云端 Hub，再建立长连接。

因此，家庭网络无需为 Agent 配置公网 IP、DDNS 或端口映射。前提是设备能正常解析并访问 Hub，平台入口也允许 WebSocket 握手。Beszel 官方将 Agent 的连接端点列为 /api/beszel/agent-connect。Beszel 通信与安全说明

网页能打开，只能说明基础 HTTP 访问正常；最终仍要通过 Agent 日志和 Hub 在线状态确认认证连接成功。

三、在 Cloady 部署监控中心

下面是可以照着核对的部署顺序，平台按钮名称可能随版本调整。

1. 登录并进入工作区

进入 Cloady，登录后选择工作区和部署地区。

先看清资源预览与费用，再创建应用。不要因为模板上出现“Free”，就默认任何资源配置都免费。

2. 选择 Beszel 模板或官方镜像

可以先在应用模板中搜索 Beszel。若采用自定义镜像方式，Hub 的官方镜像名称是：

txt

henrygd/beszel

Hub 的默认服务端口是 8090，持久化数据路径是：

txt

/beszel_data

这两个值分别对应应用入口和数据保存位置。它们来自 Beszel 官方 Hub 部署配置；在 Cloady 上，应通过平台的服务、端口和存储配置来表达，而不是直接照抄本地 Docker 的端口发布操作。Beszel Hub 安装文档

3. 确认持久化存储

部署前检查 /beszel_data 是否绑定了平台持久化卷。

监控用户、系统配置和历史记录需要跨容器重建保留。仅仅看到网页可以打开，不能证明数据已得到持久化保护。

持久化也不等于备份：误删应用、误删数据或应用数据损坏，仍可能需要单独的备份恢复措施。

4. 打开平台提供的 HTTPS 地址

应用启动后，Cloady 会提供一个 cloady.io 地址。本文用下面的示例表示：

txt

https://beszel-example-workspace.cloady.io

首次进入 Beszel，按页面提示创建账户。随后可以在环境配置中核对公开访问地址：

txt

APP_URL=https://beszel-example-workspace.cloady.io

APP_URL 是 Hub 的公开地址配置；Agent 用来连接 Hub 的则是 HUB_URL。两者用途不同，后面绑定自定义域名时还会遇到。

四、先接入云服务器，验证整条链路

在接入 R4S 之前，此前的沟通已经确认：WordPress 所在 VPS 的 Agent 成功通过 WebSocket 连接到了同一个 Hub。

这个顺序很有帮助。先用一台云服务器验证 Hub、证书和认证配置，再接入家庭设备，排错时能减少同时变化的因素。

接入时需要哪些信息？

在 Hub 点击“添加系统”，为这台服务器建立独立记录。部署 Agent 时主要需要：

配置	用途
`HUB_URL`	Hub 的 HTTPS 地址
`KEY` 或 `KEY_FILE`	Hub 公钥，用于验证对端
`TOKEN` 或 `TOKEN_FILE`	Agent 注册认证信息

每台设备使用自己的连接信息，后续更容易定位故障、迁移和撤销访问。

云服务器用 Docker 还是原生安装？

应按服务器现状选择。已有成熟 Docker 环境，可以使用容器；没有 Docker，也可以使用官方二进制安装方式，无需为一个 Agent 专门增加整套容器环境。

普通 Linux 服务器可以从 Hub 的“二进制”页签获取安装指引，安装前核对是否包含 WebSocket 所需的 HUB_URL 和令牌。官方安装脚本支持指定版本，并配置服务管理；自动更新是否启用也应明确决定。Agent 官方安装文档

此前 VPS 的逐条安装命令没有完整保存在本项目中，因此这里不把某套命令写成当时已经执行过的记录。已确认的结果是 VPS 在线并使用 WebSocket；R4S 的具体落地步骤则见下文。

五、接入 R4S 之前，先检查真实环境

我的 R4S 同时运行旁路由、代理、音乐和云盘服务。安装监控工具的前提，是不干扰这些现有工作。

所以，部署分成了两个阶段：先只读检查和制定方案，确认后才安装。

实际检查结果

项目	本次检查结果
设备	NanoPi R4S
系统	ImmortalWrt 24.10.6
内核	Linux 6.6.133
架构与 CPU	ARM64，6 核
内存	约 3.77 GiB，检查时可用约 2.82 GiB
CPU 与负载	短时 CPU 约 2%，负载较低
Docker	27.3.1，overlay2，cgroup v2
Docker Compose	v2.39.1，已经安装
现有容器	Navidrome、OpenList、ange-clashboard
Hub 网络	IPv4 HTTPS 正常、证书校验通过；当时 IPv6 出站失败

Navidrome 和 OpenList 的基础 HTTP 检查通过，Nikki、Tailscale、DNS 服务均在运行。已有三个业务容器的状态、启动时间和重启次数也被记录下来，用于安装后对照。

这里没有把“容器在运行”直接等同于所有业务都通过验收。例如，本次没有使用用户账户完成真实音乐播放测试。

检查纠正了一个重要误解

早期讨论一直把 /mnt/wrt-disk 叫作“外接盘”。实测发现，它实际上是 SD 卡上的一个分区：

用途	挂载路径	实际设备	容量	检查时剩余
系统可写区	`/overlay`	`/dev/loop0`，后端为 SD 卡 p2 分区	约 4.9 GiB	约 4.1 GiB
Docker 数据区	`/opt/docker`	`/dev/mmcblk1p3`	约 9.7 GiB	约 8.7 GiB
业务数据区	`/mnt/wrt-disk`	`/dev/mmcblk1p4`	约 13.9 GiB	约 11.1 GiB

这三个区域属于同一张 SD 卡。分别显示分区容量，方便排查哪里快满了；但它们不具备三块物理硬盘的故障隔离能力。

另外，云盘挂载显示的巨大容量也不能当成本地磁盘空间。网络挂载通常没有对应的本地块设备 I/O 指标。Beszel 额外磁盘说明

六、为什么 R4S 最终选择 Docker Agent？

两种方式都做过评估：

比较项	Docker Agent	原生 Agent
本机部署条件	现有 Docker 和 Compose 可直接使用	需安装二进制并配置服务管理
日常维护	与已有容器方式一致	需要适配 OpenWrt 的 procd
容器监控	通过 Docker API 采集	同样需要 Docker API 权限
Docker 故障时	Agent 也会受影响	可以继续独立运行
撤回方式	只撤回新增容器	需处理新增服务及相关文件

本次资源余量充足，已有容器运行正常，监控目标也包括这些容器，所以选择了 Docker。

如果目标是“即使 Docker 停止，也要继续看到主机指标”，原生 Agent 会更合适。不能因为某篇教程使用 Docker，就默认每台设备都该如此。

七、为 R4S 创建独立监控项

在 Hub 点击“添加系统”，填写：

txt

名称：R4S-ImmortalWrt
主机/IP：填写 R4S 的实际内网地址
端口：界面默认值 45876

然后复制该系统对应的 Agent 配置，并保存监控项。

复制配置与保存系统是两个动作。 使用独立系统令牌时，如果只是复制了文本，却没有保存对应系统记录，不能据此认为 Hub 已经准备好接收连接。

这次安装没有继续使用先前截图和聊天中出现过的令牌，而是为 R4S 新建了独立监控项。原有 VPS 的连接信息没有被修改。

界面里的 45876 也不代表家庭路由器必须开放这个端口。本次最终配置关闭 Agent 自身的 SSH 监听，只通过 WebSocket 主动连接。

八、准备 R4S 安装目录和凭据文件

以下操作在 R4S 的 SSH 终端执行，不是在 Windows PowerShell 里执行。示例基于本次分区布局；其他设备必须先修改对应路径和设备名。

1. 再确认挂载和可用空间

txt

df -h /overlay /opt/docker /mnt/wrt-disk
awk '$2=="/mnt/wrt-disk" || $2=="/opt/docker" {print $1,$2,$3}' /proc/mounts
docker ps
docker compose version

先确认挂载的是预期分区，再创建目录。不要在数据盘缺失时，把同名普通目录误当成已挂载的数据区。

2. 创建专用目录

若设备上已经存在同名 Agent 或部署目录，应先检查内容和备份，避免直接覆盖。首次安装可执行：

txt

umask 077
mkdir -p /mnt/wrt-disk/Configs/BeszelAgent/data
mkdir -p /mnt/wrt-disk/Configs/BeszelAgent/secrets
chmod 700 /mnt/wrt-disk/Configs/BeszelAgent
chmod 700 /mnt/wrt-disk/Configs/BeszelAgent/secrets

mkdir -p /overlay/.beszel
mkdir -p /opt/docker/.beszel
mkdir -p /mnt/wrt-disk/.beszel

三个 .beszel 是监控专用空目录，目的是把所在文件系统挂进 Agent，不需要把音乐库或整个业务目录提供给它。

3. 单独保存令牌和 Hub 公钥

txt

cd /mnt/wrt-disk/Configs/BeszelAgent
vi secrets/token
vi secrets/hub-key
chmod 600 secrets/token secrets/hub-key

token 文件只保存新系统的令牌；hub-key 文件保存完整的 Hub 公钥。不要把 YAML 字段名、引号或占位文字一并粘贴进去，也不要在执行后把文件内容贴到公开日志。

本次使用文件形式传入连接信息，Compose 文件本身不包含令牌正文。

九、R4S 使用的完整 Compose 配置

在部署目录创建 compose.yaml，填入下面的内容。将 HUB_URL 替换成自己的 Hub 地址。

这是本次 0.21.1 安装配置的脱敏版本，镜像摘要对应 Linux ARM64。后续更换版本时，应重新核对 Hub 兼容性和镜像架构。

txt

name: beszel-r4s

services:
  beszel-agent:
    image: henrygd/beszel-agent:0.21.1@sha256:af5802a459e60fb08cd3a0be77a7c1ee4ac3f7a06c2115f6da4c8f806229dd1a
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host

    environment:
      HUB_URL: https://monitor.example.com
      KEY_FILE: /run/beszel/hub-key
      TOKEN_FILE: /run/beszel/token
      DISABLE_SSH: 'true'
      DOCKER_IMAGE_CHECK: 'false'
      PACKAGE_UPDATES_INTERVAL: '0'
      SKIP_SYSTEMD: 'true'
      SKIP_GPU: 'true'
      SKIP_WIFI: 'true'
      NICS: eth1
      FILESYSTEM: /extra-filesystems/loop0__System

    volumes:
      - type: bind
        source: /mnt/wrt-disk/Configs/BeszelAgent/data
        target: /var/lib/beszel-agent
        bind:
          create_host_path: false

      - type: bind
        source: /mnt/wrt-disk/Configs/BeszelAgent/secrets
        target: /run/beszel
        read_only: true
        bind:
          create_host_path: false

      - type: bind
        source: /var/run/docker.sock
        target: /var/run/docker.sock
        read_only: true
        bind:
          create_host_path: false

      - type: bind
        source: /overlay/.beszel
        target: /extra-filesystems/loop0__System
        read_only: true
        bind:
          create_host_path: false

      - type: bind
        source: /opt/docker/.beszel
        target: /extra-filesystems/mmcblk1p3__Docker
        read_only: true
        bind:
          create_host_path: false

      - type: bind
        source: /mnt/wrt-disk/.beszel
        target: /extra-filesystems/mmcblk1p4__Data
        read_only: true
        bind:
          create_host_path: false

    logging:
      driver: json-file
      options:
        max-size: 2m
        max-file: '3'

几个配置为什么这样设置？

network_mode: host 用于读取宿主机网络接口统计。本机选择 eth1，避免把桥、物理口和多个虚拟接口简单累加。其他设备不能直接照搬这个网卡名。官方 Agent 安装说明

FILESYSTEM 指定系统可写区，另外两个分区分别显示为 Docker 和 Data。目录名中的设备名需要与实际块设备对应，才能正确关联 I/O。

create_host_path: false 可以避免 Docker 在源目录缺失时自动创建同名目录，但它不能代替完整的挂载检查。本次还核对了 fstab 先于 dockerd 启动，没有为验证而重启整台路由器。

SKIP_SYSTEMD 等设置关闭了本次不需要的采集项。ImmortalWrt 使用 procd，安装了 Agent 不代表就自动获得 Nikki、dnsmasq 等服务的专用状态监控。

DOCKER_IMAGE_CHECK: false 关闭镜像更新查询；日志设置为每份约 2 MiB、保留 3 份，减少 SD 卡上的无界日志增长。这些配置变量的具体支持范围应按所用版本核对。Beszel 环境变量文档

Docker Socket 的“只读”要正确理解

read_only: true 限制的是文件系统挂载方式，不能把 Docker API 强制变成只读接口。能访问 Docker Socket，通常就具有较高的主机管理能力。

本次使用可信的官方镜像，不加 privileged，不开放 Docker TCP API。需要进一步限制 API 时，可以评估受限 Socket Proxy，但它也会增加一个需要维护的组件。

十、启动 Agent，并验证是否真正成功

1. 检查配置并启动

txt

cd /mnt/wrt-disk/Configs/BeszelAgent

docker compose config --quiet
docker compose pull beszel-agent
docker compose up -d --no-deps beszel-agent

这些操作只针对这个独立 Compose 项目中的 Agent，不需要重启 Docker，也不需要重建其他业务容器。

2. 查看状态与连接日志

txt

docker compose ps
docker logs --tail 50 beszel-agent
docker exec beszel-agent /agent health
docker stats --no-stream beszel-agent

本次日志出现了：

txt

Detected disk name=System ... root=true
Detected disk name=Docker ...
Detected disk name=Data ...
Detected network interface name=eth1 ...
WebSocket connected host=你的Hub域名

健康检查返回 ok。随后登录 Hub，确认 R4S 显示在线，主机图表和容器列表也有数据。

docker ps 的“运行中”、健康检查的 ok、日志的连接成功和 Hub 的在线数据，是不同层次的证据；只看到其中一个，不足以代替完整核对。

3. 核对磁盘和内存有没有显示错

本次 Hub 识别出约 3.77 GB 主机内存，System、Docker、Data 三个分区与实际挂载关系一致。

容器列表中同时出现：

txt

navidrome
openlist
ange-clashboard
beszel-agent

这一步用于确认：监控既覆盖宿主机，也读到了现有容器，而不是只显示 Agent 自己的数据。

4. 检查原有业务有没有受到影响

安装后再次核对原有三个容器的启动时间、镜像标识和重启次数，与安装前记录一致。

Navidrome 基础接口、OpenList 首页仍正常，Nikki、Tailscale 和 DNS 仍在运行。没有重启 Docker、修改旁路由网络或改动现有容器。

此外，仅重启一次 Agent，验证它能重新连接 Hub，没有通过重启整机来做测试。

十一、安装后的实际资源开销

本次实机观察结果如下：

项目	本次结果
Hub 与 Agent 版本	0.21.1
Agent 内存	初期约 10–13 MiB，后续采样约 15 MiB
Agent CPU	多次短时快照接近 0%
Agent 镜像展开大小	约 10 MB
安装收尾时 data 目录	约 8 KiB
重连测试	单独重启 Agent 后约 1 秒重新连接
观察期间自动重启	未发现

这些数值只代表本机当时的短时检查。整个收尾观察约 6 分钟，没有完成长期峰值测试，也不能把约 15 MiB 解释为永远不变的内存上限。

但对于当时还有约 2.8 GiB 可用内存的 R4S 来说，这次部署的增量开销比较小。

十二、面板为什么不是每个数字都每秒变化？

这是安装后很容易出现的疑问：页面能看到数据，为什么有时候看起来没有变化？

Beszel 的汇总列表、实时详情和历史图表采用不同的数据展示方式。要观察短时间波动，可以进入某台主机的详情页，把时间范围切换为“1 分钟”。

在本次 0.21.1 版本中，1m 视图面向秒级更新，历史视图则使用按分钟或更长周期聚合的数据。因此，切换到一小时、一天后，图表不会保留同样的秒级细节。Beszel 0.21.1 图表时间配置

磁盘容量、软件更新等指标也不需要与 CPU 使用率采用相同刷新节奏。

如果页面长时间完全不变，刷新后却突然更新，再检查 Agent 连接、Hub 页面订阅和平台代理链路。不要仅凭几秒钟数字没变，就认定 Agent 没有工作。

十三、可选：绑定自己的域名

前面的沟通还讨论了自定义域名。这部分是可复用的后续配置方法，不作为 R4S 本次安装已执行的步骤。

假设准备使用：

txt

monitor.example.com

1. 先在 Cloady 添加域名

进入 Beszel 应用的 Settings → Domains，添加子域名，并查看平台给出的 DNS 配置。若要由 Beszel 正常提供服务，不要选择重定向到其他主机。

Cloady 支持平台域名与自定义域名并存，配置正确后会为域名处理 HTTPS。Cloady 域名配置说明

2. 在 Cloudflare 添加 CNAME

如果域名已经由 Cloudflare 托管 DNS，进入该域名的 DNS Records，添加类似记录：

字段	示例
类型	CNAME
名称	`monitor`
目标	Cloady 页面给出的应用主机名
代理状态	初次验证建议 DNS only，即灰云
TTL	Auto

目标只填主机名，不带 https:// 和路径。保存前检查是否已有同名记录，避免覆盖原有业务。Cloudflare DNS 记录管理

为一个子域名添加记录，不需要把整个域名的 Nameservers 改到 Cloady。页面上的 Nameservers 配置与本次子域名 CNAME 方案应区分使用。

3. 等待 DNS 和证书就绪

返回 Cloady 查看域名验证及 TLS 状态，再用浏览器访问新域名，确认页面和登录正常。

确认后，把 Hub 的公开地址改为：

txt

APP_URL=https://monitor.example.com

按平台提示应用配置变更。旧的平台域名仍可用时，已有 Agent 可以先继续使用旧 HUB_URL，不必同时修改所有设备。等新入口稳定，再逐台迁移。

十四、可选：配置告警通知

数据能看见以后，再配置离线、CPU、内存或磁盘告警，会更容易判断阈值是否合理。

如果采用邮件通知，需要区分两个概念：通知里填写的收件邮箱，与真正负责发信的 SMTP 配置。填了收件邮箱，不等于已经配好发信能力。

本次 R4S 安装没有执行 SMTP 配置或告警发送测试，因此不把通知发送写成已验收功能。实际启用时，应按当前版本支持的通知方式配置，并测试一次完整发送链路。

十五、遇到问题，按这个顺序排查

现象	优先检查
容器无法创建	Compose 语法、镜像架构、源目录、挂载和文件权限
容器运行但 Hub 离线	`HUB_URL`、证书、DNS、系统是否保存、令牌与公钥是否对应
日志不断认证失败	是否用了旧令牌，是否混用了其他设备的配置
网页能打开但 Agent 连不上	继续检查 WebSocket 认证和平台入口，HTTP 200 不能代替握手成功
内存容量明显不对	是否误用了容器自身统计口径
磁盘容量不对	是否采集到容器存储层，分区挂载和设备名是否正确
有容量但没有 I/O	目录命名与块设备是否匹配，目标是否为网络挂载
网络数值看起来翻倍	是否重复累加桥、物理接口和虚拟接口
重启后异常	数据分区是否先挂载，源路径是否存在，Docker 自启动是否正常

OpenWrt 的 BusyBox 命令也不能完全按完整 Linux 发行版来理解。本次发现 df -i、ps -o 等形式不可用；处理方式是改用已有接口检查，没有为了安装监控额外堆一批工具。

十六、以后怎样暂停、恢复和回滚？

进入 R4S 的部署目录：

txt

cd /mnt/wrt-disk/Configs/BeszelAgent

查看状态：

txt

docker compose ps

暂停监控：

txt

docker compose stop beszel-agent

恢复监控：

txt

docker compose up -d --no-deps beszel-agent

撤回新增的 Agent 容器：

txt

docker compose down

这里的前提是当前目录确实是只包含 Agent 的独立 Compose 项目。撤回时保留配置、凭据和数据，方便恢复；不要运行全局清理，也不要误删音乐库、云盘配置或其他容器的数据。

unless-stopped 允许容器随 Docker 恢复运行，但手动停止后的容器会保持停止意图。暂停后需要再次明确启动。

后续升级也只处理 Agent：保留当前镜像摘要和配置，核对新版本，再重建这个容器。若升级失败，可以退回旧版本，不必重启整套 Docker。

十七、这次部署真正解决了什么？

云端 Hub 把分散在不同位置的设备放进了同一个页面：云服务器可以看，家里没有公网 IP 的 R4S 也可以看。

更有价值的是，部署前的检查帮助我重新确认了设备本身：Docker 和 Compose 已经可用，现有服务无需重建，三个“磁盘”实际上属于同一张 SD 卡，监控网络也需要选对接口。

最终，我新增了一个约 15 MiB 内存开销的监控容器，就获得了主机与现有容器的集中可视化。音乐、云盘和旁路由工作保持原样；以后出现资源压力，也有了一个方便回看和定位的入口。

这套做法同样可以扩展到其他设备：云端保留一个 Hub，每台设备选择适合自己的 Agent 安装方式，逐台检查、逐台接入。

本文环境： Cloady + Beszel 0.21.1 + NanoPi R4S + ImmortalWrt 24.10.6 + Docker 27.3.1。

建议标签： Cloady、Beszel、R4S、ImmortalWrt、Docker、服务器监控、旁路由。

一、先认识 Cloady：它适合拿来做什么？ ​

它与普通 VPS 的使用体验有什么区别？ ​

免费额度要怎样理解？ ​

二、Beszel 怎样把不同地方的机器连接起来？ ​

家里没有公网 IP，能接入吗？ ​

三、在 Cloady 部署监控中心 ​

1. 登录并进入工作区 ​

2. 选择 Beszel 模板或官方镜像 ​

3. 确认持久化存储 ​

4. 打开平台提供的 HTTPS 地址 ​

四、先接入云服务器，验证整条链路 ​

接入时需要哪些信息？ ​

云服务器用 Docker 还是原生安装？ ​

五、接入 R4S 之前，先检查真实环境 ​

实际检查结果 ​

检查纠正了一个重要误解 ​

六、为什么 R4S 最终选择 Docker Agent？ ​

七、为 R4S 创建独立监控项 ​

八、准备 R4S 安装目录和凭据文件 ​

1. 再确认挂载和可用空间 ​

2. 创建专用目录 ​

3. 单独保存令牌和 Hub 公钥 ​

九、R4S 使用的完整 Compose 配置 ​

几个配置为什么这样设置？ ​

Docker Socket 的“只读”要正确理解 ​

十、启动 Agent，并验证是否真正成功 ​

1. 检查配置并启动 ​

2. 查看状态与连接日志 ​

3. 核对磁盘和内存有没有显示错 ​

4. 检查原有业务有没有受到影响 ​

十一、安装后的实际资源开销 ​

十二、面板为什么不是每个数字都每秒变化？ ​

十三、可选：绑定自己的域名 ​

1. 先在 Cloady 添加域名 ​

2. 在 Cloudflare 添加 CNAME ​

3. 等待 DNS 和证书就绪 ​

十四、可选：配置告警通知 ​

十五、遇到问题，按这个顺序排查 ​

十六、以后怎样暂停、恢复和回滚？ ​

十七、这次部署真正解决了什么？ ​