上周我彻底放弃了极空间自带的域名解析功能。不是因为它不好用，而是太“笨”了。每天晚高峰回家，极空间的内网穿透接口偶尔抽风，导致我通过 DDNS 查到的 IP 地址是旧的，结果打不开家里的监控。为了这点事，我折腾了整整一个下午，把 DDNS-GO 容器化部署进了极空间的 Docker 环境。

如果你也受够了极空间自带的动态解析偶尔掉链子，或者想接入一些极空间没提供的冷门 DNS 服务商，这套方案能帮你把主动权拿回来。

先说结论：DDNS-GO 在极空间上跑得很稳，但部署过程中有两个坑，踩进去会浪费你至少半小时。下面我直接按我的实际操作顺序，把过程拆解开给你看。

第一步：找镜像源

极空间自带的 Docker 管理器里直接搜“ddns-go”有时候会失败，或者更新很慢。我建议直接去 Docker Hub 确认好最新的 tag，然后在极空间的“应用中心”或者“容器管理”里手动添加。我当时用的是 jigsaw/ddns-go:latest。注意，一定要用 latest，因为 DDNS-GO 更新很频繁，老版本对新协议的兼容有时会出问题。

第二步：映射端口与配置持久化（大坑预警）

这是大多数人容易翻车的地方。DDNS-GO 的配置文件默认存在容器内部的 /etc/ddns-go 目录下。如果你不做持久化挂载，每次容器重启，你辛辛苦苦填的 Token、密码、域名全都没了。

我在极空间的容器创建界面，做了两个关键挂载：

1. 主机目录 /custom/app/ddns-go/config 映射到容器的 /etc/ddns-go。
2. 主机目录 /custom/app/ddns-go/logs 映射到容器的 /root。

这里我要特别提一下极空间的一个小毛病：在创建容器时，如果你新建了一个从未被使用过的文件夹作为挂载点，极空间有时会默认创建为 root 权限，导致容器内的进程（非 root 运行）写不进去日志。我当时的现象是容器一直循环重启，日志里只有 Permission denied。解决办法是去极空间的文件管理器，手动把那个目录权限改成 777，或者确保容器内以 root 身份运行。

第三步：获取公网 IP 的陷阱

很多人以为只要容器跑起来，DDNS-GO 就能自动获取公网 IP。错。如果你家宽带是光猫拨号，或者开了路由器 NAT，容器获取到的往往只是内网 IP（比如 192.168.x.x）。DDNS-GO 会诚实地把这个内网 IP 更新到 DNS 服务商那里，结果就是你在外网完全连不上。

我当时的解决方案是在 DDNS-GO 的设置界面，勾选“通过 API 获取 IP”，并选择了 ifconfig.me 作为探测源。这样它能从外部视角看到你的真实公网 IP。如果你的 ISP 给你分配的是动态 IP，这一步是必须的。

第四步：验证与监控

容器启动后，访问 http://你的极空间IP:9999（默认端口是 9999，我改成了 9999 避免冲突）。这时候你需要输入 DDNS-GO 生成的登录密码，这个密码第一次生成时会在日志里明文打印，记得立刻记下来。

我养成的习惯是，部署完不要直接躺平。我设了一个简单的 Cron 任务，每小时检查一次 DDNS 服务商后台的 IP 是否和 DDNS-GO 面板显示的 IP 一致。虽然 DDNS-GO 本身有监控机制，但多一层保险心里更踏实。

关于更新的取舍

极空间现在支持“自动更新”容器。对 DDNS-GO 来说，我建议关闭自动更新。为什么？因为 DDNS-GO 的数据结构偶尔会有微调，自动拉取新镜像可能导致配置文件字段不匹配，引发报错。我现在的节奏是：每两周手动拉取一次新镜像，对比一下 changelog，确认没问题再停止旧容器、启动新容器。

最后说点真实的感受。这套流程跑通后，我家里所有的外网访问——包括 NAS 远程挂载、SSH 终端、甚至家里的智能插座 APP 都变得极其稳定。以前那种“明明 IP 变了但 DNS 没解析过来”的焦虑感彻底消失了。

