群晖 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

青龙面板进阶：PT 签到之外还能自动干什么 青龙面板很多人是冲着 PT 签到装的，装完跑一个签到脚本就扔在那里吃灰。其实它本质上就是一台带可视化界面的“定时任务服务器”：能跑脚本、能定 cron、能看日志、能发通知。签到只是它最不起眼的一种用法。这篇是之前那篇 PT 签到文的进阶篇，讲讲青龙在群晖 NAS 上除了签到，还能替你自动干哪些正经事，以及哪些坑别踩。青龙到底是什么，先说清楚青龙面板（Qinglong）是一个支持 Python、Node.js、Shell 等多种脚本的定时任务管理面板。你可以把它理解成“带界面的 crontab + 脚本仓库 + 日志查看器”：脚本往里一贴，执行时间用 cron 表达式一填，跑没跑、跑出什么结果，都能在面板里直接看到。它适合干的活有一个共同点：重复、定时、不需要人盯着。签到符合，备份、清理、巡检、提醒也都符合。反过来，需要交互、需要实时响应的活（比如远程桌面、在线聊天）就不适合它，别硬塞。如果你已经装过青龙，直接跳到下一节；还没装的，先用下面这段 Compose 在群晖 Container Manager 里起一个。Docker 一键部署在群晖上新建一个项目，docker-compose.yml 如下：services: qinglong: image: whyour/qinglong:latest container_name: qinglong restart: unless-stopped ports: - "5700:5700" volumes: - ./data:/ql/data environment: - QlBaseUrl=/部署要点只有三条：数据卷 ./data 一定要映射出来，否则容器一删，脚本、定时任务、环境变量全没了；端口 5700 别和已有服务冲突，冲突就改左侧端口，比如 5701:5700；首次打开 http://群晖IP:5700，按向导设好账号密码和通知方式（推荐 Bark 或邮件，巡检告警全靠它）。部署完先别急着往里塞脚本，先把下面这套“进阶用法”想清楚：你到底想让它替你省哪几件事。进阶用法一：多站点签到聚合，不止 PTPT 签到是起点，不是终点。很多论坛、网盘、工具站都有每日签到或每日任务，逻辑大同小异：登录、请求签到接口、判断返回结果、失败发通知。进阶的做法不是一个站点写一个脚本到处复制，而是一个脚本管一类站点：把账号、Cookie、签到地址放进青龙的环境变量，脚本只读变量不写死账号。新增一个站点，只加一组变量，不用改代码。实测步骤：在青龙「环境变量」里新建变量，如 SITE_COOKIE、SITE_SIGN_URL；在「定时任务」里新建任务，命令填 task 脚本名.py，cron 填 0 8 * * *（每天 8 点跑）；手动点一次「运行」，看日志里是“签到成功”还是“已签到”，确认无误再交给定时。提醒一句：签到脚本只用在你自己有账号、且站点规则允许自动签到的地方。有的站点明文禁止脚本签到，封号风险自担，别为了几个积分把主力账号搭进去。进阶用法二：NAS 自动运维，清理与备份交给它群晖用久了最常见的两件事：磁盘被 Docker 镜像、日志、缓存慢慢吃满；青龙自己的配置、脚本改了半天没备份。这两件都可以交给青龙自己干。定时清理 Docker 悬空镜像和日志，每周跑一次 Shell 脚本：#!/bin/bash # 每周清理一次悬空镜像，保留最近 7 天日志 docker image prune -f find /var/log -type f -name "*.log" -mtime +7 -delete 2>/dev/null echo "清理完成：$(date)"注意：这条脚本要在能访问 Docker 的宿主机定时任务里跑，或者把 Docker 套接字挂载进青龙容器——新手更稳妥的做法是把清理脚本放在群晖「任务计划」里，青龙只负责发提醒、记日志。别在没看懂命令的情况下直接 prune -a，会把没在运行的镜像也清掉，下次启动容器要重新拉取。定时备份青龙自身：把 /ql/data 打包一份，拷到群晖的备份目录或异地备份路径。备份方案本身可以参考本站的 3-2-1 备份思路：本地一份、快照一份、异地一份，青龙数据虽小，丢了却最麻烦——因为所有定时任务都在里面。进阶用法三：服务存活巡检，挂了第一时间知道Uptime Kuma 是专门的监控面板，青龙则适合做“轻量巡检 + 动作联动”。比如每 10 分钟 curl 一次家里的几个关键地址：博客首页、图床、NAS 的 Web Station 页面，状态码不是 200 就通过 Bark 推送告警。import requests URLS = [ "https://www.yeyhome.com/", "http://群晖内网IP:5000/", ] for url in URLS: try: r = requests.get(url, timeout=10) print(url, r.status_code) except Exception as e: print(f"告警：{url} 访问失败 {e}")把告警逻辑接上通知渠道后，巡检就从“偶尔想起来看一眼”变成了“挂了手机立刻响”。它和 Uptime Kuma 不冲突：Kuma 看得细、看板好看，青龙胜在顺手——巡检发现问题后，可以直接在同一个面板里再跑一个重启、清理脚本，形成“发现—处理”的闭环。进阶用法四：定时提醒与数据汇总还有一类活，青龙做起来比手机闹钟靠谱：每天固定时间汇总一件事，推到你面前。每天早上 8 点，把昨天各站点的签到结果汇总成一条推送；每周一，把 NAS 磁盘占用、Docker 容器状态汇总成一条周报；每月 1 号，提醒自己检查证书到期、域名续费、VPS 账单——这些事不难，难的是记得。实现方式都一样：脚本跑完把结果拼成一句话，调用 Bark 或邮件通知接口发出去。关键是只推值得看的：巡检正常时别天天推“一切正常”，只在异常或汇总节点推，否则推送一多，人就自动忽略了，等于没装。进阶用法五：脚本管理规范，别让面板变成垃圾场青龙用半年，面板里脚本一多就乱。进阶玩家的分水岭不在脚本写得多花哨，而在管理得干不干净。我的规矩是四条：命名规范：站点_用途.py，如 pt_sign.py、nas_cleanup.sh，一眼知道干什么；变量与代码分离：账号、Cookie、Webhook 地址一律放环境变量，脚本里不出现明文密钥，分享、迁移都不怕；依赖单独记：Python 脚本用到的第三方库，在青龙「依赖管理」里装好并记在脚本头部注释里，换机器重装不抓瞎；日志定期清：青龙日志默认越攒越大，定时任务里加一条每月清理旧日志的任务，别等磁盘告警才想起来。避坑清单：这几条都是实测踩过的时区先对齐：青龙容器时区默认可能是 UTC，cron 按 UTC 跑，想每天 8 点跑却 16 点才跑，先检查容器时区和群晖时区是否一致；别跑来路不明的脚本：网上“复制粘贴即用”的青龙脚本，先看它读了哪些变量、往外发了什么请求，再决定跑不跑；要你填账号密码的脚本，先确认它发到哪里；失败要通知：定时任务只设成功路径等于没设，脚本里把异常分支也接上通知，跑失败了你得知道；先手动跑一次：任何新任务上线前，先手动运行一次、看日志、确认输出，再交给定时。直接上定时，出问题都不知道是哪天开始坏的；别用青龙干重活：转码、压缩、大文件同步这类吃 CPU 和 IO 的活，交给群晖任务计划或专门工具，青龙只做轻量调度。怎么卸载：干净收尾哪天不想用了，卸载分两步：先停容器、删容器，再决定数据卷留不留。docker compose down # 数据也不要了，再加 -v： # docker compose down -v只 down 不加 -v，数据卷还在，以后重新 up 还能恢复；确认彻底不用，再加 -v 连数据一起清掉。卸载前如果脚本里有自己写的通用工具，先导出一份存到群晖的文档目录，别跟着容器一起删了。结语青龙的价值不在它能跑多少脚本，而在它把“每天、每周、每月都要做一次的小事”从你的脑子里接过去。PT 签到只是入门，从签到聚合、NAS 运维、服务巡检到定时汇总，一台群晖 + 一个青龙，就能搭起一套不用人盯着的家庭自动化小中枢。先从一个巡检任务开始跑通，跑稳了再往上加，别一次塞十个脚本——自动化最怕的不是少，而是乱。相关旧文：青龙面板 PT 站点自动签到脚本Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好

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 三种内网穿透实测对比：延迟、成本、稳定性怎么选

