群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家 群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家很多老用户是从 DSM 6.x 一路升级上来的，Docker 套件里跑着三五个容器：下载器、相册、密码库、监控面板，几年都没动过。升级到 DSM 7.2 后，Docker 套件被 Container Manager 接替，名字变了、界面变了，不少人第一反应是：直接升级会不会把容器弄丢？先给结论：DSM 7.2 的 Container Manager 就是 Docker 套件的改名续作，底层还是 Docker，容器和镜像可以平滑带过来。但“可以带过来”不等于“点一下升级就万事大吉”。旧版里一些写法、路径和权限，在新版里会踩坑。本文按真实迁移顺序讲：先盘点、再备份、再动手，迁移完逐项验证，万一翻车还能原路退回。提醒：站内 2022-2023 年写的群晖 Docker / DSM 6.x 旧文（旧版 Docker 套件界面与操作）已过时，请以本文 DSM 7.2 Container Manager 的流程为准，不要再按旧截图一步步点。一、迁移前先盘点：你到底跑着什么别急着点升级，先把家底列清楚。打开旧版 Docker（或已升级后的 Container Manager），逐个记下来：每个容器的名字、镜像名和版本标签（比如 latest 还是带版本号的 1.2.3）端口映射：宿主机端口对容器端口，例如 8080:80数据卷：哪些目录映射到了 /docker/xxx，哪些是匿名卷环境变量：时区 TZ=Asia/Shanghai、PUID/PGID、密码、域名等网络模式：bridge 还是 host，有没有用到 macvlan自动启动：是不是随 NAS 开机自启最容易丢的是两类东西：一是写在容器内部、没映射出来的数据（比如只存在容器里的数据库），二是 latest 标签——你以为还是原来那个版本，重新拉取后其实已经是大版本更新了。盘点表建议直接写成一张表，迁移后逐项打勾。还有一个常被忽略的点：DSM 7.2 要求 Container Manager 的项目文件和旧版 Docker 的存储位置不完全相同，升级向导一般会保留数据，但如果你之前把 Docker 目录改过位置，或者用了非默认的共享文件夹，升级前一定要先确认 /volume1/docker（或你自己的目录）里每个应用的文件夹都在。二、备份：三份东西，缺一不可迁移的底气全来自备份。动手前做好这三份：容器配置导出：在旧版 Docker 里把每个容器的设置导出，或者用 docker-compose.yml 重写一遍。推荐后者——一份 compose 文件就是一份可复现的部署说明书，比在界面里点来点去可靠得多。数据卷备份：把 /docker 下每个应用的配置和数据文件夹完整复制一份到另一个共享文件夹或外接硬盘。像 Vaultwarden 的数据文件、Immich 的上传目录、下载器的配置文件，丢了就得重头来。Hyper Backup 快照：如果 NAS 上开了 Hyper Backup 或快照，迁移前手动做一次快照。这一步是给“整个迁移翻车”准备的后悔药。备份完别只放在原地：验证一下备份文件能不能打开、大小是不是正常。备份没验证过，等于没备份。三、正式迁移：按这五步走第 1 步：停容器，记状态先把所有容器停掉，不要在运行中直接升级。停之前截一张运行状态图，或者把 docker ps 的输出存下来，方便迁移后对照：原来跑着几个、现在跑着几个，一眼就能看出来。第 2 步：升级 DSM 到 7.2，安装 Container Manager在控制面板里把 DSM 升级到 7.2（如果还没升），然后在套件中心安装 Container Manager。安装完成后，旧 Docker 套件会被替换，容器列表应该还在——如果列表空了，先别慌，也别马上重建，先看第 5 步的排查。第 3 步：核对镜像与容器逐个核对：容器名、镜像、端口、卷映射、环境变量是不是和盘点表一致。重点看三处：端口冲突：DSM 7.2 的系统服务占用端口有变化，原来能用的端口可能被系统占了，容器起不来就先查端口。权限变化：DSM 7.2 对共享文件夹权限更严格，容器用户读不到映射目录时，表现常常是“容器起来了但数据是空的”或“写不进文件”，这时要去检查文件夹权限和 PUID/PGID。网络模式：host 模式的容器在新版里行为基本一致；bridge 模式下如果原来用了自定义网桥，要确认网段没有冲突。第 4 步：逐个启动，别一键全开不要图省事把所有容器一次性全启动。一个一个起，起一个、看日志、打开网页确认能访问，再起下一个。日志里出现 permission denied 多半是权限问题；出现 port is already allocated 就是端口冲突；出现 no such file or directory 往往是卷路径写错了。特别提醒：数据库类容器（比如带 MariaDB/Postgres 的应用）启动要慢一些，等它初始化完成再判断，不要看到一时打不开就反复重启。第 5 步：全量验证按盘点表逐项验证：网页能打开、登录账号还在、历史数据都在、定时任务在跑、外部访问（域名或内网穿透）正常。验证通过的打勾，有问题的记下来集中处理，不要带着疑问过夜——迁移当天的问题，当天最容易定位。四、最常见的五个坑坑 1：以为升级会自动转 compose，旧容器变成“孤儿”旧版用界面建的容器，升级后可能没有对应的项目文件，界面里能看到但不好批量管理。办法：趁这次迁移，把重要容器逐个整理成 compose 项目，放到 Container Manager 的“项目”里统一管理，以后备份、迁移都是一份文件的事。坑 2：latest 一拉取，大版本变了迁移时顺手点了“更新镜像”，结果应用从 1.x 升到 2.x，配置格式不兼容。原则：迁移先求稳，镜像版本先保持原样；等迁移验证通过了，再单独安排一次升级，并且升级前再备份一次。坑 3：数据卷路径大小写或斜杠写错Linux 路径区分大小写，/docker/Vaultwarden 和 /docker/vaultwarden 是两个目录。迁移时复制路径要原样粘贴，不要手打。坑 4：时区和时间不对，定时任务全乱套新容器如果忘了设 TZ=Asia/Shanghai，定时签到、备份、清理任务的执行时间会差 8 小时。建容器时把时区写进环境变量，顺手检查一次。坑 5：没留回滚路，翻车只能干瞪眼回滚路其实很简单：旧数据文件夹的备份 + 旧 compose 文件 + 旧镜像版本号。只要这三样在，删掉新容器、按旧配置重建，十分钟就能回到迁移前。迁移当天不要删备份，确认稳定运行一周后再清理。五、迁移后顺手做的三件优化迁移只是开始，DSM 7.2 的 Container Manager 有几个值得顺手用起来的地方：用“项目”管理：把 compose 文件放进项目里，改配置不用再进容器详情页翻，改完一键重新部署。资源限制写清楚：给下载器、相册这类吃内存的应用设个内存上限，避免某个容器失控拖垮整台 NAS。日志轮转别忘开：容器日志默认一直涨，时间长了能吃掉不少空间。在 compose 里加上日志大小限制，或者定期清理。六、结尾：迁移清单，照着打勾[ ] 盘点表已列好：容器、镜像版本、端口、卷、环境变量、网络[ ] 数据卷已备份并验证能打开，Hyper Backup/快照已做[ ] 旧容器已停止，DSM 已升到 7.2，Container Manager 已安装[ ] 容器逐个启动、日志无报错、网页能访问[ ] 登录、历史数据、定时任务、外部访问逐项验证通过[ ] 重要容器已整理成 compose 项目，备份保留一周再清理DSM 7.2 的这次改名，表面是换了个名字，实际是把 Docker 管理收进了更规范的项目制里。迁移本身不难，难的是不做盘点、不做备份就直接动手。按本文的顺序走一遍，大多数人一个晚上就能平滑搬完，第二天早上起来，容器还是原来那几个，只是管理方式更顺手了。相关旧文群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：https://www.yeyhome.com/2026/10/20/285.htmlDockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战：https://www.yeyhome.com/2026/10/17/276.htmlLucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.htmlVaultwarden 自建密码库：Docker 一键部署 + 多端同步实测：https://www.yeyhome.com/2026/10/16/273.html