DDNS-GO 本身是个很轻量的工具，资源占用极低，极空间跑它毫无压力。唯一需要你要注意的是路径挂载权限，这是极空间 Docker 部署里最容易让人抓狂的点。搞定这个，后面就是纯粹的享用了。

如果你的极空间版本比较老，找不到 Docker 容器管理入口，那可能需要先升级系统，老版本的极空间对 Docker 的支持非常有限，基本属于不可用状态。

折腾NAS最让人头疼的不是扩容，而是“外网访问”。

上个月家里宽带师傅上门，测速显示下行500M，上行却只有30M。更绝望的是，运营商死活不给公网IP，光猫背后全是内网地址。我想用极空间（Zspace）存家庭照片，结果发现在外地根本连不上。VNC、RDP、甚至自带的远程访问都得通过内网穿透，要么收费，要么被墙，要么速度慢得令人发指。

最后我放弃了传统的内网穿透逻辑，改用Cloudflare Tunnel（简称CFT）。这玩意儿不需要公网IP，只要极空间能连上云，就能反向打穿。而且配合腾讯云免费试用，我甚至省去了购买Cloudflare套餐的麻烦，全程零成本，且速度能跑满我那条30M的上行带宽。

以下是我踩坑后的完整流程，专为无公网IP的极空间用户整理。

一、 为什么选 Cloudflare Tunnel？

传统frp、ngrok这类工具，往往需要你有一个有公网IP的中间服务器。对于我这种纯内网用户，这就是死局。

Cloudflare Tunnel的核心逻辑是“反向WebSocket”。简单来说，极空间里的cloudflared客户端主动连接到Cloudflare的云端服务器，建立一条长连接。你在外网访问xxx.trycloudflare.com时，Cloudflare边缘节点识别到这个请求，然后通过这条已建立的隧道，把数据“扔”进你的极空间。

好处是极致的：

1. 零配置端口映射：路由器不需要开任何端口，光猫保持默认桥接或路由模式即可。
2. 自带HTTPS证书：不用自己搞域名SSL配置，免去认证报错。
3. 隐藏NAS真实地址：外部网络只能看到Cloudflare的IP，你的极空间内网IP和端口完全隐藏，安全性比裸露在公网高得多。

二、 前期准备：域名与服务器

1. 腾讯云免费域名

我不建议你直接注册云flare的域名，虽然Cloudflare原生支持，但在国内，注册.com和.net往往能省下一笔钱。
我使用了腾讯云的免费企业邮箱/子域名服务（或者直接用他们每年几块钱的域名活动）。这里我用了mydomain.com作为主域名。

注意：如果为了极致省钱，可以去Cloudflare注册一个免费域名，但解析记录需要手动操作。下文以已有域名为例。

2. 极简空间初始化

确保你的极空间能正常连接互联网。进入极空间App -> 设置 -> 网络设置，确认状态正常。

三、 核心步骤：部署 Cloudflared

极空间原生并不支持直接运行Linux容器（除非你开启了K8s或Docker模式，且版本较新）。我是通过极空间的Kubernetes应用中心部署的。

1. 获取 Token

这是最关键的一步。你需要在极空间生成一个专用的Cloudflared Token。

1. 登录 Cloudflare Dashboard。
2. 左侧菜单 -> Network -> Tunnels -> Create a Tunnel。
3. 填写名称，比如jisu-josuan。
4. 创建后，系统会让你选择创建方式。选Cloudflared，然后复制那串以ey开头的长字符串。这就是你的Tunnel Token。

警告： 这个Token等同于密码，谁拿到都能控制你的NAS，务必保管好，不要发群里。

2. 在极空间部署容器

1. 打开极空间K8s集群管理界面。
2. 新建Deployment（部署）。
3. 镜像选择：cloudflare/cloudflared。
4. 环境变量（关键）：
   • 名称：TUNNEL_TOKEN
   • 值：粘贴刚才复制的那串eyJ...