Immich 自建相册实测：能不能替代群晖 Photos Immich 自建相册实测：能不能替代群晖 Photos家里群晖 NAS 用了几年，Photos 里的照片从几千涨到了几万张。最近家人开始抱怨：手机备份经常漏、找人脸照片要翻半天、AI 识别的准度也不太行。趁这个机会，我在群晖上用 Docker 部署了开源的 Immich，实测跑了两周——这篇就说说它能不能替代群晖 Photos、部署过程和从 Photos 迁移过来的成本。先说结论：Immich 是干什么用的Immich 是一个开源的自托管照片/视频备份方案，号称"Google Photos 自建版"。它和群晖 Photos 最大的区别有三点：多端备份更主动：iOS / Android 客户端有真正的后台备份，定时任务、仅 Wi-Fi、仅充电等策略都有；AI 能力更强：内置人脸识别、语义搜索（比如搜"海边""狗"直接出图）、地图时间线，用的都是本地模型，不上传云端；权限更开放：支持多用户、共享相册、相册链接分享，API 完善，第三方客户端和插件多。如果你只是要一个"NAS 上存照片"的地方，群晖 Photos 够用了。但如果你要的是全家人手机自动备份 + 能按人脸/场景快速找回，Immich 值得一试。Docker 一键部署：群晖 Container Manager 实战Immich 官方提供 docker-compose 部署，一共 4 个核心容器：服务端（server）、PostgreSQL 数据库、Redis、机器学习服务（machine-learning）。群晖 DSM 7.2 的 Container Manager 直接支持 compose 项目，步骤如下：第 1 步：准备共享文件夹在 File Station 建两个共享文件夹（或同一文件夹下的子目录）：/docker/immich —— 放配置文件和数据库数据/volume1/photo/immich-library —— 放真正的照片库（建议和 Photos 用同一个 volume 但不同目录，方便迁移对比）第 2 步：写 compose 文件去 Immich 官网 release 页下载官方的 docker-compose.yml 和 .env 模板（官网有完整文档，本文用当时最新版 v1.1xx）。核心配置注意这几项：services: immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} volumes: - ${UPLOAD_LOCATION}:/data # 照片实际存储路径 - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - 2283:2283 depends_on: - redis - database restart: always.env 里关键的几项：UPLOAD_LOCATION=/volume1/photo/immich-library DB_PASSWORD=改一个强密码 IMMICH_VERSION=release第 3 步：Container Manager 建项目Container Manager → 项目 → 新增 → 输入项目名称 immich，把 compose 文件内容粘贴进去，建好后启动。第一次启动会拉 4 个镜像，大约 2~3 GB，群晖的千兆内网一般几分钟拉完。启动成功后浏览器打开 http://群晖IP:2283，先注册管理员账号（第一个注册的就是管理员），然后就可以建用户、装手机 App 扫码登录了。第 4 步：挂载已有照片目录如果你 NAS 上已经有整理好的照片目录（比如 Photos 的备份文件夹），可以直接把目录映射进容器，然后在后台"外部库（External Libraries）"里添加，Immich 会扫描入库，不复制文件。这是我从 Photos 迁移时最省事的一步，下面迁移部分细说。两周实测：和群晖 Photos 对比体验我拿了同一批约 1.2 万张照片 + 800 个视频做对比，结论先行：对比项群晖 PhotosImmich手机自动备份iOS 后台经常被杀，需手动打开后台备份稳定，可设仅 Wi-Fi / 仅充电人脸识别有，但合并/纠错麻烦人脸聚类 + 手动命名，准确率明显更高语义搜索基本没有"日落""猫"这类词直接搜，中文关键词可用分享共享空间/相册相册链接分享 + 密码 + 有效期，更灵活多用户需 DSM 账号体系独立用户体系，家人不用给 DSM 账号资源占用轻较重，AI 识别时 CPU 会跑满一阵几个实测细节：备份可靠性：iPhone 上 Immich 的后台备份两周零漏传；Photos 之前平均每周漏 2~3 天，得手动点开 App 触发。这对"给爸妈备份"这个场景是决定性差距。人脸识别速度：DS920+ 上 1.2 万张照片的初始识别跑了约 6 小时（CPU 满载），之后增量识别无感。识别准度上，同一人的不同年龄段照片基本能聚到一起，Photos 那边我手动合并了几十次。视频回放：Immich 默认会转码生成预览，手机端滑动时间线很跟手；原画质点开即看。HEVC 视频在部分旧安卓机上需要转码，NAS CPU 弱的话会有点卡。搜索体验：搜"身份证""发票"这种文档类照片，Immich 的 OCR + 语义搜索基本能命中，Photos 只能靠文件名和时间。避坑：部署前必须知道的 5 件事内存至少 4GB 可用：machine-learning 容器吃内存，2GB 内存的入门 NAS（如 DS220j 这类）别折腾，会卡到怀疑人生。DS920+ / DS923+ 这种 4GB 起步的没问题。数据库密码别用特殊字符：DB_PASSWORD 里如果有 # ! 这类字符，compose 解析可能出问题，用纯字母数字最稳。照片目录权限：容器内默认用 UID 1000 读写，群晖上给共享文件夹的读写权限时，注意勾选"应用到子文件夹"。权限不对的表现是上传 0 字节文件。版本升级别追 latest 太快：Immich 迭代快，偶尔有 breaking change。生产库建议锁 IMMICH_VERSION 为具体版本号，升级前先看 release notes，有数据库迁移的一定先备份。备份 Immich 的数据库：照片文件在 /data 里好备份，但人脸标注、相册关系都在 PostgreSQL 里。定期用 pg_dump 导出一份，或者把 database 容器的数据卷纳入 Hyper Backup。从 Photos 迁移过来，成本有多大这是大家最关心的。我实测的迁移路径：照片文件：Photos 的照片实际存在 /photo 下（按时间分目录），直接把该目录映射为 Immich 的外部库，扫描入库，零复制、零耗时（除了 AI 识别那几小时）。相册关系：Photos 里的相册不会自动过来。我的做法是：重要的家庭相册（大概 30 个）在 Immich 里重建，用"按条件筛选 + 批量加入"的方式，两个人一下午搞定。不重要的相册直接放弃——迁移是个断舍离的好机会。人脸标注：Photos 的人脸数据导不出来，Immich 要重新识别。这是最大的一次性成本，但识别完准度更高，算值得。分享链接：Photos 的旧分享链接会失效，提前通知家人换新链接。总成本：一下午的人工 + 一晚上 AI 识别的电。迁移完我把 Photos 保留为"冷备份"，Immich 作为日常主力。怎么卸载：不喜欢就干净撤走Immich 是纯 Docker 部署，卸载非常干净：Container Manager 里停止并删除 immich 项目（勾选"同时删除容器"）；删掉 /docker/immich 配置目录（数据库数据在这里）；照片库目录 /volume1/photo/immich-library 如果是外部库映射的，不要删，那是你的原照片；手机 App 卸载即可。整个过程不碰 DSM 系统，Photos 的数据完全不受影响，可以随时回滚。这也是我敢拿主力照片库做实测的原因。总结：谁适合换，谁没必要适合换：家人多、手机备份老是漏、人脸/场景搜索是刚需、NAS 内存 4GB 以上。没必要换：就自己一个人用、照片量不大、Photos 用得挺顺手、NAS 是入门款。我自己的选择：Immich 主力 + Photos 冷备份，两条腿走路。毕竟照片这东西，丢一次的教训比什么都贵。相关旧文群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好 —— Immich 的数据库记得纳入备份计划Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 —— 容器管理更顺手Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解 —— 顺手监控下 NAS 负载

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 容器

Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实测 Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实测密码这东西，越攒越多：网站账号、服务器 SSH、路由器后台、摄像头 NVR、各种 App……浏览器自带的密码管理器换台电脑就抓瞎，1Password、Bitwarden 官方云要么收费、要么数据在别人手里。我的解法是：在群晖 NAS 上用 Docker 跑 Vaultwarden——Bitwarden 服务器的轻量开源实现，几十 MB 内存就能跑，手机 App、浏览器插件、桌面客户端全兼容官方 Bitwarden 协议，数据完完全全在自己手里。一、Vaultwarden 是干什么用的一句话：自建的 Bitwarden 服务器。Bitwarden 是开源密码管理器，官方提供云服务；Vaultwarden 用 Rust 重写了服务端 API，功能对齐官方（密码库、TOTP、组织共享、附件、应急访问），但资源占用极低，树莓派、群晖这种小机器都能轻松跑。为什么值得折腾：数据自主：密码库存在自家 NAS 的硬盘上，不经过第三方服务器。全端同步：官方 Bitwarden 客户端（iOS / Android / Windows / macOS / 浏览器插件）直接连自建地址登录，自动同步。离线可用：客户端有本地加密缓存，断网也能查密码。免费：核心功能全开，不用订阅。二、Docker 一键部署（群晖 DSM 7.2）群晖 Container Manager 里用「项目」（docker compose）部署最省事。先在 docker 共享文件夹下建好目录，比如 /volume1/docker/vaultwarden。compose 文件如下：services: vaultwarden: image: vaultwarden/server:latest container_name: vaultwarden restart: unless-stopped environment: - DOMAIN=https://vw.example.com # 改成你自己的域名 - SIGNUPS_ALLOWED=true # 先允许注册，建好账号后改成 false - ADMIN_TOKEN=换成一串强随机口令 # 后台管理 /admin 用 volumes: - /volume1/docker/vaultwarden:/data ports: - "127.0.0.1:8080:80"部署步骤：Container Manager → 项目 → 新增 → 项目名称填 vaultwarden，路径选 docker/vaultwarden，把上面 compose 内容粘进去，点「下一步」建好并启动。容器跑起来后先别急着暴露公网——Bitwarden 客户端强制要求 HTTPS，纯 http 直连会报安全错误。去 DSM「登录门户 → 高级 → 反向代理服务器」加一条规则：来源 https://vw.example.com，目的地 http://localhost:8080，并配好 Let's Encrypt 证书。浏览器打开 https://vw.example.com，注册你的管理员账号，然后立刻把 SIGNUPS_ALLOWED 改成 false 并重建容器——公开注册的密码库等于给全网开了个保险柜门，这一步不能忘。访问 https://vw.example.com/admin，用 ADMIN_TOKEN 进后台，可以看到用户、组织与配置一览。到这一步服务端就绪。整个链路是：群晖 Docker 跑 Vaultwarden 容器 → DSM 反向代理做 HTTPS 统一入口 → 手机、电脑、浏览器各端连同一个域名同步。三、多端同步实测网页端：浏览器直接打开域名登录，就是完整的密码库管理界面，新增、编辑、搜索、生成强密码都在这。手机端：装官方 Bitwarden App，登录时点齿轮把「自托管」服务器地址填成你的域名，登录后密码库秒同步。实测：手机上新增一条 NAS 登录，电脑端刷新即出现。浏览器插件：Chrome / Edge 装 Bitwarden 插件，同样填自托管地址，登录表单自动填充，体验和官方云无差别。离线：手机开飞行模式，已同步过的密码照样能查——客户端本地有加密缓存。另外 TOTP（一次性验证码）也能直接存在条目里，扫码登录网站时自动填充验证码，手机上可以少装一个验证器 App。四、避坑指南必须 HTTPS：客户端依赖 Web Crypto，纯 http 下网页版直接报错，这是新手翻车最多的地方。注册完立刻关闭公开注册：SIGNUPS_ALLOWED=false，否则任何人都能在你的服务器上注册账号。ADMIN_TOKEN 用强口令：/admin 后台能管理所有用户，别用弱口令。备份 /data 目录：密码库本质是个 SQLite 文件，用 Hyper Backup 把 docker/vaultwarden 目录定时备份一份。丢了就是真丢了——没有官方客服能帮你找回。端口别直接映射公网：上面 compose 绑的是 127.0.0.1:8080，只走 DSM 反向代理；需要外网访问就走你已有的内网穿透方案。升级：Container Manager 里拉取最新的 vaultwarden/server 镜像后重建容器即可，数据都在映射卷里，不会丢。五、怎么卸载不想要了也很干净：Container Manager 里停止并删除 vaultwarden 项目和容器，删除 vaultwarden/server 镜像，最后删掉 /volume1/docker/vaultwarden 数据目录——密码数据彻底清除。各客户端退出登录并清除本地缓存即可。删数据目录前先确认已导出备份（网页端 → 工具 → 导出密码库，建议选加密 json），别手滑。自建密码库这件事，门槛就是一台 NAS 加十分钟。数据回到自己手里之后，换设备、重装系统再也不用为密码发愁了。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选 —— 自建服务要从外网访问，穿透方案看这篇选型群晖 Docker 容器升级失败怎么办：备份、回滚与日志排查完整指南 —— 容器升级翻车时的标准处理流程

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

