Docker 部署 Lucky：公网转发、DDNS 与反向代理
家里的宽带有公网 IPv6，NAS 或旧路由器里的服务却只监听 IPv4；或者你希望把多个内网服务放到同一个域名入口，并自动更新 DNS。Lucky 把端口转发、反向代理、DDNS、WOL、STUN、ACME 和网络存储放在一个管理后台里，适合把一台软路由、旁路由或 Linux 小主机变成可持续维护的网络服务节点。
下面采用官方文档当前推荐的 gdy666/lucky:v2 镜像，在 Linux 上使用 host 网络并把配置目录挂载到宿主机。读者会先完成一次可访问的后台启动，再配置一条转发规则，最后处理密码、安全入口、备份和升级。v2 是浮动系列标签，适合跟随 Lucky 的 Docker 发布路径；需要严格复现时，应在拉取后记录镜像 digest。
项目来源与版本信息
| 信息 | 内容 |
|---|---|
| 项目标题 | Lucky（万吉） |
| 项目描述 | 软硬路由公网工具，支持 IPv6/IPv4 端口转发、反向代理、DDNS、WOL、STUN、计划任务、ACME 和网络存储等功能。 |
| GitHub 仓库 | gdy666/lucky |
| 官网地址 | lucky666.cn |
| 主要开发语言 | Go 99.96%、Shell 0.03%、Dockerfile 0.01% |
| 开源许可证 | MIT |
| 最近代码更新 | 2026-02-15（GitHub pushed_at，核对日期：2026-10-10） |
先判断网络模式
Lucky 的 Docker 使用方式取决于你是否需要直接处理主机的 IPv6 和多个监听端口。官方安装文档把 Linux 的 host 模式作为优先路径：容器与主机共用网络栈，Lucky 可以同时使用 IPv4 和 IPv6，命令里不需要写 -p。bridge 模式通过端口映射隔离网络，只适合明确的 IPv4 场景；官方还提醒 Linux 上不推荐 bridge，Windows 使用 Docker 版也不推荐。
| 场景 | 建议 | 关键差异 |
|---|---|---|
| Linux 软路由、旁路由、NAS，需要 IPv6 转发 | --net=host | 容器直接使用主机网络，端口冲突由主机负责排查 |
| Mac/Windows 开发机，只验证后台或 IPv4 | -p 16601:16601 | 只映射 IPv4；Docker Desktop 的网络与真实路由器环境不同 |
| 需要长期运行 | 宿主机目录挂载到 /app/conf | 删除容器后配置仍在宿主机；目录本身需要备份 |
| 只想短暂试用 | 不挂载配置目录 | 容器删除会丢失容器内配置，不适合本文的维护路径 |
本文主路径以 Linux 和 host 模式为准。Docker 镜像是官方文档所说的“万吉”全能版，GitHub 仓库主要发布 Lucky，配置文件通用；这不代表每个发布版本都拥有相同的镜像内容。固定提交中的历史 Dockerfile 曾把配置放在 /goodluck，而当前文档明确要求 v2.23.1 及以上使用 /app/conf，两者不要混在同一个新容器命令里。
Lucky 能做什么
Lucky 的价值在于把网络入口和内网服务之间的几步工作集中起来。每个模块都对应一类可以观察到的结果：
- 端口转发：把公网 IPv6 的 TCP/UDP 端口转发到只提供 IPv4 的内网主机，适合访问家庭 NAS、游戏服务或旧设备；后台会保存规则并提供访问日志。
- 反向代理与证书：为多个 Web 服务按域名或路径分流，可配合 ACME 自动申请证书，减少为每个内网应用单独开放端口的需要。
- DDNS 与计划任务：把动态公网地址同步给 DNS 服务商，并按计划开关转发规则或执行维护动作。
- WOL、STUN 与网络存储：从后台唤醒局域网设备，处理部分内网穿透需求，或通过 FTP、WebDAV、File Browser、rclone 等模块访问网络存储。
这套组合更适合已经知道自己要暴露哪一个服务、哪个端口和哪一类地址的网络使用者。Lucky 的后台能简化配置，但不会替你判断某个内网服务是否安全，也不会自动让运营商提供公网 IPv6；没有公网地址时，应先确认 STUN、端口转发或其他网络条件是否真的可用。
启动一个持久化实例
主机需要安装 Docker Engine，能使用 Bash 或兼容的 shell，并准备一个只供 Lucky 使用的配置目录。本文不启动容器，以下命令来自官方 Docker 路径；执行后请按“验证后台”中的 HTTP 检查观察结果。
创建配置目录并拉取镜像
mkdir -p "$HOME/lucky-conf"
chmod 700 "$HOME/lucky-conf"
docker pull gdy666/lucky:v2
docker image inspect gdy666/lucky:v2 \
--format '{{.Id}} {{join .RepoDigests ","}}'docker image inspect 能帮助你记录当前镜像的本地 ID 和 digest。v2 标签会随着官方镜像更新，若输出中没有 RepoDigest，也不要把本地 ID 当成跨机器可复现的镜像地址；可以在你的镜像仓库或发布记录中保存这次拉取的版本信息。
用 host 网络启动
docker run -d \
--name lucky \
--restart=always \
--net=host \
-v "$HOME/lucky-conf:/app/conf" \
gdy666/lucky:v2官方文档使用相同的镜像、容器名、重启策略、host 网络和 /app/conf 挂载。host 模式下 Lucky 默认在主机的 16601 端口提供后台，不能再追加 -p 16601:16601；如果主机已有服务占用该端口，容器会启动失败或后台无法访问，应先停用冲突服务或在 Lucky 设置中修改后台端口。
验证后台
docker ps --filter name=lucky
docker logs --tail=80 lucky
curl --fail --head http://127.0.0.1:16601/成功信号是容器状态为 Up，日志没有立即退出或配置解析错误，HTTP 请求收到响应。浏览器访问 http://主机IP:16601，首次登录使用官方文档给出的默认账号和密码：666 / 666。这组凭据只能用于第一次进入后台，不能保留在公网服务上。
如果使用 bridge 模式，在 Mac/Windows 或只需要 IPv4 的测试环境中可以改成：
docker run -d \
--name lucky \
--restart=always \
-p 16601:16601 \
-v "$HOME/lucky-conf:/app/conf" \
gdy666/lucky:v2bridge 模式只映射 IPv4，且不能替代真实路由器上的 IPv6 转发测试。Linux 主机遇到端口访问异常时，先切回 host 模式；不要同时保留两个同名容器。
第一次登录先收紧入口
Lucky 从 v2.13.9 起默认关闭外网访问开关，但初始化配置后的短时间存在例外；如果没有修改默认账号密码或设置安全入口，后台也会限制部分功能。第一次登录后立即完成以下动作：
- 在设置页修改用户名和密码，使用密码管理器保存新凭据。
- 设置复杂的后台安全入口。安全入口相当于管理面 URL 的额外路径，例如
https://example.net/<你的入口>；不要使用666、端口号或域名作为入口。 - 确认外网访问开关只对确有需要的网络接口开放；不需要公网管理时，把后台限制在内网或防火墙允许的地址范围。
- 配置 HTTPS 或把 Lucky 放在已经完成 TLS 和身份认证的反向代理后面。不要把带默认凭据的 HTTP 后台直接暴露到互联网。
- 在后台设置页导出配置备份，并在每次升级前重新备份。
安全入口变化后，直接访问 http://主机IP:16601 可能不再显示登录页，这是预期行为；应使用包含入口路径的地址。若丢失入口或账号密码，先停止容器并保留配置目录，再按照官方启动参数和备份恢复说明处理，不要直接删除配置文件。
配置一条 IPv6 到 IPv4 的端口转发
假设公网侧有一个 IPv6 地址，内网 NAS 的 IPv4 地址为 192.168.1.20，NAS 的 Web 服务监听 8080。在 Lucky 后台进入端口转发模块，新增一条 TCP 规则：
- 监听地址选择主机可用的公网 IPv6 接口，监听端口填写一个未占用的公网端口，例如
18080。 - 转发目标填写
192.168.1.20:8080，协议选择 TCP。 - 如果还要转发 DNS、游戏或其他 UDP 服务，单独创建 UDP 规则并确认目标服务确实监听 UDP。
- 先保持规则关闭，确认内网服务只在预期的网卡和端口监听，再开启规则。
从不在同一局域网的网络发起测试，例如使用手机蜂窝网络访问：
curl -g --fail "http://[你的公网IPv6地址]:18080/"能够返回 NAS 的 HTTP 响应，且 Lucky 访问日志出现对应记录，说明转发链路至少已经到达目标服务。若失败，按“公网 IPv6 是否可达、主机防火墙是否放行 18080、Lucky 规则是否开启、目标主机是否监听 8080”的顺序排查；局域网内用同一个公网地址测试，可能受路由器回流策略影响，不能代替外部网络验收。
如果你的内网网段不在 Lucky 的默认识别范围内，可以在宿主机配置目录创建 localips 文件，每行写一个 IP 或 CIDR 网段：
cat > "$HOME/lucky-conf/localips" <<'LOCALIPS_EOF'
192.168.1.0/24
LOCALIPS_EOF官方文档说明，localips 非空时会覆盖 Lucky 内置的默认网段；文件中的地址应覆盖你真实的内网范围，否则原本被识别为内网的地址可能不再按预期处理。修改后无需重启 Lucky，仍应通过后台日志和一次实际连接确认规则行为。
用反向代理和 DDNS 管理 Web 服务
端口转发适合明确暴露一个 TCP/UDP 服务；多个 Web 服务共用 443 端口时，反向代理更合适。在 Lucky 的反向代理模块中，为每个域名配置上游地址，例如把 drive.example.com 转到 192.168.1.20:8080，再用 ACME 模块为域名申请证书。DNS 记录必须先解析到你的公网地址，证书申请所需的 HTTP-01 或 DNS-01 条件也要按证书服务商要求准备。
DDNS 模块负责在公网地址变化后更新 DNS。创建 DDNS 任务时只给 DNS 服务商生成必要权限的 API Token，并把 Token 视为密码；不要把该 Token 写进命令行、截图、仓库或公开日志。第一次启用后检查任务日志，确认记录更新到了预期的 IPv4 或 IPv6 地址，再从外部网络访问反向代理域名。
反向代理和 DDNS 的组合把“地址经常变化”和“用户记住 IP 端口”两个问题分开了，但不改变上游应用的认证责任。后台、NAS 管理面和带写入权限的服务应继续使用应用自己的登录、访问控制和最小暴露面。
配置文件、备份和恢复
/app/conf 是当前 v2.23.1 及以上镜像的配置目录，宿主机的 $HOME/lucky-conf 是本文的恢复单元。2.x 配置按模块拆分；官方后台支持 ZIP 配置备份，2.8 之后不再支持导入 1.x 配置。备份文件包含账号、入口、证书或第三方 Token 的可能性，必须存放在受限目录。
优先使用 Lucky 设置页的“备份配置”导出 ZIP，再把 ZIP 复制到离线或受限备份位置。若需要保护整个挂载目录，可以先停止容器，打包目录后再启动：
mkdir -p "$HOME/lucky-backups"
docker stop lucky
tar -C "$HOME" -czf \
"$HOME/lucky-backups/lucky-conf-$(date +%Y%m%d-%H%M%S).tgz" \
lucky-conf
docker start lucky恢复前先确认备份来源和版本。停止容器后将备份解压到原工作目录，再启动并检查后台登录、端口转发规则、证书和 DDNS 任务；不要把恢复成功等同于公网链路已经恢复。恢复只覆盖配置目录，不包含镜像、宿主机防火墙规则、DNS 服务商数据或内网应用本身的数据。
升级、回滚和卸载
官方文档提醒，部分 Docker 环境中从后台上传升级包可能失败；更稳妥的流程是先备份，再拉取新镜像、重新创建容器。v2 是浮动标签，升级前应记录当前镜像信息：
docker image inspect gdy666/lucky:v2 \
--format 'image={{.Id}} digest={{join .RepoDigests ","}}'
docker pull gdy666/lucky:v2
docker stop lucky
docker rename lucky lucky-old
docker run -d \
--name lucky \
--restart=always \
--net=host \
-v "$HOME/lucky-conf:/app/conf" \
gdy666/lucky:v2
docker ps --filter name=lucky
docker logs --tail=80 lucky随后重新验证后台登录、端口转发、反向代理、证书和 DDNS。回滚要同时考虑镜像和配置 schema：新版本可能已经改写共享的 /app/conf，切回旧镜像不代表配置也回到了旧格式。新容器失败时，先停止并删除新容器；如果旧版本无法读取当前配置，应使用升级前的 Lucky ZIP 或目录备份恢复配置，再启动旧容器：
docker rm -f lucky
docker rename lucky-old lucky
# 如旧版本报配置格式错误，先停止 lucky，恢复升级前的备份，再执行：
docker start lucky确认新版本运行稳定后，再执行 docker rm lucky-old。不要在删除旧容器前清理 $HOME/lucky-conf；配置目录独立于容器生命周期。卸载只删除容器：
docker rm -f lucky确认不再需要配置、证书和备份后，再由操作者单独删除对应目录。删除容器不会自动删除绑定目录，删除绑定目录才会丢失 Lucky 的配置数据。
旧于 v2.23.1 的容器如果仍把配置挂载到 /goodluck，不要直接把旧容器路径和新镜像混用。先在后台备份配置，再以 /app/conf 创建新容器并恢复配置；固定提交中的 Dockerfile 只说明历史路径，不能覆盖当前官方文档的迁移要求。
常见问题
浏览器无法打开 16601。 先看 docker ps 和 docker logs lucky，确认容器没有退出；host 模式检查主机是否已有进程占用 16601，bridge 模式检查 -p 16601:16601 和主机防火墙。公网访问还要单独检查运营商、路由器和防火墙的 IPv4/IPv6 入站策略。
桥接模式下 IPv6 转发失败。 官方文档明确说明 bridge 只支持 IPv4。Linux 需要 IPv6 或多个主机端口时，删除旧容器后按本文的 host 模式重建，不要只给 bridge 命令增加更多 -p 参数。
重建容器后配置像是丢了。 检查 -v "$HOME/lucky-conf:/app/conf" 是否使用了同一个宿主机目录，并确认运行的是 v2.23.1 及以上路径约定。若从旧镜像迁移，先检查旧容器实际挂载点，再通过备份恢复。
规则保存了但公网仍不可达。 分别测试外部 IPv6 到主机、主机防火墙到 Lucky、Lucky 到内网目标三个区段；确认规则协议、监听端口和目标端口一致。内网回流测试不可靠，应使用蜂窝网络或另一条外部链路。
DDNS 或 ACME 失败。 查看 Lucky 模块日志，核对域名解析、DNS Token 权限、系统时间和证书服务商的验证方式。不要为了排障把完整 Token 粘贴到日志或工单里。
后台访问被安全入口拦截。 使用完整的入口路径访问；如果入口和凭据都丢失，保留配置目录并先查找备份。直接删除配置文件会改变初始化状态，可能造成更大的恢复范围。
部署验证
本指南的镜像、配置路径和命令来自固定提交与官方文档的静态核对，没有在当前环境启动 Lucky 容器，也没有真实验证公网 IPv6、端口转发、DDNS、ACME 或备份恢复。实际部署时至少要观察容器保持 Up、日志没有立即退出、curl --fail --head http://127.0.0.1:16601/ 收到响应，并在外部网络分别验收主机入站、Lucky 规则和内网目标三段链路。配置恢复后还要重新登录后台并检查规则、证书和任务。
总结
Lucky 的 Docker 维护路径以 Linux host 网络和 /app/conf 持久化目录为核心，适合需要直接处理 IPv6 与多个监听端口的软路由、NAS 或小主机。上线前必须更换默认凭据、设置安全入口、限制管理面、保护配置备份和第三方 Token，并把公网链路、DNS 和上游服务分别验收。