弱电工程实战：可视对讲 + 门禁 + 网络布线联调 前言：三个系统单独都通，一联调就全乱弱电工程里最磨人的，从来不是单个设备调不通，而是可视对讲、门禁、网络布线三个系统凑到一起之后，互相扯皮：对讲一按就断网，门禁一刷卡对讲就花屏，交换机一重启，门口机和室内机全掉线。我之前做过一个小项目：门口机、室内机、门禁控制器、摄像头、NAS、交换机全齐了，单测每个都正常，联调当天却花了大半天才捋顺。事后复盘，问题不在设备，而在顺序——没有按“先物理、再网络、再单系统、最后跨系统”的顺序走，一上来就全系统联调，出了问题根本不知道是哪一层。这篇就是那次联调的完整复盘：联调顺序、每一步的验收标准、以及一张排障表，照着走能省下至少半天返工。一、联调之前，先把三件事定死联调最怕边调边改方案。动手前，先把下面三件事落在纸上，现场只执行、不讨论。1. 一张拓扑图，而不是脑子里的一张图画清楚：光猫 / 路由 / 核心交换机 / 楼层交换机 / POE 交换机分别在哪，门口机、室内机、门禁控制器、摄像头、NVR、NAS 各接哪个口、拿什么地址。地址规划建议单独给弱电留一个网段，例如 192.168.10.x，门口机、室内机、门禁控制器按设备类型分段，DHCP 只给临时调试用，正式交付前全部改静态地址。地址一乱，联调时抓包都不知道谁是谁。2. 供电方式先定，不要现场现想可视对讲门口机、门禁电锁、摄像头这三类最容易在供电上翻车：POE 供电的摄像头和门口机，要核对交换机 POE 总功率够不够；电锁必须独立电源，绝对不要从门禁控制器板子上直接取电带锁——锁一动作电流一冲，控制器重启，对讲跟着掉线。电锁电源建议单独一路，带 UPS 更好，断电时门该开还是该关，提前和业主确认好（消防通道与安全门的逻辑是反的，不能凭感觉定）。3. 线材与标签一次到位六类线跑千兆、超五类线只跑百兆，这个账要在布线时算清，不要等联调测速时才发现瓶颈。每个信息点、每个弱电箱出线都要贴标签：哪根线去门口、哪根去门禁、哪根去摄像头。没有标签的联调，就是在几十根线里玩抽奖。二、联调顺序：五步走，跳步必返工记住这个顺序：物理层 → 网络层 → 单系统 → 跨系统 → 验收。任何一步没验收通过，不要进下一步。第一步：物理层——线通了再说别的先测线：测线仪打通每根网线，确认线序、通断、POE 供电正常；再测电：电锁电源、门口机电源、交换机电源逐一上电，量电压。门禁的线重点查四组：电源线、信号线（读卡器 / 出门按钮）、电锁线、门磁线。上一篇文章里讲过的门禁接线，这里不再展开，联调时只要确认这四组线没有接反、没有虚接。第二步：网络层——先 ping 通，再谈业务所有设备上电后，先做三件事：ping 网关、ping 核心交换机、ping 同网段的其他弱电设备；再看交换机端口速率是不是千兆、POE 功率有没有超标；最后把 VLAN、端口隔离（如果用了）核对一遍。网络层不通就去调对讲参数，是联调最常见的无效劳动。第三步：单系统自测——各自先跑起来可视对讲单独测：门口机呼叫室内机、室内机开锁、门口机夜视；门禁单独测：刷卡开门、出门按钮开门、门磁报警、断电状态；网络单独测：摄像头上 NVR、NAS 能访问、远程访问走内网穿透是否正常。单系统自测时发现的问题，修起来最便宜，因为干扰项最少。第四步：跨系统联调——按真实使用场景走一遍这一步不要只测“功能”，要测“场景”：访客按门口机 → 室内机振铃 → 业主开锁 → 门禁记录同步；业主刷卡进门 → 摄像头抓拍联动 → NVR 留下记录；断电再来电 → 各系统按什么顺序恢复、要不要手动干预。场景走通了，才算联调通过；只测单点功能通过，交付后照样会在真实场景里翻车。第五步：验收与留档联调记录要留下来：每台设备的 IP、账号（密码单独保管）、固件版本、接线照片、拓扑图最终版。交付时给业主一份简化版：出问题先看哪盏灯、重启顺序是什么、哪个口不能乱拔。没有留档的工程，下次上门维护等于重新做一次勘察。三、排障表：联调现场最常见的六种翻车现象先查什么常见根因门口机呼叫时断时续交换机 POE 功率、网线长度与线序POE 总功率超标，或超长线 + 劣质水晶头导致协商降速室内机能振铃但开不了锁电锁电源、开锁继电器接线锁电源与控制器共用一路，锁动作瞬间拉垮电压刷卡正常但记录不同步门禁控制器 IP、网关、NTP 时间控制器拿了 DHCP 临时地址，重启后变了；或时间不同步导致记录对不上摄像头一多，对讲就卡交换机背板带宽、是否跑满百兆口摄像头与对讲挤在同一个百兆口 / 同一台低端交换机上断电恢复后部分设备掉线各设备启动顺序、DHCP 租期门口机比交换机先启动，拿不到地址；或 DHCP 冲突远程能看摄像头，打不开对讲内网穿透 / 端口映射规则只映射了摄像头端口，对讲的信令端口没放行排障有个通用原则：先分层定位，再换件验证。先确认是线的问题、网络的问题还是设备参数的问题，再去动配置；一上来就恢复出厂设置，往往会把原本正常的参数也洗掉，越修越乱。四、几个容易被忽略的细节门口机与室内机固件版本要一致：跨版本联调最容易出“能呼叫、不能开锁”这种半通不通的怪现象，联调前先统一升级。门磁一定要装：没有门磁，门禁系统不知道门到底关没关，联动和报警全是摆设，验收时也说不清楚。弱电箱留余量：交换机端口、电源插座、线槽空间都留 20% 以上余量，今天多留一个口，明天加个摄像头就不用重新布线。防雷与接地别省：室外门口机、室外摄像头的外壳接地和防雷器，省下来的是成本，赔进去的是整机。标签与图纸随工程走：拓扑图最终版贴在弱电箱门内侧，下次任何人上门，打开箱门就知道线怎么走。五、验收清单（照着打勾就能交）[ ] 每根网线测线通过，标签与图纸一致[ ] 门口机 ↔ 室内机呼叫、开锁、夜视全部正常[ ] 门禁刷卡、出门按钮、门磁报警、断电状态全部验证[ ] 摄像头上 NVR、NAS 远程访问、内网穿透全部正常[ ] 断电再来电后，各系统自动恢复，无需手动干预[ ] 拓扑图、IP 表、账号清单已留档并交给业主联调这件事，拼的不是谁手速快，而是谁的顺序对。按物理层、网络层、单系统、跨系统、验收这五步走，问题出现在哪一层，就在哪一层解决，不要跨层猜。希望这篇能帮你在下一个项目里，联调当天准时收工。相关旧文一个门禁项目的布线到调试踩坑手记：门禁四组线的接法与调试细节，这篇联调的前提。群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战：摄像头上 NVR 与存储联动的工程视角。Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：远程访问走哪条穿透路线，联调前先定好。群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：联调留档与录像备份的配套思路。