RustDesk 开源远程桌面：Docker 自建中继服务器，免费告别 TeamViewer 做弱电、安防、智能化工程的朋友都有体会：项目现场的电脑、客户家的录像机、小区门禁主机，动不动就需要远程过去看一眼、调一下。TeamViewer 免费版动不动就判定"疑似商业用途"强制断连，向日葵免费版限速又限设备数量，关键时刻掉链子最让人头疼。今天分享一款开源免费的远程桌面工具 —— RustDesk，自己动手搭一套中继服务器，速度、稳定、隐私全都掌握在自己手里。RustDesk 是什么RustDesk 是 GitHub 上的开源远程桌面软件，star 数常年霸榜远程工具分类，核心特点一句话概括：TeamViewer 能干的它都能干，还不收费、不弹窗、不限制。完全开源免费：个人用、商用都不收费，没有"疑似商业用途"警告；跨平台：Windows、macOS、Linux、Android、iOS 全支持，手机也能远程控制电脑；端到端加密：连接默认加密，数据不经过第三方也能放心用；无需注册：装好就有 ID，输入对方 ID 和密码即可连接；支持自建服务器：官方提供 hbbs（ID 服务器）/ hbbr（中继服务器）Docker 镜像，搭好之后所有流量走自己的机器。快速上手：三分钟连上第一台电脑打开官网 rustdesk.com，下载对应平台的客户端。Windows 用户可以直接下载免安装的 exe 版，双击即用；两台电脑都打开 RustDesk，软件左侧会显示本机 ID（一串数字）和一次性密码；在控制端输入被控端的 ID，点击"连接"，输入密码，搞定。默认的临时密码每次重启软件会变化，适合临时远程协助亲戚朋友处理电脑问题。无人值守：固定密码 + 开机自启要实现随时随地远程家里的电脑、办公室的工控机或者项目现场的调试机，需要多做两步设置：在被控端打开「设置 → 安全」，勾选"启用密码"并设置一个固定密码；Windows 上把 RustDesk 安装为系统服务实现开机自启：设置里点击"安装"按钮即可；Linux/macOS 可通过系统自启动项实现。设置完成后，在外网输入 ID + 固定密码，就能随时连回家里的机器，相当于给自己搭了个 7×24 小时在线的"云电脑"。进阶玩法：Docker 自建中继服务器默认情况下 RustDesk 走官方的公共中继服务器，速度全看运气，高峰期卡顿是常事。想稳定、想保护隐私，自己搭一套中继只需要一台有公网 IP 的 VPS；如果家里宽带是公网 IP，群晖 NAS 上跑 Docker 也一样能搭。官方镜像 rustdesk/rustdesk-server，用 docker-compose 一把梭：services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server command: hbbs -r 你的服务器公网IP或域名:21117 volumes: - ./data:/root network_mode: "host" restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server command: hbbr volumes: - ./data:/root network_mode: "host" restart: unless-stopped把 你的服务器公网IP或域名 换成自己的 VPS 公网 IP 或解析好的域名，然后 docker compose up -d 启动。端口放行：需要在服务器防火墙/安全组放行以下端口 —— 21115（TCP）、21116（TCP/UDP）、21117（TCP）、21118（TCP）、21119（TCP）。启动成功后，在 ./data 目录下会生成 id_ed25519.pub 文件，把里面的字符串内容复制下来，这就是客户端接入时需要的 Key，妥善保存。客户端接入自建服务器在每一台设备的 RustDesk「设置 → 网络 → ID 服务器」中填入：ID 服务器：你的服务器IP或域名:21116中继服务器：你的服务器IP或域名:21117Key：id_ed25519.pub 文件里的完整内容填完后重启客户端，左下角状态栏显示"就绪"即表示接入成功。之后所有连接都走自己的服务器，流畅度取决于你的 VPS 带宽，一般 5~10Mbps 的上下行就足够日常办公和运维操作。几个实用小技巧文件传输：连接成功后顶部工具栏有文件传输按钮，支持双向传文件，现场拷日志、传固件很方便；TCP 打洞直连：两端网络条件允许时会尝试 P2P 直连，延迟最低；隐私模式：被控端开启后远程时本地黑屏防偷窥（Windows 需要安装版）；TCP 隧道：可以把远端内网的某个端口映射到本地，比如直接在浏览器打开远端群晖 DSM 管理页面、摄像头后台。写在最后RustDesk + 自建中继这套组合，成本就是一台小 VPS，换来的是完全不受限的远程桌面：修电脑、看监控、调设备、帮亲戚处理"电脑又蓝屏了"，一个 ID 全搞定。开源意味着没有厂商锁定，哪天不想用了，数据和服务器都在自己手里。如果你也在用 RustDesk，或者有更好用的远程方案，欢迎在评论区交流。

Lucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案 背景群晖 NAS IP：192.168.2.108Lucky：部署在群晖 Docker 中，使用 host 网络模式宝塔面板：部署在群晖 Docker 中，使用 macvlan 网络模式，独立 IP 192.168.2.109目标：通过 Lucky 反代宝塔面板问题描述在 Lucky 中配置反代地址为 http://192.168.2.109:8888/ 后，访问报错：proxy url [http://192.168.2.109:8888/] err: dial tcp 192.168.2.109:8888: connect: no route to host原因分析macvlan 网络模式有一个特性：容器与宿主机之间网络是隔离的，宿主机无法直接访问 macvlan 容器，反之亦然。虽然 Lucky 使用的是 host 模式（直接使用宿主机网络），但 macvlan 容器对宿主机同样不可达，因此访问 192.168.2.109 会直接失败。解决方案：为宝塔容器添加 bridge 双网络让宝塔容器同时连接两个网络：网络驱动用途bridge-hostmacvlan保留宝塔独立 IP 192.168.2.109bridgebridge与 Lucky（host 模式）通信，用于反代操作步骤1. 在群晖 Docker 界面添加 bridge 网络打开群晖 Docker → 左侧菜单 网络，可以看到当前所有网络列表：找到 bridge 网络，点击 管理 → 新增，在容器名称下拉框中选择 baota，点击 应用：2. 确认双网络配置成功操作完成后，在宝塔容器详情 → 网络 标签页中可以看到：网络名称驱动程序bridgebridgebridge-hostmacvlan3. 查询宝塔在 bridge 网络中的 IPSSH 登录群晖，执行：docker inspect baota | grep '"IPAddress"'输出示例："IPAddress": "172.17.0.14", "IPAddress": "192.168.2.109",其中：172.17.0.14 → bridge 网络 IP（用于 Lucky 反代）192.168.2.109 → macvlan 独立 IP（对外访问保留）4. 配置 Lucky 反代在 Lucky 反代设置中，将目标地址改为：http://172.17.0.14:8888保存后即可正常反代宝塔面板。总结方案优点缺点宝塔改为 host 模式简单直接失去独立 IPmacvlan + bridge 双网络保留独立 IP，同时支持反代需额外配置最终采用双网络方案，既保留了宝塔的独立 IP 192.168.2.109，又通过 bridge 网络实现了 Lucky 的正常反代，两全其美。