5. 端口映射：无需映射端口到宿主机，CFT是出站连接。
6. 资源限制：建议给200m CPU和256m内存，足够了。

点击部署。几秒后，容器状态变成Running。

四、 配置入口（Ingress）

容器跑起来了，但还没告诉它“把流量转给谁”。
回到Cloudflare Dashboard -> Tunnels -> 点击你刚创建的隧道 -> Public Hostnames（公共主机名）。

1. 添加服务：
   • Public Hostname: nas.mydomain.com （你可以自定义前缀）。
   • Service: 选择 Local Port。
   • URL: http://192.168.x.x:xxxx
     • 这里填极空间的内网IP和Web管理端口的号。例如：http://192.168.1.10:5000
   • 点击保存。

五、 验证与踩坑实录

配置完成后，别急着欢呼。我一开始在外网访问nas.mydomain.com，一直显示502 Bad Gateway。

排查过程：

1. 检查极空间容器日志：kubectl logs cloudflared-xxxxx。
2. 日志里有一行关键的错误：Unable to connect to service。
3. 我回头一看，极空间内部防火墙禁用了来自本地网络的访问请求（因为我之前设了IP白名单）。
4. 修复：在极空间 -> 网络设置 -> 防火墙中，临时关闭，或者确保K8s的Pod IP在可信列表里。

再次访问，页面加载了。

速度测试：
我用Speedtest测了一下外网上传速度，稳定在28M/s。下载因为受限于Cloudflare边缘节点到国内的线路，大约是40M/s。对比之前用阿里云ECS做frp中转时那种卡顿流媒体、缓冲转圈的状态，这次看4K电影几乎无感。

六、 几个实用建议

1. DNS 记录：确保你的域名在Cloudflare解析中，nas这条A记录指向的是198.41.0.4等Cloudflare IP（实际上CFT是自动配置的，不需要手动改A记录，只要把域名托管到Cloudflare即可）。
2. 极空间重启：CFT容器设置为重启策略Always，极空间断网重连后，隧道会自动恢复，不需要人工干预。
3. 多机扩展：如果你有多个极空间，或者想暴露WebDAV、Jellyfin等服务，可以在同一个Cloudflare Tunnel下添加多个Public Hostname，指向不同的本地端口。比如jellyfin.mydomain.com指向http://192.168.1.10:8096。

这套方案最大的爽点在于“无感维护”。你不需要买服务器，不需要担心IP被封，甚至不需要懂复杂的网络原理。只要你的极空间通电、联网，外网随时待命。

对于像我这样家里没有公网IP、又不想每个月多花几十块钱订阅费的用户，这基本是目前的最优解。

上周末我花了一整晚折腾家里的 NUC，把一直裸奔在 Windows 上的 Qbittorrent 迁移到了 Docker 环境。说实话，刚开始我是抗拒的。Windows 版图标拖进去就能用，多省心？直到有一次我重启电脑，下载任务全断，还得重新手动添加磁链，那一刻我下定决心：必须得搞个 7x24 小时无人值守的方案。

这里不扯什么“架构优雅”的大道理，直接分享我踩坑后的两套可行路径：原生 Linux 安装和 Docker 部署。如果你是软路由或者树莓派用户，前者可能更直观；但如果你像我一样有个闲置的 x86 主机，Docker 绝对是更干净的选择。

为什么我放弃了 Windows 和原生 Linux

先说 Windows。虽然 QBT 在 Win 上很稳定，但它是个后台服务，关机就等于停服。我试过设置开机自启，结果每次系统更新后路径都会变，经常连不上。

后来我想着直接装个轻量级的 Debian 系统，结果翻车了。原生安装需要手动配置 qbittorrent.conf，还要处理 systemd 服务单元。一旦我想升级版本，就得重新编译或者替换二进制文件，还得注意依赖库版本冲突。

有一次升级后 Web UI 直接白屏，查了半天日志才发现是前端静态文件权限问题。这种“黑盒”维护，对不想整天修机器的人来说太折磨了。