群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战 家里、店里、工地现场装了摄像头，最怕的不是“看不到”，而是“关键时刻录像不在”。单靠一台 NVR 硬盘录像，硬盘一坏、机器一被偷，录像就全没了；单靠群晖 Surveillance Station 直录，摄像头一多、授权一超预算，又容易顾此失彼。这篇讲一套我现场常用的组合：NVR 主录 + 群晖 Surveillance 备份录 + 关键通道双录，海康、大华摄像头混接，一次把接入、存储、回放、权限讲透。一、先定架构：三种组合怎么选先别急着加摄像头，先定“录像存在哪、丢了哪一份还能找回”。方案录像落点优点缺点适合谁A. NVR 主录只存 NVR 硬盘成本最低、接线最简单NVR 坏了就全丢只有 4 路以内、能接受单点风险的小店B. NAS 直录只存群晖回放、权限、远程看都统一授权按路数买，路数多就贵；NAS 宕机也丢已有群晖、路数少于授权数C. NVR 主录 + NAS 备份录两份，互为备份一份坏了另一份还在；NAS 还能做权限分级和远程回放初期多花一台 NAS 的盘和授权门店、仓库、工地、别墅，本文推荐本文按方案 C 写：平时看 NVR，查事、给人看回放、远程调阅走群晖。两份录像不同盘、不同设备，才算真备份——同一台机器里两块盘，不叫异地备份，顶多叫冗余。二、动手前先对齐的几件事1. 授权数先算清。 群晖 Surveillance Station 自带 2 路免费授权，超出部分按路数买授权，一路一码、绑定 NAS，不要先装 8 个头再发现只剩 2 路。规划时只把“必须双录的关键通道”接进群晖，比如大门、收银台、仓库门、机房；走廊、后院这种只看实时的，可以只走 NVR。2. 时间必须同步。 摄像头、NVR、群晖三方时间差超过几分钟，回放对不上、报警时间也对不上。统一做法：群晖开 NTP 服务或三方都指向同一个 NTP 服务器（路由器或群晖都行），摄像头里把 NTP 地址填上，别用默认的出厂时间。3. 编码与码流先定好。 主码流录像用 H.265、1080p 或 4MP 即可，4K 全开只会把存储和带宽吃爆；子码流用来多画面预览和手机远程看，码率压低一点。双码流都开，后面回放和远程才不卡。4. 网段与 IP 先规划。 摄像头、NVR、群晖放同一个局域网段，摄像头用固定 IP（DHCP 保留或手动静态），别让摄像头 IP 隔三差五漂移——IP 一变，Surveillance 里就掉线。PoE 供电的，交换机功率要留余量，别按满配算。三、海康、大华摄像头接入群晖海康和大华都支持 ONVIF，这是混接的关键：不用管品牌，先用 ONVIF 通用协议接通，再按需换原厂协议调细节。海康摄像头：浏览器进摄像头后台，确认 ONVIF 已开启，并新建一个专门给群晖用的 ONVIF 用户（别用 admin 直连，改密码、降权限后出问题也好排查）。确认视频编码为 H.265、主码流分辨率与帧率符合规划。群晖 Surveillance Station → IP 摄像机 → 新增，品牌选 Hikvision 或 ONVIF，填入摄像头 IP、ONVIF 用户名密码、端口（ONVIF 默认 80，具体以摄像头后台为准），点“测试连接”，通了再保存。大华摄像头：同样在摄像头后台开启 ONVIF，建独立 ONVIF 用户。大华部分型号的 ONVIF 端口与 RTSP 端口分开，填错端口是掉线最常见的原因，对照摄像头后台的端口页逐项核对。群晖侧品牌选 Dahua 或 ONVIF，测试连接通过后再进下一步；如果 ONVIF 通但画面黑，先把编码从 H.265 切到 H.264 试一次，排除解码兼容问题，再切回来定位。通用排错清单： 测试连接失败时按这个顺序查：IP 通不通（ping 一下）、端口对不对、ONVIF 开没开、用户名密码对不对、摄像头时间与群晖时间差几分钟、是不是子码流参数被改乱了。一次只改一个变量，别同时改 IP 又改编码。四、NVR 联动：让 NVR 和群晖各录一份NVR 联动有两种接法，按现场已有设备选一种，别两种混着配：接法一：摄像头双推流（推荐）。 摄像头同时被 NVR 和群晖拉流：NVR 按自己的通道录一份，群晖按 ONVIF 再录一份。优点是两份录像完全独立，NVR 拔电也不影响群晖；缺点是摄像头要扛两路拉流，老型号或低端头同时推两路主码流会卡，解决办法是给群晖那一路用子码流或降一档分辨率。接法二：群晖拉 NVR 的流。 NVR 已接好所有头，群晖不再直连摄像头，而是通过 NVR 的 RTSP/ONVIF 通道把画面拉过来再录一份。优点是群晖侧只配 NVR 一个设备、授权占用少；缺点是 NVR 一挂，两份一起断，只能算“多一份拷贝”，不算真独立备份。现场已有 NVR 且不想动摄像头接线时，用这个过渡可以，但关键通道建议还是走接法一。不管哪种接法，录像计划都要分开设：NVR 侧设 24 小时连续录像，群晖侧对关键通道设连续录像 + 移动侦测报警录像叠加，非关键通道只设移动侦测录像，省盘又不漏事。报警联动别贪多：先把移动侦测灵敏度、侦测区域调准，再开推送，不然手机每天被误报刷屏，最后人就把推送关了，等于没装。五、存储怎么算、怎么配才不爆盘录像存储先算再买盘，公式很简单：单路每天存储 ≈ 码率（Mbps）× 86400 ÷ 8 ÷ 1024（GB）按主码流 4Mbps 算，单路每天约 43GB，8 路连续录 30 天约 10TB。群晖侧只给关键通道做连续录，移动侦测通道按实际触发时长打折算，盘就省下来了。群晖侧配置要点：给 Surveillance 单独建一个存储空间或共享文件夹，别和照片、文件备份混在一个卷里，录像写满不会拖垮别的服务。每个摄像头设录像保留天数和空间上限，写满按“先删最旧”循环覆盖，别等盘满了才发现新录像写不进。重要事件单独存档：查到关键片段后，用 Surveillance 的导出功能另存一份到别的共享文件夹或备份任务里，循环覆盖删不到它。结合 3-2-1 思路：NVR 一份、群晖一份，关键事件再导出一份到别处，才算闭环。备份方案的完整做法见相关旧文。六、回放与权限：谁能看、能看哪一路装完能看只是及格，分得清“谁能看哪一路”才算交付。群晖 Surveillance 里按人建账号：店长看全部，值班员只看大门和仓库，保洁、临时人员不给 Surveillance 账号，只给实时预览或干脆不给。手机端用 DS cam 登录，远程看之前先确认群晖的远程访问走的是自家内网穿透或 QuickConnect，别把 Surveillance 端口直接暴露到公网。回放查事流程固定下来：先定时间段，再按摄像头筛选，最后导出片段并备注事件时间——现场最常见的浪费时间不是没录像，而是没人知道去哪个时间点找。隐私红线：别把摄像头对着邻居家、员工更衣室、卫生间；员工、家人知情，是装监控的前提，不是可选项。七、现场避坑清单别用默认密码。 摄像头、NVR、群晖、ONVIF 用户，四个密码全改，摄像头后台的弱密码、不明端口、P2P 云服务不用的就关掉。固件先升级再交付。 海康、大华老固件的 ONVIF 兼容性坑最多，升级一次能省后面三趟上门。PoE 功率留余量。 交换机标称功率打七折算，红外夜视一开功耗就上去，满配必掉线。先通一路再批量。 第一路海康、第一路大华、第一路 NVR 联动都跑通并录满 24 小时，再批量复制配置，别一次加 16 路再排错。留一张拓扑图和一份 IP 表。 哪路头在哪个位置、IP 是多少、接哪个 PoE 口、录像存哪，写下来贴在机房或存进 NAS 文档里，下次维护的人（很可能就是半年后的你）会感谢这张纸。定期演练恢复。 每季度随机抽一天，实际从 NVR 和群晖各导出一段录像，确认两份都能播——没演练过的备份，等于没备份。八、结语监控这套东西，贵不在摄像头，贵在“出事时拿得出录像”。NVR 主录保底、群晖备份兜底、关键通道双录，这套组合不花哨，但停电、坏盘、被偷三种情况里至少有一种能保住证据。先按本文把一路海康、一路大华、一条 NVR 联动跑通，跑满 24 小时没掉线，再往上加路数，稳得多。相关旧文群晖 Surveillance 接入监控摄像头实现无限制空间存储录像（2024 年旧文，单点接入思路，本篇的多品牌 + NVR 联动为其进阶做法）：https://www.yeyhome.com/2024/05/05/38.html群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：https://www.yeyhome.com/2026/10/20/285.html一个门禁项目的布线到调试踩坑手记：https://www.yeyhome.com/2026/10/18/284.htmlLucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选（远程看回放的通道选型）：https://www.yeyhome.com/2026/10/14/268.html

