飞牛玩家注意了，应用中心Lucky已下架。别担心，已安排docker版安装及数据迁移教程
摘要
Lucky应用中心下架后，用户需先备份配置，卸载旧版v2.27，再通过Docker Compose安装最新版v3。最后还原备份文件即可恢复使用，确保DDNS和内网穿透功能持续运行。
前言
用飞牛（fnOS）的朋友要注意了：应用中心的 Lucky 已经下架。目前已经装了的暂时还能用，但作者已不再通过应用中心更新。
Lucky 对很多 NAS 玩家来说是必备的网关工具：一键 DDNS、自动申请 SSL 证书、内网服务转发都靠它，把域名访问串了起来。正因为它承担的角色重要，保持版本更新、别停在旧版还是很有必要的——新版本往往带安全修复和新特性。好在 Lucky 的 Docker 版安装、以及从应用中心到 Docker 的数据迁移都非常方便，花几分钟就能无缝切换，今天就把完整流程记下来。
先说清楚：为什么"下架"这件事值得立刻处理
Lucky 不是一个小插件，它在你家里的网络里扮演的是网关角色——外网访问你家所有服务的入口都经过它。这意味着：
它负责的事 | 一旦停更的风险 |
|---|---|
DDNS 动态解析 | 运营商换 IP 后解析不更新，家里服务外网失联 |
SSL 证书申请与续期 | 证书到期后浏览器报警、部分 App 直接拒连 |
反向代理 / 转发 | 所有走域名的服务全部中断 |
这三件事的共同点是"出问题时你才知道它重要"。 尤其 SSL 证书是有有效期的——应用中心版的 Lucky 停更之后，你面临的是"证书续期能力"被冻结。运气好能续到证书过期那天，运气不好中途 ACME 协议或签发放行变更，直接续不动。
同时也别慌：Lucky 项目本身还在活跃更新，只是不再通过飞牛应用中心分发。源码和 Docker 镜像都正常，所以这不是"项目要凉了"，而是分发渠道变了——你要做的只是换个安装方式。
有个概念值得记住：应用中心的版本更新，取决于"打包者"是否跟进。它跟第三方商店一样，是"有人把上游的东西打包适配你的系统"——上游发了新版，打包者没跟进，你在商店里就只能停在旧版。这也是为什么稍微进阶一点的玩法，都会尽量用官方 Docker 镜像：镜像由作者自己维护，新版本发布即可
pull，不依赖任何中间人。
第一步：备份数据
迁移前最重要的就是先备份配置，否则之前配好的 DDNS、转发规则、证书全得重来。
打开 Lucky 的 Web 页面，进左边栏的设置，点击备份配置，把生成的备份文件保存到电脑上。
备份完成后，就可以到应用中心把旧版 Lucky（当前是 2.27）删除了。
⚠️ 顺序不能反，"先备份再卸载"是这一整篇里最不能省的一步。
原因很直接：卸载旧版之后，那些配置就只存在于那个备份文件里了。DDNS 的域名和密钥、反代规则、证书配置——这些通常需要半小时到一个小时才能重新配好，而且很多密钥类的信息（比如 DNS 服务商的 API Token）你不一定还留着，可能得重新去申请。
另外强烈建议把备份文件多存一份到 NAS 之外的地方（电脑 + 网盘/邮箱）。你的 NAS 正是那台需要用 Lucky 才能从外网访问的机器——如果备份只存在 NAS 上，而你迁移失败又需要重装，就会出现"要找的东西锁在要修的门里面"这种尴尬。 我自己还会保留一份配置的文字记录（改了哪些端口、挂了哪些域名），这是最便宜的保险。
第二步：通过 docker compose 安装最新版
最新版的 Lucky 已经升级到 v3 了，用 docker compose 部署到飞牛上：
几个要点：
用
host网络模式，能让 Lucky 直接看到宿主机的所有端口，DDNS / 转发调度更省心；挂载了
docker.sock，便于 Lucky 管理和联动其它容器；配置目录
/vol1/1000/docker/lucky/conf要确保可写、持久化。
在飞牛 Docker 里新建一个 Compose 项目，把上面的配置粘进去并启动。
⚠️ 这两行配置背后各有一个安全取舍，值得知道再决定要不要留：
1. 挂载
/var/run/docker.sock等于把整台 NAS 的控制权交给这个容器。 这不是夸张——Docker 的套接字就是管理接口，能通过它操作所有容器：创建、删除、读写、挂载宿主机任意目录。也就是说 Lucky 容器一旦被攻破（或者镜像本身出问题），攻击者拿到的不是"一个容器"，而是整台机器。所以：如果你不需要 Lucky 的容器管理功能，建议把这一行注释掉。缺了它，Lucky 的 DDNS、证书、反代这些核心功能照样正常——它只是个"顺便管理容器"的扩展能力。家庭网关这种东西，权限越小越好。
2.
network_mode: host下，下面的ports其实是不生效的（写了也无妨，但别指望靠它改端口）。 原因是 host 模式让容器直接共用宿主机的网络，不再有独立的网络命名空间，也就没有"端口映射"这回事。Lucky 实际监听什么端口，取决于它自己的配置（v3 默认 Web 后台是 16601），你去改 compose 里的ports是改不动的——如果想换端口，得进 Lucky 设置里改。这也解释了一个常见困惑："我明明把端口改了，怎么还是 16601？"——因为 host 模式下那个映射本身就没参与工作。
第三步：恢复备份数据
容器起来后，浏览器访问 http://你的飞牛IP:16601 打开 Web 页面——这次跑的就是最新版 Lucky v3 了。
点击还原配置，选择第一步导出的备份文件。
应用会自动重启一次，之后重新登录，你之前配好的 DDNS、反代规则、SSL 证书等就都回来了，无缝恢复使用。
如果你还不会用 Lucky，可以先看我之前的文章，有完整的基础教程：使用 lucky 插件，通过 ipv6 访问本地服务器。另外如果你想用 Lucky 给内网服务加一层 WAF 和 IP 过滤，可以看这篇：使用 Lucky 保护你的飞牛，开启 WAF 防火墙，设置 IP 过滤。
小结
整体迁移流程归纳为三步：备份配置 → Docker 部署 v3 → 还原备份。
关键提醒：
务必先备份再卸载，丢了配置从头配很痛苦；
用 Docker 版之后，Lucky 就不再依赖应用中心，以后作者发新版本，自己
docker compose pull && up -d升级即可，比应用中心更自由可控；迁移完成后留意 DDNS 是否正常更新、各转发规则是否还指向正确，确认无异常再放心使用。
第 2 点值得展开一下——它其实是这次迁移最大的收获。 从"应用中心版"换成"Docker 版"之后，你获得的是跟上游同步的能力：
Shell这两条命令 = 拉取作者发布的最新镜像 + 用新镜像重建容器。版本更新从此不依赖任何中间人，作者发版你就能用上。这也是我在 NAS 上一条通用的偏好：能自己维护的容器，就别依赖商店分发——商店方便一时，但会把你锁在别人的更新节奏上。
一些补充
v3 相比 v2 的变化：界面和底层都有升级，入口仍是 Web 后台（默认 16601 端口）。如果你在 v2 里用了某些偏门特性，还原后可以先在"设置"里检查一遍开关状态，个别选项的默认值可能不同。
不要同时跑两套：迁移完成后，确认旧版容器/应用中心里已经没有仍在运行的 Lucky，避免两个实例抢 16601 端口或重复执行 DDNS，造成解析冲突。
迁移后验证：推荐在非工作时段做迁移，完成后用手机 4G/5G（脱离内网）访问一次你的 DDNS 域名，确认外网入口依然畅通——这是最有效的"迁移成功"检验。
对一直在用 Lucky 做 DDNS / 反代的飞牛玩家来说，这是一次必要且顺利的"搬家"，动手做一遍就再也不用担心被下架卡住更新了。
常见问题
Q：迁移后 DDNS 不更新了，怎么办？
先确认是不是有两个实例在跑——旧版和 Docker 版同时运行是最常见的原因，两个进程争同一条域名解析记录，结果就是解析乱跳或长期不更新。彻底停掉旧版（不只是停服务，要把应用中心里的旧版本删干净），再观察一轮。
Q：DDNS 正常，但域名访问打不开？
按这个顺序查：① 反代规则有没有还原成功（v3 里逐条看一下目标地址和端口）；② 证书是否已加载（Windows 上可以点浏览器地址栏的锁图标看证书签发时间，如果还是旧证书，说明续期/加载有问题）；③ 防火墙端口是否放行（换版本后如果有新监听的端口，路由器那边得跟着放行）。
Q：升级会不会导致配置丢失？
正常的 docker compose pull && up -d 不会——配置存在你挂载出来的 conf 目录里，重建容器不影响它。但升级前顺手导出一份配置备份是个好习惯：万一新版本有兼容性变更，你至少能回退到能用状态。
Q：能回退到应用中心的旧版本吗？
技术上可以（重新从应用中心装，或者直接跑旧版镜像），但没太大必要——应用中心版本来就是停更的那一版，回退等于把自己重新锁在旧版本上。真遇到 v3 的问题，更合理的做法是用 Docker 的方式跑一个 v2 版本的镜像，这样既回到了熟悉的版本，也保留了自主升级的能力。