最后我选了 Docker。理由很简单：环境隔离，配置即代码，坏了直接删了重建，五分钟搞定。

Docker 部署的实操细节

我用的镜像是 linuxserver/qbittorrent，比官方镜像更新快，而且自带了一些便利性脚本。

1. 数据卷挂载（最关键的一步）

很多新手直接 docker run 起来就完了，结果发现下载完的文件找不到，因为容器内部的文件系统重启后清空了。你必须显式挂载两个目录：

• /config：存放配置、会话状态。
• /downloads：实际存放文件的地方。

docker run -d \
  --name qbittorrent \
  --restart unless-stopped \
  -p 8080:8080 \
  -e PUID=1000 -e PGID=1000 \
  -e TZ=Asia/Shanghai \
  -v /opt/qbittorrent/config:/config \
  -v /mnt/data/downloads:/downloads \
  ghcr.io/linuxserver/qbittorrent:latest

注意 -e PUID=1000 和 -e PGID=1000。 这是我踩得最大的坑。如果不指定用户组，容器内以 root 身份创建的文件，宿主机的普通用户读不了，挂载点权限混乱。根据你的宿主机实际用户 UID/GID 改这两个值。

2. 网络模式的选择

默认 bridge 模式够用，但如果你希望 QBT 获取到内网 IP 以便局域网访问，或者需要更复杂的端口映射，可以考虑 host 模式。我推荐先用 bridge，因为隔离性好，不容易跟宿主机其他服务端口冲突。

自动化与防“假死”

部署完只是第一步，真正的痛点在于“僵尸任务”。QBT 偶尔会卡在一个种子上了，进度条不动，也不报错。

我加了一个简单的健康检查脚本，每 10 分钟跑一次。如果 QBT 的 Web API 响应超时，就自动 docker restart qbittorrent。

#!/bin/bash
# healthcheck.sh
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" "http://localhost:8080/api/v2/app/getVersion" --user "admin:yourpassword")
if [ "$RESPONSE" != "200" ]; then
    echo "QBT unresponsive, restarting..."
    docker restart qbittorrent
fi

把这个脚本扔到 Docker 的 HEALTHCHECK 指令里，或者直接在宿主机跑个 cron 任务。这比你自己记得去检查强多了。

避坑指南：关于 Web UI 密码

Docker 起容器后，第一次登录 Web UI（默认 http://IP:8080）需要初始密码。很多人会在这里卡住，因为默认密码是“空”，但界面却提示“请输入密码”。

解决方法：

1. 去 /config 目录下找到 qbittorrent.conf。
2. 编辑 [WebUI] 部分，把 Password 改掉。
3. 重启容器。
4. 或者在启动容器时通过环境变量注入初始密码（看镜像文档支持与否）。

千万别把默认的空密码用在生产环境，除非你的局域网有防火墙严格管控。

总结

Qbittorrent 本身是个成熟的软件，部署方式无非就是“怎么让它永远不关机”和“怎么方便管理文件”。

• 图省事：树莓派/软路由直接装包，配好开机自启。
• 图干净：用 Docker，挂载好卷，设好用户权限，加个健康检查。

我现在每天早上起来，看着 NUC 的硬盘灯闪烁，打开网页就能管理几百个种子的状态，这才是工具该有的样子。别被技术细节吓住，先把容器跑起来，再慢慢调优配置。

折腾极空间 Z4 Pro 这半个月，终于把它调教顺了。之前一直用群晖，图的就是个“稳”，懒得动脑子。但最近家里想搞个软路由加 NAS 的混合体，为了省电费，决定试试极空间。刚到手时，最大的拦路虎就是 Docker 镜像源。国内直连 Docker Hub 那个速度，转圈转到让人怀疑人生，真的急人。

1. 网络代理：土办法最管用

我踩的第一个大坑就是“网络代理”。很多人第一反应是配 Hosts，或者用第三方镜像加速器。我一开始也这么干，结果发现极空间底层和群晖不一样，它对系统级的修改比较保守，动不动就回滚或者不生效。