lucky证书更新群晖自动同步 引言家里这套东西跑起来之后，有一个细节很容易被忽略：反代用的证书和群晖 DSM 用的证书，其实是同一张。Lucky 作为反代入口，负责申请和续签 Let's Encrypt 证书；DSM 的 Web 界面、群晖套件的 HTTPS 访问，走的也是这张证书。Lucky 续证很勤快，DSM 这边却不会自己跟着换——续证之后如果不把新证书同步过去，DSM 用的还是旧证书，拖到旧证书过期，浏览器就会开始报不安全。所以需要一个同步机制：Lucky 证书一变，DSM 里的证书就跟着变。这篇文章记录的就是我最后定下来的方案：不按固定日期跑，改成每天检测证书指纹，变了才同步。一、原来每三个月跑一次，为什么不好最开始我用的是 DSM 任务计划里一个每三个月执行一次的任务，到日子就跑更新脚本。这个办法能用，但有两个别扭的地方。第一，续证时间不固定。Let's Encrypt 证书有效期 90 天，Lucky 一般提前 30 天左右续签，也就是说证书实际变化的时间点，取决于 Lucky 的续签策略，而不是日历上的固定日期。按固定日期跑，运气好能赶上，运气不好就错过一轮。第二，时间卡得太死。我当时把任务定在证书到期日当天晚上，等于一点缓冲都没有。万一那次执行出点问题（比如脚本报错、服务没重启），旧证书过期了都还没人发现。后来我想明白了：与其算日子，不如直接盯着证书文件本身。文件变了，就说明续证发生了；文件没变，就什么都不用做。二、更新脚本到底做了什么同步的核心是一个更新脚本，它做四件事：先把 DSM 里正在用的旧证书备份一份，带时间戳，存在 Lucky 的配置目录下；把 Lucky 的新证书、新私钥复制到 DSM 的证书存档目录；把证书和中间证书合并成 fullchain；重启 DSM 的 nginx，让新证书生效。这里有个坑，值得单独说一句：这个脚本是宿主机脚本，不能在 Lucky 容器终端里跑。容器里看到的 /app/conf，其实就是宿主机上的 /volume1/docker/lucky 映射进去的；而 DSM 的证书目录 /usr/syno/etc/certificate/_archive/... 根本没有挂载进容器，synosystemctl 也是宿主机才有的命令。在容器里执行，只会得到一堆"文件不存在"。所以更新脚本必须跑在宿主机上，DSM 任务计划的用户账号选 root 就是这个原因。更新脚本全文如下（域名和存档目录换成自己的）：#!/bin/bash # 证书源目录 CERT_SRC_DIR="/volume1/docker/lucky/ssl" # 证书文件名，这里需要你按照你自己的情况修改，把你自己的域名填写在里面，比如上面你的域名填写的是*.qq.com，那么这你就填qq.com CERT_FILE="$CERT_SRC_DIR/yeyhome.pem" KEY_FILE="$CERT_SRC_DIR/yeyhome.key" CHAIN_FILE="$CERT_SRC_DIR/yeyhome_issuerCertificate.crt" # 群晖证书目标目录，这里需要你按照你自己的情况修改，一会在第三点里面会讲这个具体的位置是什么，每个人都不一样 CERT_DEST_DIR="/usr/syno/etc/certificate/_archive/9i9viz" # 备份旧证书 BACKUP_DIR="/volume1/docker/lucky/ssl/backup/cert_backup" mkdir -p "$BACKUP_DIR" # 创建备份目录 cp "$CERT_DEST_DIR/cert.pem" "$BACKUP_DIR/cert.pem.$(date +%Y%m%d%H%M%S)" # 备份证书 cp "$CERT_DEST_DIR/privkey.pem" "$BACKUP_DIR/privkey.pem.$(date +%Y%m%d%H%M%S)" # 备份私钥 cp "$CERT_DEST_DIR/fullchain.pem" "$BACKUP_DIR/fullchain.pem.$(date +%Y%m%d%H%M%S)" # 备份完整证书链 # 更新证书 cp "$CERT_FILE" "$CERT_DEST_DIR/cert.pem" # 复制新证书 cp "$KEY_FILE" "$CERT_DEST_DIR/privkey.pem" # 复制新私钥 cat "$CERT_FILE" "$CHAIN_FILE" > "$CERT_DEST_DIR/fullchain.pem" # 合并证书和中间证书 # 重启群晖 Web 服务 synosystemctl restart nginx # 重启 Nginx 使新证书生效 echo "证书已更新并重启服务。"注意事项：存档目录因人而异：9i9viz 是 DSM 给这张证书分配的存档编号，每台机器、每张证书都不一样，不能照抄。用 SSH 看 /usr/syno/etc/certificate/_archive/ 下面哪个目录里的证书和你的域名对得上（可以用 openssl x509 -in 目录/cert.pem -noout -subject 看域名），就用哪个。文件名按自己域名改：yeyhome.pem、yeyhome.key、yeyhome_issuerCertificate.crt 换成你自己的证书文件名。必须用 root 跑：DSM 的证书存档目录只有 root 能写，DSM 任务计划的用户账号要选 root，普通账号连查看都会被拒绝。只能在宿主机上跑：不要在 Lucky 容器终端里执行，容器里没有 DSM 证书目录，也没有 synosystemctl 命令。别只看成功提示：这个脚本没有 set -e，中途某一步失败也不会停下，最后还是会打印“证书已更新并重启服务”。所以每次同步后都要核对 DSM 里证书的修改时间和指纹，确认真的换了。旧证书有备份：每次执行都会把旧证书、旧私钥、旧 fullchain 带时间戳备份到 ssl/backup/cert_backup，万一新证书有问题可以回滚。三、新方案：每天检测指纹，变了才同步新方案的思路很简单：每天凌晨 3 点跑一次检测脚本，比对 Lucky 证书文件的 md5 指纹。指纹和上次记录的一样，说明证书没变，直接退出，nginx 也不会被重启；指纹不一样，说明 Lucky 续证了，马上执行更新脚本，同步成功后才把新指纹写下来。如果更新失败，指纹不会被写死，第二天还会再试一次。检测脚本全文如下：#!/bin/sh CERT=/volume1/docker/lucky/ssl/yeyhome.pem STATE=/volume1/docker/lucky/.cert_last_md5 LOG=/volume1/docker/lucky/check_ssl.log [ -f "$CERT" ] || exit 0 NEW=$(md5sum "$CERT" | awk '{print $1}') OLD=$(cat "$STATE" 2>/dev/null) if [ "$NEW" != "$OLD" ]; then if bash /volume1/docker/lucky/update_syno_cert.sh; then echo "$NEW" > "$STATE" echo "$(date '+%Y-%m-%d %H:%M') 证书变化，已同步" >> "$LOG" else echo "$(date '+%Y-%m-%d %H:%M') 证书变化，但更新脚本失败" >> "$LOG" fi else echo "$(date '+%Y-%m-%d %H:%M') 证书未变，跳过" >> "$LOG" fiDSM 任务计划里的设置也很简单：任务名 check ssl，用户账号 root，计划每天 3 点，脚本直接粘贴到任务的脚本框里，不用单独存文件。第一次跑的时候还没有旧记录，会先同步一次并重启一次 nginx，这是正常的；之后证书没变就每天只记一行日志。这里面有三个文件，分工很清楚：yeyhome.pem：Lucky 维护的证书本体，是检测对象；.cert_last_md5：上次同步时的证书指纹，是判断"变没变"的基准；check_ssl.log：每次运行的记录，能看到哪天跳过、哪天同步。四、怎么确认它真的在工作搭好之后不用天天盯着，但第一次最好验证一下：看日志：check_ssl.log 里应该有一行"证书未变，跳过"，说明检测脚本已经跑通过；看 DSM 证书：DSM 证书存档目录里 cert.pem 的修改时间，应该和 Lucky 证书同步的时间对得上；也可以直接比对两个文件的 md5，完全一致才算同步到位；看任务状态：DSM 任务计划列表里，check ssl 的"上次运行时间"和"状态"每次跑完都会更新，状态是成功就说明没问题。资源占用也不用担心。每天一次的检测，就是读一个 5KB 多的文件算个 md5、再读一个几十字节的状态文件，全程几十毫秒，没有常驻进程。真正"重"的重启 nginx，一年也就发生几次——只在证书真的续签了那天。五、另外两条路为什么没选其实还考虑过另外两个方案，最后都没用，顺便记一下，免得以后绕回来。一个是 Lucky 的触发器 + Bark 推送：Lucky 续证后触发一条 Bark 消息，再由脚本检测到消息后执行更新。这个办法的问题是 Bark 只有推送接口，没有查询历史消息的接口，脚本没法直接"看到"消息；要实现就得去翻 Bark 容器的日志，可靠性差了一截。另一个是 inotify 实时监听：守着证书文件，一变立刻执行。这是最实时的，但群晖默认没有 inotifywait，得另外装工具、搞常驻进程和开机自启，为 90 天才发生一次的事折腾这个，不值。指纹检测算是折中得刚刚好：每天一次，延迟最多 24 小时，失败自动重试，没有常驻进程，也不依赖任何外部服务。结尾证书这种东西，平时感觉不到它的存在，出问题的时候却都是大事。把同步做成"变了才动、动了必记"的样子，之后就不用再算日子、不用再惦记续证时间，交给每天凌晨 3 点的那一次检测就行。相关旧文：Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选

