# 用 Mac mini 从零搭建 Nextcloud 家庭云：从 AIO 部署到公网直连
问题背景
一开始的目标很明确：在家里的 Mac mini 上自建一个类似坚果云的同步服务，用来保存个人文件、家庭共享文件，并支持手机和电脑在外网访问。相比继续依赖第三方网盘，自建 Nextcloud 的核心价值是数据主要放在自己的硬盘里，账号、共享目录、备份策略也可以自己控制。
这次最终采用的是 Nextcloud AIO 方案。AIO 的好处是官方把 Nextcloud、数据库、Redis、Apache、Notify Push、备份等组件打包到一套容器流程里，维护成本比手工拼 Docker Compose 低一些。底层运行环境选择 OrbStack，数据盘和备份盘分别放在外置磁盘上。
现象
搭建过程不是一次性顺利完成的，中间主要遇到了几类问题。
- 一开始要确认数据到底应该放在哪里，避免 Nextcloud 服务器数据目录和客户端同步目录混用。
- 家庭宽带公网标准端口 80 和 443 不可用，不能直接按常规 HTTPS 方式暴露服务。
- 先通过 VPS 和反向 SSH 隧道跑通外网访问，但客户端同步流量会绕 VPS。
- 后来改成家庭公网高端口直连，需要重新处理 DNS、证书、反向代理和 Nextcloud 的高端口配置。
- Mac 客户端安装后使用的是 macOS CloudStorage 文件提供者模式，本地看到的文件不一定真的完整下载。
这些问题的共同点是：Nextcloud 本身只是其中一部分，真正决定可用性的还有存储、反向代理、证书、端口转发、备份和客户端行为。
排查过程
第一步先处理本机运行环境。Mac 上安装 OrbStack 后，确认 Docker 可以正常运行，并确认容器架构、CPU 和内存分配正常。Nextcloud 的用户数据单独放到外置盘的数据目录，AIO Borg 备份放到另一块外置盘的备份目录。这样做的目的很简单：服务数据和备份不要混在一起，后续迁移或恢复时边界更清楚。
第二步启动 Nextcloud AIO 管理容器。AIO 管理入口只绑定在 Mac 本机，实际 Nextcloud Apache 后端也只先暴露给本机或反向代理，不直接裸露到公网。这样在公网入口没处理好之前，服务不会被不必要地暴露。
第三步先用 VPS 作为中转入口。Mac 主动连到 VPS，建立反向 SSH 隧道；VPS 上的 Nginx 再通过本地回环端口转发到 Mac 上的 Nextcloud。这个方案的优点是稳定、容易申请标准 HTTPS 证书，也不依赖家庭宽带入站 443 是否可用。缺点也很明显：所有客户端上传下载都会绕 VPS 一圈，带宽、延迟和 VPS 流量都会变成瓶颈。
第四步初始化 Nextcloud。完成 AIO 安装后，创建普通用户和家庭组，安装 Group folders，建立“家庭共享”目录。随后把本地坚果云目录按账号导入 Nextcloud：一部分进入家庭共享，一部分进入个人账号根目录。导入完成后通过 Nextcloud 的扫描命令让数据库识别这些文件，再执行一次 Borg 备份，确认导入后的数据可以被备份。
第五步测试家庭宽带入站端口。结果是标准 80 和 443 不可达，但高端口可以从公网访问。因此最终切换到“公网高端口直连”：域名通过 CNAME 指向家庭 DDNS，路由器把公网高端口转发到 Mac 上的 Caddy 容器，Caddy 再反向代理到 Nextcloud AIO Apache。
这里还有一个关键点：因为 80/443 不可用，不能依赖 HTTP-01 方式签发证书，所以改用 DNS-01。Caddy 构建时加入 AliDNS 插件，通过 DNS 记录完成 Let’s Encrypt 证书申请和续期。这样即使公网只开放高端口，也可以拿到正常可信的 HTTPS 证书。
解决方法
最终稳定下来的架构是：
- Mac mini 作为家庭服务器。
- OrbStack 运行 Nextcloud AIO。
- Nextcloud 用户数据放在外置数据盘。
- AIO Borg 备份放在外置备份盘。
- Caddy 作为本地 HTTPS 入口，负责证书和反向代理。
- DNS 使用家庭 DDNS，业务域名 CNAME 到 DDNS 域名。
- 路由器把公网高端口转发到 Mac 的 Caddy 入口。
- VPS 反向 SSH 隧道保留一段时间，仅作为回退方案。
Nextcloud 侧还需要处理高端口感知问题。否则网页、WebDAV、客户端授权和 Notify Push 可能仍然认为自己运行在默认 443 端口。最终通过单独的自定义配置文件设置：
- `overwritehost` 指向带端口的访问域名。
- `overwriteprotocol` 固定为 `https`。
- `overwrite.cli.url` 指向新的高端口 HTTPS 地址。
这个配置不要直接改 AIO 自动生成的反向代理配置文件，而是放在最后加载的自定义配置里，避免 AIO 重启或升级时覆盖。
备份方面，使用 AIO 自带的 Borg 备份。备份密码只保存在 AIO 和 macOS 钥匙串中，不写入项目文档。备份时间设置为北京时间每天 04:00，并在首次导入数据后执行完整备份和完整性检查。
客户端方面，Mac 上安装 Nextcloud 客户端后，Finder 左侧会出现 Nextcloud 入口。当前客户端使用 macOS 的文件提供者模式，本地实际位置在用户目录的 `Library/CloudStorage` 下。这个目录主要是同步视图和本地缓存，并不等于服务器数据目录。默认情况下，文件可以只是云端占位；只有打开文件或选择“Always keep downloaded”时，才会真正下载到本机。如果想释放本机空间，应在 Finder 右键选择 “Remove download”，而不是删除文件。
注意事项
第一，服务器数据目录和客户端同步目录必须严格区分。服务器数据目录是 Nextcloud 后端真正保存文件的地方，不能拿来当客户端同步目录使用。客户端同步目录只是某台电脑自己的本地视图和缓存。
第二，家庭宽带能不能直连，不能只看有没有公网 IP，还要测入站端口。很多线路即使有公网 IP，也可能屏蔽 80 或 443。遇到这种情况，可以选择高端口直连，并用 DNS-01 方式申请证书。
第三，如果通过 VPS 中转，部署会更容易，但同步文件流量会经过 VPS。小文件和低频访问问题不大，大量同步照片、视频或备份文件时，VPS 会成为瓶颈。
第四，Nextcloud AIO 的自动化程度高，但也意味着有些配置会被它接管。需要自定义高端口、Notify Push 或反向代理行为时，应尽量使用可持久化、可恢复的方式，而不是直接改临时生成文件。
第五，导入已有网盘文件时要先明确映射关系。比如哪些目录进入家庭共享，哪些目录进入个人账号，是否保留外层目录，都应该在复制前确定。否则导入完成后再调整，会增加扫描、权限和备份成本。
第六，备份不是“配置了”就结束。至少要确认首次备份成功、完整性检查通过，并在合适的维护窗口安排恢复演练。没有恢复验证的备份，只能算半成品。
总结
这次 Nextcloud 搭建最后形成了一套比较清晰的家庭云方案：Mac mini 负责计算，外置盘负责数据和备份，Nextcloud AIO 降低维护复杂度，Caddy 负责 HTTPS，家庭公网高端口负责直连，VPS 只保留为临时回退。
真正需要注意的不是某一条命令，而是边界划分：服务器数据目录、客户端缓存目录、备份目录、反向代理入口、公网回退入口都要分清楚。只要这些边界清楚，后续无论是客户端同步、手机访问、文件导入还是恢复备份，问题都会少很多。