我在 Z4 Pro 的 Docker 里拉取 linuxserver/emby，卡了十分钟才下来 50MB，心态直接崩了。后来翻了半天社区帖子，发现极空间自带的 Docker Hub 镜像源支持自定义，但稳定性确实不如一些动态更新的加速节点。

我的解法比较土：我在 VPS 上跑了一个简单的 Nginx 反向代理，通过 SSH 隧道把流量打穿过去，在极空间的 Docker 网络设置里，把 HTTP_PROXY 环境变量写死指向我的 VPS。虽然配置稍微麻烦点，但之后拉取镜像的速度直接起飞，基本满速下载。

操作提示：如果你也是类似情况，不要死磕系统级 Hosts，直接走环境变量代理更稳。

2. 权限与挂载：Btrfs 文件系统的陷阱

第二个痛点是权限和挂载。极空间的文件夹权限逻辑和 Linux 原生有点出入。我试着在 Docker 里挂载数据卷，一开始直接写 /volume1/docker/emby，结果容器里进去一看，全是只读，或者根本就是空的。

后来我才反应过来，极空间用的是 Btrfs 文件系统，而且在 Web 界面里看到的“共享文件夹”，在 Docker 容器里对应的路径是 /storage/XXXX 或者类似的映射路径，而不是物理路径。

最稳妥的办法是：

1. 先在 Web 界面建好共享文件夹。
2. 在 Docker 高级设置里，直接通过图形界面选择那个共享文件夹进行挂载。
3. 千万不要让 Web 界面帮你解析路径字符串，否则极易出错。

3. 存储池：务必给 Docker 划固态盘

极空间 Z4 Pro 允许组建 RAID，但 Docker 数据如果放在 RAID1 或者 RAID5 里，写性能会受限。我特意把 Docker 数据卷单独划在一个 SSD 盘上，组成 RAID1。

这点很重要。如果你把 Docker 镜像、容器数据和数据库都塞在机械硬盘的 RAID5 里，并发写的时候，I/O 等待会让你的 Jellyfin 或者 Plex 转码卡死。

我测过一组数据：

• SSD 做 Docker 盘：启动 Emby 冷加载速度大概是 8 秒。
• 机械硬盘：启动 Emby 冷加载速度大概是 45 秒。

对于日常家用，这差距体验感完全不同。

4. 隐蔽的坑：时区不对齐

很多开源镜像默认是 UTC 时区，导致你在 Web 界面看到的日志时间，比实际快 8 小时。我在 docker-compose.yml 里全局加了时区环境变量：

environment:
  - TZ=Asia/Shanghai

这个看似小事，但一旦日志乱序，排查问题时会非常痛苦。

5. “零门槛”的 A 面与 B 面

最后聊聊极空间的“零门槛”到底值不值得。

• 对于小白：极空间的 Web 界面确实友好，可视化操作降低了门槛。
• 对于进阶用户：如果你对 Docker 网络原理（比如 Bridge 模式和 Host 模式的区别）有需求，极空间的 GUI 封装反而成了束缚。

我后来放弃了纯 GUI 操作，转而在 SSH 里敲命令。比如我要给容器分配固定 IP，Web 界面里只能选随机，我得手动编辑 /etc/containers/ 下的配置文件，重启 docker 守护进程才能生效。这种“半自动”的体验，让高级用户有点尴尬，但让小白用户安心。

核心结论

极空间部署 Docker，核心思路就是：网络走代理，数据放固态，时区要统一，权限避坑走 GUI 挂载。

别指望它像群晖那样什么都给你包好，也别指望它能像原生 Linux 那样自由。它是个很好的中间层，适合那些想要省心又不想完全放弃折腾乐趣的人。

最后给个建议：如果你家里只有机械硬盘，我建议把 Docker 容器数量控制在 3 个以内，否则机械盘的扇区寻道声会伴随你整个深夜。