群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好 群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好前言：NAS 不是保险箱很多人把数据塞进群晖 NAS 就觉得万事大吉：RAID 保护、硬盘冗余、UPS 续航……听上去固若金汤。但干了这些年弱电和 NAS 维护，我见过的翻车实在太多：硬盘到寿批量坏掉、勒索病毒加密全盘、一场雷击带走整台机器、装修工人一脚踢掉电源。这些事故发生时，很多人才第一次意识到：RAID 只是"高可用"，不是备份。硬盘坏一块能恢复，数据被加密、被删除、整机被偷，RAID 一点忙都帮不上。真正靠谱的做法是业界用了几十年的 3-2-1 备份原则：至少 3 份数据，存放在 2 种不同介质上，其中 1 份放在异地。今天这篇文章，就在群晖 DSM 7.2 上把这套方案一次配好：快照（防误删、勒索）+ Hyper Backup 本地备份（防整机故障）+ 异地备份（防火灾、盗窃），最后再做一次完整的恢复演练——没演练过的备份，等于没备份。一、先规划：三层防线各防什么层级工具防什么恢复速度成本第一层快照复制（Snapshot Replication）误删、改错、勒索病毒秒级几乎为零第二层Hyper Backup → USB 移动硬盘整机故障、硬盘全挂分钟~小时级一块硬盘的钱第三层Hyper Backup → 异地 NAS / 公有云火灾、盗窃、本地天灾小时~天级按量付费三层是"串联"不是"三选一"：快照快但怕整机没了，本地备份全但怕家里出事，异地备份最保险但恢复最慢。配齐三层，任何一层出问题都有兜底。二、第一层：快照——防误删和勒索的最快防线快照严格说不算备份，但它是性价比最高的防线。Btrfs 文件系统的写时复制（COW）特性，让快照生成只需几秒、平时几乎不占空间。只有装在 Btrfs 文件系统上的共享文件夹才能拍快照——如果是旧存储池（EXT4），得先迁移，这个提前确认好。配置步骤打开 快照复制 套件，选中存放重要数据的共享文件夹（比如 home、photo、docker）；点击「快照」→「设置」→「计划」，设为每天自动快照一次，建议凌晨业务低峰时段；「保留原则」里设保留最近 30 个快照，勾选「锁定」最关键时间点的快照，防止被保留策略自动删掉；开启「快照可见性」，这样在 File Station 里可以直接浏览快照里的历史文件。恢复怎么用在 File Station 里右键共享文件夹 →「浏览以前的版本」，找到删错之前的时间点，把文件拖出来就行，整个过程几秒钟。勒索病毒加密了当前文件？快照是只读的，加密软件动不了快照里的旧版本，直接从快照还原即可。避坑快照防不了整机故障：机器丢了、存储池崩了，快照跟着一起没。它只负责"第一层"，千万别把它当完整备份。快照保留数量别贪多：每个快照都保留一份"差异数据"，保留 30 天对普通家庭/小办公室足够，保留一年会把空间吃光。重要目录建议单独建共享文件夹拍快照，比如把 Docker 容器映射卷单独放一个共享文件夹，恢复容器数据时不会影响别的文件。三、第二层：Hyper Backup 本地备份——防整机故障Hyper Backup 是群晖官方备份套件，支持备份到本地文件夹、USB 外接设备、另一台群晖、公有云。先配本地这层：拿一块容量大于等于源数据的移动硬盘（建议 USB 3.0 以上接口），插到 NAS 的 USB 口上。配置步骤套件中心安装 Hyper Backup，打开后「新增」→「数据备份任务」→ 选择「本地文件夹和 USB」；勾选要备份的共享文件夹（建议全选重要目录）、应用程序（比如 Container Manager 的配置、MailPlus）；备份目的地选插好的 USB 移动硬盘，勾选「启用备份计划」（每周一次全量+每日增量是常用组合）；务必勾选「启用客户端加密」并记好密码：硬盘丢了也不怕数据泄露；但密码丢了备份就彻底打不开了，密码和备份介质必须分开存放；开启「备份完整性检查」，让 NAS 定期验证备份包没坏。恢复怎么用Hyper Backup →「还原」→「数据」，选择 USB 上的备份任务，可以整包还原，也可以只挑几个文件还原。手机端装 Hyper Backup Explorer 同理。避坑USB 硬盘建议两块轮换：A 盘在 NAS 上备份，B 盘放在公司/亲戚家，每周换一次。这其实是"异地"的廉价实现，我称它为"人肉异地"。备份完拔掉硬盘或至少在 Hyper Backup 里暂停任务：勒索病毒如果能访问到挂载的 USB 盘，备份盘也可能遭殃。离线，才是备份的终极保险。别用杂牌硬盘做备份盘：备份盘是最后防线，用靠谱品牌，SMART 定期检查。四、第三层：异地备份——防火灾和盗窃本地两层都配好了，还剩最后一层：异地。方案按成本从低到高：方案 A：备份到亲戚/老家的另一台群晖（推荐）在对方 NAS 上装 Hyper Backup Vault 套件，本机 Hyper Backup 新增任务选「远程 NAS 设备」，填对方的 QuickConnect ID 或域名+端口。首次全量备份建议把硬盘拿到现场做（几百 GB 走公网传要传到天荒地老），之后每天增量走公网即可。异地机器如果在内网没有公网 IP，可以用本站之前实测过的内网穿透方案打通：参考本站文章《Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选》。方案 B：备份到公有云Hyper Backup 原生支持 Synology C2、S3 兼容存储、阿里云 OSS、腾讯云 COS 等。优点是省心、不用求人；缺点是长期费用。小数据量（<100GB）可以考虑 C2 的免费/低价档；大照片库走公有云一年下来不便宜，建议只把最重要的文档类数据放云端。方案 C：备份到 VPS（rsync）有闲置 VPS 的话，Hyper Backup 支持 rsync 目标。注意 VPS 硬盘一般不大，适合文档类数据；另外记得给 VPS 也做好快照，异地备份本身也需要被保护。避坑异地备份必须开客户端加密：数据要经过公网、放在别人机器上，不加密等于裸奔。加密密码、Hyper Backup 的备份任务配置，单独记一份放在密码管理器里（本站有《Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实战》可以参考）。异地备份的恢复演练最容易被忽略，但恰恰是它最可能在关键时刻掉链子——见下一节。五、恢复演练：没演练过的备份等于没备份备份配完只是完成了 50%，另外 50% 是确认它真的能恢复。建议每季度做一次，流程如下：快照演练：在测试目录新建一个文件，删掉，然后从快照里找回来。确认快照计划真的在跑、保留策略没把需要的版本清掉。本地备份演练：从 USB 备份里还原一个共享文件夹到临时目录（别直接覆盖生产数据），打开几个文件确认能正常读取。异地备份演练：模拟"本地全挂"——从异地备份里拉回一份关键数据。重点验证：网络通不通、加密密码对不对、恢复速度能不能接受（几百 GB 的异地恢复可能要一整天，这个时间要心里有数）。把演练结果记下来：哪一层花了多久、有没有报错。演练中发现的问题（比如 USB 盘 SMART 报错、异地任务连续失败一周没人看）现在修，总比灾难那天修便宜。另外给 Hyper Backup 开启通知：控制面板 → 通知 → 勾选 Hyper Backup 任务失败时推送到手机/邮箱。备份任务静默失败几个月，是我见过最多的"假备份"。六、避坑清单（全文精华）RAID ≠ 备份，再说一遍。快照只防"文件级"事故，整机没了快照也没了。备份盘备份完就离线，防勒索。异地备份必须客户端加密，密码和介质分开存。备份通知必须开，静默失败最致命。每季度做一次恢复演练，恢复时间要心里有数。USB 备份盘两块轮换，等于廉价异地。应用程序配置也要备份：Docker 容器的 compose 文件、MailPlus 设置，重装时比数据还难找回。写在最后3-2-1 听起来像大道理，落到群晖上其实就是三个套件、一下午的配置：快照复制管"手滑"，Hyper Backup + USB 管"机器挂"，Hyper Backup + 异地管"家没了"。配完记得做一次演练，然后你就可以安心地把照片、文档、项目资料交给这台小黑盒子了——毕竟，备份的价值不在"有"，而在"灾难那天真的能拿回来"。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选 —— 异地备份到另一台 NAS 时，内网穿透选型参考Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实测 —— 备份加密密码存哪？放进自建密码库Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 —— 记得把 Docker 容器数据目录也纳入备份范围

Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解 Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解手里几台 VPS、NAS、小主机，CPU 飙了、磁盘满了、流量跑超了都不知道？今天介绍 Komari：一款轻量开源的服务器监控面板，MIT 协议免费，Docker 一条命令跑起来，多台机器的资源状态一屏看清。顺带讲清楚它和 Uptime Kuma 到底有什么区别、该怎么选。Komari 是什么？Komari（komari-monitor/komari）是一个自托管的服务器监控工具，Go 语言开发，GitHub 6000+ Star，MIT 开源协议，完全免费无付费版。它的工作模式和“哪吒探针”类似：面板端 + Agent 端。你在 NAS 或一台 VPS 上部署面板（Dashboard），然后在每台要监控的机器上装一个轻量 Agent，Agent 会把 CPU、内存、磁盘、网络、流量、负载等指标实时上报到面板，打开网页就能看到所有机器的状态。核心特点：极轻量：Agent 资源占用极小，面板默认 SQLite，不用额外装数据库；秒级实时：官方称监控数据按秒级间隔展示，机器状态变化立刻可见；自托管：数据只留在你自己的服务器上，不经过第三方；可玩性高：支持自定义主题和插件，社区有主题市场，监控页可以做得很好看；附带 Web 终端：面板里可以直接打开被控机的终端，排查问题不用再 SSH。Docker 部署面板：一分钟搞定官方镜像在 GitHub Container Registry，默认端口 25774，数据目录 /app/data，不配数据库就用 SQLite：mkdir -p ./data && docker run -d \ -p 25774:25774 \ -v $(pwd)/data:/app/data \ --name komari \ --restart unless-stopped \ ghcr.io/komari-monitor/komari:latest更推荐 Compose，方便以后升级：services: komari: image: ghcr.io/komari-monitor/komari:latest container_name: komari restart: unless-stopped ports: - "25774:25774" volumes: - ./data:/app/data启动后打开 http://服务器IP:25774，首次访问会进入安装向导：创建管理员账号、设置站点名称。./data 目录存着账号、配置和监控记录，记得定期备份。群晖 NAS（Container Manager）部署步骤Container Manager → 项目 → 新增，项目名填 komari，路径选一个顺手的共享文件夹；把上面的 Compose 内容粘贴进 docker-compose.yml；下一步完成，等镜像拉取完、容器状态变为运行中；浏览器打开 http://群晖IP:25774，按向导创建管理员账号。端口提醒：25774 记得在群晖防火墙放行（仅内网访问的话不用映射到公网）。接入被控机：装 Agent面板跑起来只是第一步，Komari 的精髓是 Agent 上报。流程：登录面板后台，进入节点管理，添加一个节点（填个名字，比如“腾讯云-上海”）；面板会生成一条一键安装命令，里面带了面板地址（endpoint）和节点 Token；去被控机上以 root 执行这条命令，Agent 就会自动下载、安装并连回面板；回到面板，节点显示在线，CPU/内存/磁盘/流量曲线开始滚动。Agent 本身也支持容器化（ghcr.io/komari-monitor/komari-agent，参数 -e 面板地址 -t Token），但注意：容器里的 Agent 只能看到容器视角的资源，想监控整台宿主机还是建议用一键脚本直接装在宿主机上。装完后的效果大概是这样（官方仪表盘实拍）：核心功能速览节点总览：所有机器在线状态、CPU/内存/磁盘/流量、累计流量一屏展示；历史曲线：每台机器的资源使用历史图表，半夜谁在偷跑流量一目了然；Web 终端：面板里直接进被控机终端，应急排查不用找 SSH 客户端；通知告警：节点掉线、资源超限可以推送通知（支持 Telegram 等常见渠道）；主题市场：监控页支持换主题，做成公开的服务器状态页也很好看。重点：Komari 和 Uptime Kuma 有什么区别？这是被问得最多的问题。两者都是“监控”，但监控的东西完全不是一回事：对比项KomariUptime Kuma监控对象服务器本身（CPU/内存/磁盘/流量）服务是否在线（网站/API/端口通不通）工作原理被控机装 Agent，由内向外上报指标监控端由外向内主动探测（HTTP/TCP/Ping/DNS）被监控端需要安装 Agent什么都不用装典型问题“这台 VPS 内存是不是又满了？”“我的博客是不是又挂了？”状态页有（展示机器状态）有（展示服务在线率，更成熟）告警节点掉线、资源超限告警服务 Down 告警，通知渠道极丰富（90+ 种）部署面板容器 + 每台机器装 Agent单个容器即可资源占用都很轻都很轻一句话总结：Komari 回答“机器健不健康”，Uptime Kuma 回答“服务活没活”。举个例子：你的博客打不开了——Uptime Kuma 会立刻告诉你“网站 Down 了”；而 Komari 会告诉你“这台 VPS 的内存 98%、磁盘满了”，帮你定位为什么挂了。一个管“现象”，一个管“原因”。该怎么选？只想知道网站/服务有没有挂 → Uptime Kuma 就够了，部署最简单；手里有多台 VPS/NAS，想看资源用量、流量统计 → Komari；都想要 → 两个都跑，它们是互补关系不是替代关系。很多人的标准组合就是：Uptime Kuma 做存活告警 + 状态页，Komari 做资源总览。（本站后续也会出一篇 Uptime Kuma 的部署教程，敬请期待。）远程访问与安全建议面板默认 HTTP，不要直接把 25774 暴露到公网。需要外网看监控页，走反代 + HTTPS（Lucky / Nginx Proxy Manager 都行）；Agent 连面板走的是出站连接，被控机不用开入站端口，NAT 后面的机器也能接；管理员设强密码，./data 目录定期备份——监控历史丢了是小事，账号配置丢了重建麻烦。总结Komari 是一款“装完就回不去”的小工具：面板一条 Docker 命令，被控机一条安装命令，几台机器的 CPU、内存、流量就全收进一个仪表盘了。配合 Uptime Kuma，一个管机器健康、一个管服务存活，个人服务器的监控体系就算齐活了。花二十分钟搭起来，以后半夜收到告警，打开面板就知道是哪台机器在作妖。相关阅读：Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战群晖 Docker 容器升级失败怎么办：备份、回滚与日志排查完整指南群晖 NAS 使用 Docker 部署 Lolia FRP 实现多隧道内网穿透Lucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案

Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战还在用命令行 docker ps 一个个查容器状态？Portainer 用久了觉得功能跟不上？今天介绍一款新面孔——Dockhand：开源免费的 Docker 可视化管理平台，家庭实验室永久免费，自带中文界面，群晖 NAS 上一条命令就能跑起来。Dockhand 是什么？Dockhand（dockhand.pro）是一个现代化的 Docker 管理平台，定位和 Portainer 类似：给你一个网页管理界面，容器的启停、日志、终端、Compose 编排都能点鼠标完成，不用再记命令。几个关键特点，先说结论：家庭实验室永久免费：核心功能（容器管理、Compose、Git 部署、漏洞扫描、备份）免费版全有，不按功能阉割；部署极轻：默认 SQLite，不用额外装数据库，树莓派 4 都能跑，群晖 NAS 更不在话下；中文界面：支持简体中文，浏览器语言自动识别；零遥测：不回传任何使用数据，数据只留在你自己的机器上；源码开放：BSL 1.1 协议开源，每个版本四年后自动转为 Apache 2.0。功能亮点速览功能说明容器管理启停、重启、删除、批量操作，CPU/内存实时指标可视化 Compose可视化编辑 Compose，还有依赖关系图，不用死磕 YAML网页终端直接进容器执行命令，不用 SSH实时日志日志流式查看，支持 ANSI 颜色、时间范围和关键字过滤Git 部署从 Git 仓库部署 Stack，支持 Webhook 自动部署定时任务镜像自动更新、定时同步，带安全拉取保护（先扫描再更新）备份恢复基于 restic 的加密备份，可备份数据卷和 Stack 文件，支持 S3 等漏洞扫描集成 Grype/Trivy 扫描镜像 CVE 漏洞通知推送支持 Bark、Telegram、ntfy 等，容器崩了第一时间知道多环境管理一台 Dockhand 管多台 Docker 主机，还有穿透 NAT 的 Hawser AgentOIDC/SSO免费版就带单点登录和双因素认证对 NAS 用户来说，最实用的就是前四项：容器状态一目了然，日志和终端点开即用，Compose 项目可视化管理。部署：一分钟跑起来Dockhand 官方给出了一键命令，数据只用一个 volume，配置极简：docker run -d \ --name dockhand \ --restart unless-stopped \ -p 3000:3000 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v dockhand_data:/app/data \ fnsys/dockhand:latest更推荐用 Compose，方便以后升级维护：services: dockhand: image: fnsys/dockhand:latest container_name: dockhand restart: unless-stopped ports: - 3000:3000 volumes: - /var/run/docker.sock:/var/run/docker.sock - dockhand_data:/app/data volumes: dockhand_data:安全提醒：挂载 docker.sock 意味着 Dockhand 拥有操作宿主机 Docker 的最高权限，这是所有 Docker 管理面板的通用做法。务必给 Dockhand 设置强密码，不要把 3000 端口直接暴露到公网，需要远程访问请走反代 + HTTPS。群晖 NAS（Container Manager）部署步骤打开 Container Manager → 项目 → 新增，项目名称填 dockhand，路径选一个顺手的共享文件夹；在 docker-compose.yml 编辑框粘贴上面的 Compose 内容；点下一步完成，等待镜像拉取完成、容器状态变为运行中；浏览器打开 http://群晖IP:3000，看到登录页即部署成功。初始化：创建管理员并连接本地环境首次打开会让你创建一个管理员账号，设置好用户名和强密码。登录后 Dockhand 会自动识别本机的 Docker 环境（通过挂载的 docker.sock），仪表盘上立刻能看到这台机器的容器数量、镜像数、CPU 内存状态。如果你有多台机器（比如一台群晖 + 一台小主机），可以在“环境”里添加远程主机：支持 TCP + TLS 连接；内网穿透场景可以用官方的 Hawser Agent，Agent 主动向外连，不用开防火墙端口——思路和 FRP 内网穿透很像，适合没有公网 IP 的机器。核心用法：日常用这几个就够了容器管理：容器列表里能看到每个容器的实时 CPU/内存占用，批量选中可以一键重启、停止、删除；点进容器详情能看完整配置、挂载、环境变量，改 CPU/内存限制不需要重建容器。网页终端：选中容器点 Shell，直接进容器执行命令，排查问题不用再 SSH 到 NAS 上敲 docker exec。下面是官方的终端界面实拍：日志查看：日志页面支持实时流式输出，带颜色高亮，可以按时间范围和关键字过滤。容器起不来的时候，先来这里看第一条报错——排查思路和之前写的 Docker 升级排障指南是一样的：先看日志，再动手。Stacks（Compose 项目）：可以可视化创建和编辑 Compose 项目，还有只读的依赖关系图；已经用 Compose 跑起来的项目，Dockhand 能自动识别接管，不用重建。Git 部署：把 Compose 文件放 Git 仓库，Dockhand 定时同步，配合 Webhook 实现改完代码自动部署，适合跑博客、图床这类自建服务。通知推送：在设置里配好 Bark（iOS）或 Telegram，容器异常退出、备份完成都能收到推送。之前本站介绍过自建 Bark 服务器推送评论，Dockhand 的通知走 Apprise 协议，Bark 同样支持。远程访问：建议走反代不要把 3000 端口直接映射到公网。正确做法是在内网跑 Dockhand，外网访问走反向代理：有公网 IP：用 Lucky 或 Nginx Proxy Manager 反代 http://群晖IP:3000，配好 HTTPS 证书；没公网 IP：内网穿透（FRP/Lucky）把 3000 端口穿透出去，同样建议套一层 HTTPS。反代配置可以参考本站之前的 Lucky 反代教程和 FRP 内网穿透教程。和 Portainer 简单对比对比项DockhandPortainer CE费用家庭实验室永久免费社区版免费数据库默认 SQLite，极轻需要外部数据库（较重）中文界面原生支持简体中文社区汉化备份内置 restic 加密备份需手动/商业版漏洞扫描内置 Grype/Trivy商业版功能通知推送内置 Bark/Telegram 等需 Webhook 自行对接上手难度界面更现代，学习成本低生态成熟，教程多如果你是 Portainer 老用户，Dockhand 值得一试；如果你还没用过任何面板，直接上 Dockhand 更省事。两者可以共存，不冲突。注意事项数据持久化：dockhand_data 这个 volume 一定要保留，删了配置和用户数据就没了；重要环境建议再用 Dockhand 自带的备份功能定期备份；升级：fnsys/dockhand:latest 拉新镜像重建即可，升级前按老规矩备份数据、记录版本；资源占用：官方称树莓派 4 可跑，群晖上实测内存占用很小，适合长期挂着；安全：强密码 + 不直接暴露端口 + 定期更新，三件套做好。总结Dockhand 给我的整体感觉是“Portainer 的现代化重制版”：部署一条命令、界面清爽、中文原生、备份扫描通知全家桶免费。对群晖 NAS 用户来说，它是管理一堆 Docker 容器的好帮手——容器状态、日志、终端、Compose 项目，一个网页全搞定。花十分钟部署上，你的 NAS 容器管理就从命令行时代进入面板时代了。相关阅读：群晖 Docker 容器升级失败怎么办：备份、回滚与日志排查完整指南群晖 NAS 使用 Docker 部署 Lolia FRP 实现多隧道内网穿透Lucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案群晖更新 Docker 容器

群晖 Docker 容器升级失败怎么办：备份、回滚与日志排查完整指南 整理一套适合群晖与家庭服务器用户的 Docker 升级失败恢复流程。

Hark Pro 注册与使用教程：体验"主动式"AI 助手 10 月 6 日，Figure AI 创始人 Brett Adcock 的新公司 Hark 发布了首款产品 Hark Pro。这不是又一个问答聊天机器人，而是一个"主动式"AI 助手——它不等你下指令，自己发现待办事项并动手去做，被称为"你人生的操作系统"。这篇教程带你从注册到上手，快速体验它。一、Hark Pro 是什么？先说背景。Hark 的创始人 Brett Adcock 来头不小：他先后创办了 Vettery（招聘平台）、Archer Aviation（电动空中出租车），以及大名鼎鼎的人形机器人公司 Figure AI。Hark 是他的第四次创业，2025 年底成立，今年 5 月就拿到了 7 亿美元 A 轮融资，估值 60 亿美元——一家产品还没发布就拿到这种融资的公司，整个 AI 圈都没几家。Hark Pro 在 10 月 6 日正式公开发布，网页版、iOS、Android 全平台免费可用。它和传统 AI 助手最大的区别就一个词：主动。传统助手：你问一句，它答一句，不问就闲着；Hark Pro：你把邮箱、日历、常用账号连上，它自己整理信息、自己发现待办——航班该值机了、账单该付了、快递该签收了，首页直接给你摆好"一键执行"的按钮。用官方的话说，它想做的是"proactive（主动式）"而非"reactive（反应式）"的助手。二、核心功能：Handoff、Action Buttons、PanelsHark Pro 有三个杀手级功能，理解了它们就理解了这款产品。Handoff：它有自己的云端电脑这是 Hark Pro 的心脏。和某些 AI 助手只能调用 API 不同，Handoff 会为你开一台专属的云端电脑，上面跑着完整的浏览器，像真人一样上网：点按钮、填表单、比价、下单，一气呵成。据报道，它最多可以同时开 6 个浏览器并行干活——比如同时对比 6 家酒店的价格。操作过程中会有一个小窗口实时显示它在干什么，遇到付款这类敏感步骤会停下来先请示你。Action Buttons：不用你想的待办清单连上邮箱和日历后，Hark Pro 会自己分析你的事项，在首页生成一排"行动按钮"：航班值机、账单支付、快递签收确认、上传发票报销……你只需要点一下，它就从头到尾办完。这就是"主动式"的直观体现。Panels：你的专属信息面板在聊天旁边，Hark Pro 还有"Panels"——一块块可定制的信息面板：信用卡余额、订单物流、航班状态、本周跑步里程，问一句还能深挖数据。它会学习你的偏好，越用首页越顺手。另外它还有持久记忆，记住你的习惯和偏好，回答越来越对味；Projects 功能则适合长期事项，比如求职、旅行规划，帮你分门别类管起来。三、注册与下载Hark Pro 目前全平台免费：网页版：打开 hark.com 直接注册使用；iPhone：App Store 搜索"Hark"下载；安卓：Google Play 搜索"Hark"下载。注册只需要一个邮箱，按提示完成验证即可。值得一提的是早鸟福利：前 10 万名注册用户免费送付费版（Pro²/Pro³）——现在注册大概率还能赶上。四、上手使用：连上账号，能力翻倍光聊天体现不出 Hark Pro 的价值，关键一步是连接你的常用账号。在设置里把邮箱、日历等连上之后，它才能真正"主动"起来：连上邮箱：它会自动发现未回复的重要邮件、待付账单、待报销发票，生成行动按钮；连上日历：它能发现日程冲突并给出解决方案；再往后：订票、约会、比价这些脏活累活，点一下按钮就有人（AI）去干了。上手路径很简单：先在首页看看它为你生成的行动按钮，点一个试试；再试试让它帮你做件具体的事，比如"帮我查一下下周的航班并值机"。记住它的设计哲学：你不用学提示词，它负责发现需求。五、价格方案Hark Pro 的定价很实在：免费版：全部功能都可以用，有用量额度限制；Hark Pro²：20 美元/月，用量翻倍；Hark Pro³：100 美元/月，用量是免费版 10 倍。注意：付费档不锁功能，只给更多用量，应用内也没有广告。前 10 万名用户送付费版，薅羊毛要趁早。六、安全与隐私：Secured by Hark把邮箱密码、支付信息交给一个 AI，先问一句"安全吗"是应该的。Hark 官方的说法是：Secured by Hark：登录信息和卡片存在加密保险库中，官方称连自家员工都读不到；端到端加密：数据传输全程加密；敏感操作先请示：付款、删数据这类动作，动手前一定先问你。当然，这些目前是官方单方面承诺，还没有看到独立第三方审计报告。稳妥起见，建议先从低风险账号开始连，等信任建立起来再逐步放开——这也是对待所有 AI 助手都该有的态度。七、和 Muse 的对比：两条路线的 AI 助手本站前几天刚发过 Muse 的教程，有读者可能会问：Hark Pro 和 Muse 有什么区别？简单说：Muse：更像一个听话的助理，你交代任务，它拆解执行，重要节点请示你；Hark Pro：更像一个主动的管家，不等你开口，自己发现事情、自己建议行动。两者都强调"替你办事"而非"陪你聊天"，代表了 AI 助手正在从"问答工具"转向"执行代理"的大趋势。至于 2027 年 Hark 要发布自家硬件设备，那是后话了——先把软件玩明白再说。结语Hark Pro 的出现，标志着 AI 助手进入了"主动式"时代：从"你问我答"变成"我发现、我建议、我执行"。花十分钟注册并连好账号，你就多了一个 24 小时在线、还会自己找活干的数字管家。至于它能不能兑现"人生操作系统"的野心，让我们拭目以待。

Muse AI 注册与使用教程：手把手教你拥有一个个人 AI 助理 最近 Meta 推出了一款个人 AI 智能体 Muse，和常见的聊天机器人不同，它有自己的一台云端电脑，能真正替你办事：收发邮件、安排日程、查资料比价、订票订酒店，甚至定时帮你盯事、发提醒。这篇教程带你从注册到上手，完整走一遍。一、Muse 是什么？简单说，Muse 是你的专属 AI 助理，有三个特点：有自己的电脑：每个用户都有一台独立的云端电脑，它可以在上面装软件、跑任务，你不在它也能干活；能操作真实网站：有自己的浏览器，可以登录网站帮你查订单、比价、下单（重要操作会先请示你）；能连你的应用：邮箱、日历、Facebook、WhatsApp 等，授权后它就能替你打理。二、下载与注册Muse 支持 iOS、Android、Mac 和网页版：iPhone：App Store 搜索「Muse」下载；安卓：Google Play 搜索「Muse」下载；Mac：在 ai.meta.com/muse/download 下载客户端；网页版：直接打开 muse.ai 就能用，手机浏览器也可以。注册需要一个 Meta 账号，按提示用手机号或邮箱完成即可。目前 Muse 主要在美国和加拿大区上架，如果应用商店搜不到，可以先用网页版体验，功能是一样的。三、邀请码兑换（领 10 亿词元）如果你有朋友的邀请码，记得在加入后的 48 小时内兑换：打开 Muse App，进入「设置」；找到「兑换邀请码」（Redeem token）；输入邀请码并确认，双方都能获得 10 亿 Muse 词元。比如我的邀请码是 V7B1J0，欢迎使用：https://muse.ai/join四、上手使用：直接说人话就行Muse 的使用方式很简单——直接说你的需求，不用学什么提示词技巧。比如：「帮我查一下下周北京飞上海最便宜的机票」「每天早上 8 点给我发一份科技新闻简报」「把这篇英文文章翻译成中文并做个摘要」它会自己拆解任务、调用工具去完成，遇到需要你确认的地方（比如付款、发邮件）会停下来等你点头。五、连接你的应用，能力翻倍在设置里把常用应用连上，Muse 才能真正替你打理事务：邮箱（Gmail）：收发邮件、草拟回复、整理收件箱；日历：查日程、约会议、改时间；Facebook / WhatsApp：在聊天软件里直接跟它对话；更多连接持续增加中。六、定时任务：让它每天自动干活这是 Muse 最实用的功能之一。你可以安排周期性任务，比如：每天早上推送天气预报和穿衣建议；每周一整理上周的邮件并生成摘要；每月提醒你交水电费、还信用卡。设置一次，它就会按时执行，结果直接发到你的聊天里。七、进阶玩法侧边聊天：不同话题开不同的聊天，互不干扰，比如一个聊工作、一个做足球分析；文件与神器：让它写文档、做表格、生成网页和小工具；语音对话：支持语音输入和语音播报，开车时也能用。八、注意事项重要操作（付款、发邮件、删数据）Muse 会先请求你的确认，这是保护机制；账号密码等敏感信息只在官方安全页面输入，不要直接发在聊天里；免费版有用量额度，重度使用可以考虑订阅制。结语Muse 和传统 AI 聊天最大的区别，就是从“只会说”变成了“会办事”。花十分钟注册并连好应用，你就多了一个 24 小时在线的助理。祝使用愉快！