在 VPS 上自建 Nextcloud：用你自己掌控的服务器取代 Google Drive

你真正替换掉的是什么，没替换掉的又是什么

剥去营销话术，Nextcloud 其实就是一个 PHP 应用：维护一个文件元数据的数据库和一个存放文件内容的目录，并且支持足够多的协议，让普通设备把它当成一个正常的云账户来对待。这种描述低估了它悄悄覆盖了你数字生活中多大的一部分。文件同步是看得见的那部分，也是大家安装它的初衷。真正在六个月后才显出分量的，是那些没人会演示给你看的部分：通过 CalDAV 和 CardDAV 同步的日历与联系人，让你手机自带的应用不用再跟某个邮件服务商对话；带自动相册上传的照片库，这才是真正能让一家人告别 Google Photos 的东西；还有笔记、任务和书签，不必再散落在四个你控制不了的账号里。

值得把这个对比说精确一点，因为通常的说法框错了方向。没有人是为了在 GB 上省钱才自建的——一份两 TB 的消费级套餐，价格和一台中档 VPS 差不多，还完全不用操心。你之所以自建，是因为另一个选项是这样一种关系：对方掌握着数据、制定规则、为了合规扫描内容，还会处理关于你的法律要求，却没有任何义务事先告诉你。去掉这个对方，就是这件事全部的产品价值。其余的一切都只是副作用，有些讨人喜欢，有些则成了你新添的责任。

你得不到、也不该指望得到的，是超大规模云服务商免费提供的那层看不见的运维基础。除非你自己搭建，否则不会有跨地域复制。不会有边缘网络，让地球另一端的人也能快速完成一次大文件下载。也不会有支持工单队列，在你删除文件又当天下午清空回收站之后，替你把文件找回来。凌晨三点磁盘写满时，五台设备上的同步客户端会开始亮红色图标，而解决这一切的人是你自己。这不是在劝你别做，而是在说清楚你接下的这份工作到底包含什么。

最后一件要看清楚的事，是更新节奏。Nextcloud 一年会发布好几次主版本，升级必须一个主版本一个主版本地来，而你已经离不开的一些第三方应用，有时候会落后最新版本一个版本。这项工作本身并不难，内置的更新程序加上事前打个快照，能把它压缩成十五分钟的活，但这是一项带着截止日期的持续性工作：一个落后三个主版本的实例，你没法一步升级到位，也不适合继续安全地暴露在互联网上。

机器该怎么选：按文件服务器来定规模，而不是按网站

大多数自建指南是按应用本身来定服务器规模的。而对这套系统来说，应用几乎无关紧要，资料库才是一切。在家庭规模的负载下，PHP 进程、Web 服务器、数据库和缓存加在一起，一两个 GB 的内存就能轻松容纳；真正决定你该选哪档套餐的，是你要往磁盘上放多少字节，以及这些字节被分成了多少个独立文件——这是两个各自独立的约束，会以两种不同的方式让你踩坑。

先从如实盘点开始，而不是从理想化的估计开始。文档和表格基本可以忽略——攒上十年也很少超过 10 GB。手机相册可不是噪音：算上视频的话，一部现代手机每人每年会产生大约 15 到 40 GB，如果给一家四口都开启自动上传，那就等于每年承诺大约 100 GB，不管你有没有意识到，它都会照来不误。然后还要在原始资料库之上再加一层开销：为图片和视频生成的预览图、为编辑过的文档保留的版本、以及一个默认会把已删除文件保留最多 30 天、并占用同一块磁盘空间的回收站。一个实用的估算是“资料库总量再加 20%”，而这 20% 正是大家会忽略的部分，直到磁盘用量到了 95% 才想起来。

内存是第二个约束，满足起来要便宜得多。4 GB 就能平稳跑一个单用户实例。8 GB 是家庭或小团队比较舒适的数字，因为它能让你给 PHP-FPM 配足够的 worker，去应付好几个同步客户端同时被唤醒的情况，给数据库一个像样的缓冲池，还能给操作系统的页面缓存留出空间，把常用的元数据留在内存里。只有当你加上 Nextcloud Office 时，这个数字才会明显变化——它会在自己的容器里跑一套完整的文档转换引擎，在任何人打开一张表格之前，就要独占 2 到 4 GB。

CPU 在稳定运行时几乎感觉不到存在，但会在大约一周的时间里变得极其重要。为已有的照片库生成预览图，是这台服务器要做的最重的活——每张图片都要被解码，再按几种尺寸重新编码——在一个小套餐上，这第一遍处理可能要跑上好几天。这之后，提供文件服务几乎不花什么代价：工作量在于 I/O，同步协议本身的“话多”，消耗的也是往返次数而不是运算周期。买核心是为了这次导入，不是为了日常运行的实例；如果导入是你唯一想升级套餐的理由，那就升到大一档跑一个月，再降回来就好。按月计费、没有合同约束，正是这种操作能省钱的原因。

最后一行值得多读一遍，因为这正是大家最容易把机器规模选错的地方。VPS 非常适合作为一群人日常接触的工作集的同步与共享枢纽。但它不适合当媒体档案库：我们出售的最大档位，本地 NVMe 也只到 640 GB 封顶，一旦你的资料库要以 TB 计，正确答案就是专用服务器——用一对镜像硬盘，在底层冗余的保护下，给你一到两个 TB 的空间。提前想清楚这一点，要比在磁盘用满之后再迁移一个已装满数据的实例轻松得多。

只需要做一次的数据库决定

安装程序会给你提供 SQLite 这个选项，它也确实能用。但只把它用在你打算之后删掉的演示环境上，别的场合都不要用。SQLite 会把整个数据库的写入操作串行化，而这个应用几乎一直在写——每一次同步客户端轮询、每一次文件扫描、每一条活动记录——所以只要有两个客户端同时活跃，请求就会开始互相排队，界面也会出现一种任何调优都去不掉的延迟。官方系统要求也委婉地说明了这一点。

MariaDB 和 PostgreSQL 都是一流之选，两者之间的取舍更多是个人偏好问题。大多数部署跑的是 MariaDB，社区里大多数解答也是照着它来假设的，这一点在你半夜搜索一条报错信息时会很有用；它需要用四字节 UTF-8 字符集来建库，这样文件名里的表情符号才不会截断某一行，而且它的事务隔离级别要设成 read-committed，文档写得明明白白，但大家总是跳过这一步。PostgreSQL 在并发场景下悄悄地更出色，需要的额外调教也更少，代价是能直接抄的现成答案池子稍微小一点。两者都是正确选择；不管选哪个，只要是你已经知道怎么备份的那个，就比另一个更正确。

把它装在同一台机器上，用 unix socket 连接。这是少数“显而易见的架构恰好也是正确架构”的地方之一：把数据库放到另一台主机上，对单个实例没有任何好处，反而会让应用发出的大量小查询，每一次都多绕一趟网络往返。把数据库绑定在回环接口上，绝不要绑定到公网接口——加固清单讲了为什么一个对外监听的数据库，是一台小型服务器从主人手里被夺走的最常见方式。

关于这个数据库要理解的一点是：它字节数很小，后果却很大。它的核心表里，每个用户的每个文件占一行——四个账号、十万个文件，也就是几十万行，对现代数据库引擎来说不算什么，在磁盘上也就几百 MB。但只有这张表，知道你的数据结构长什么样。丢了数据库、留着文件，你得到的就是一棵没有共享、没有版本、没有评论、没有标签、也没有同步状态的目录树。命令行的 rescan 能从中重建出一棵可用的目录树，第一次真正需要用到它时，会让你实实在在松一口气，但它找不回哪怕一个共享链接或版本历史。永远把两者一起备份，只备份其中一个而没有另一个，就当它根本不算备份。

为什么默认安装用起来会慢——以及能解决这个问题的四项设置

一个刚装好的实例，通常会被人说反应迟钝，说这话的人并没有说错。问题不出在硬件，也不出在 PHP 上：而是出在四项出厂设置，它们是为了在共享主机上做到最大兼容性而选定的，而不是为了一台你自己掌控的机器。改掉它们只需要二十分钟，却能带来任何人对这套安装所做的、感受最明显的一次提升。

第一项是后台任务。开箱状态下，这些任务以 AJAX 模式运行，意味着队列只有在有人用浏览器打开页面时才会往前推进——所以预览图不会生成，回收站不会过期清理，联合共享不会刷新，搜索索引也不会建立，除非碰巧有人访问。按照 后台任务文档所说的那样，切换成一条系统 cron 条目，以 Web 服务器用户身份，每五分钟运行一次任务执行器。关于 Nextcloud“什么都不做”的那些莫名其妙的抱怨，一半都出在这项设置上。

第二项是缓存和文件锁。没有共享缓存，应用会不停地重复读取配置和应用元数据；没有由 Redis 支撑的事务性文件锁，它就会退回到在数据库里锁行，而那恰恰是你最不希望出现争用的地方。安装 Redis，让它监听 unix socket 而不是 TCP 端口，这样网络上就没有任何东西能连到它，然后把分布式缓存和文件锁后端都指向它，同时把速度更快的本地缓存留给 APCu。缓存配置参考给出了确切的配置块。

第三项是 PHP 的操作码缓存。出厂的缓冲区大小是按一个小型应用设定的，而这个应用不是——管理概览页面会直接告诉你，字符串驻留缓冲区快满了，而缓冲区一满，解释器在每次请求时就会做一些本可以避免的工作。把 opcache 的内存和字符串驻留缓冲区调大，再把最大加速文件数提到远高于默认值的水平，只需要多花几百 MB 内存，却能在每一次页面加载时立刻感受到效果。第四项是 PHP-FPM 的进程管理器：默认的 worker 数量，是按一台内存远比你这台少的机器调的，一个有好几个同步客户端的家庭很快就会在这里排队。要按你实际的内存和每个 worker 的占用来定 worker 数量，这是本节里唯一值得动笔算一算的部分。

有一个相关的坑值得单独成段，因为它会造成一种令人困惑的症状：通过网页界面上传大文件会失败，而同一个文件从桌面客户端上传却没问题。这不是 bug：桌面客户端会把上传拆成分块，再在服务器端重新拼装起来，所以能躲过所有限制，而浏览器发送的是一个大请求，必须扛过 PHP 的上传和 POST 大小限制、Web 服务器自身的最大请求体限制，以及中间任何一处超时。如果大文件是从浏览器进入你的实例的，所有这些数值就必须一起调大——只调其中一个，不调其他的，只是换了一个组件出来拒绝你而已。

三种不同的机制都叫加密，防的却是三种不同的人

这是大多数自建部署会出错的地方，而且错得可以理解：三个互不相关的功能共用同一个词，管理界面把三者都摆出来给你选，而多启用几个听起来总比少启用几个更安全。事实并非如此。这三者各自防的是特定的对手，各自都有代价，而其中一个，用在大家通常会用的场景上时，实际上是有害的。

全盘加密是垫在最底层的那一层。它保护的是一台已关机机器上的数据——一块从机架上拔下来的硬盘、一块退役的驱动器、一份从冷存储复制出来的镜像。服务器运行期间，它什么作用都不起，因为卷已经解锁，操作系统会把它当成普通文件来读取。它成本低、不打扰任何人、对 Nextcloud 的任何功能都没有影响，也没有什么理由不用它。它要求的是一套远程解锁方案，因为一台在凌晨四点重启的服务器，在有人输入密码短语之前会一直停在那里；全盘加密指南讲了怎么用 initramfs 里的 SSH 安排，让这件事变得可以扛得住。

服务器端加密，是最值得你认真琢磨的那一个。它用同一台服务器上的密钥，由同一个应用管理，来加密文件内容，而它真正的设计目的，是保护你放在别人的存储上的数据——一个对象存储、一个租来的外部挂载、一个第三方后端。用在你本就掌控着的机器上的本地主存储上时，它能给你的保护少得可怜，因为任何能读到文件的人，也能读到密钥；而它的代价是多耗费大约三分之一的存储空间、让每一种恢复场景都变复杂，还会关闭那些需要读取文件内容的功能。加密文档对这笔取舍说得异常直白。如果你的存储是一台你独自租用的服务器上的本地 NVMe，就不要开它，改用磁盘这一层就好。

端到端加密才是真家伙，也是三者之中唯一能防住服务器本身的那个。端到端文件夹里的文件，会在离开设备之前就由客户端加密，服务器存的是它自己也打不开的密文——这正是你想要的效果，用在那一小部分“就算胁迫主机方也绝不能拿到可读数据”的内容上。代价是严苛且没有商量余地的：这些文件夹没有网页界面、没有服务器端搜索、没有缩略图、不能公开分享，如果丢了解锁用的助记词，也没法恢复。这不是一个需要想办法绕过去的局限，而是这份保证本身的定义。把它用在真正需要它的那个文件夹上，让家庭照片库留在它之外，那里预览图能用，日子也过得舒心。

客户端，以及其他人真正会用到的部分

这个项目成不成功，几乎完全取决于那些永远不会登录服务器的人，而他们的判断，会在第一周之内由三款软件决定。桌面客户端是最重要的那一个。把它配置成虚拟文件模式，而不是完整的本地副本——文件出现在文件管理器里，打开之前不占空间，按需下载——因为正是这一点，让一个 200 GB 的资料库在一台磁盘不大的笔记本上也能用，而这也正是大家已经从商业客户端那里习惯了的行为。

手机应用里，装着那项能说服怀疑者的功能：相册自动上传。给家里人都打开它，指向各自的用户文件夹，一个月之内，关于要不要离开 Google Photos 的争论就会结束。但也正因为同样的原因，这也是那个会按一个你没有选择过的节奏，把你的磁盘填满的东西——这也是为什么上面定规模那部分，花的心思在相机而不是文档上。从一开始就给每个用户设一个配额——不是因为你打算真的强制执行，而是因为一个配额，能把“磁盘悄无声息地用完”，变成某人手机上一条清楚的提示消息。

日历和联系人，是那个不声不响的胜利，也是最常见的“配置到一半就撂下”的地方。Nextcloud 支持 CalDAV 和 CardDAV，而每台手机和电脑都原生支持它们，所以不需要装什么新应用——但自动发现依赖一对重定向，分别在 /.well-known/caldav 和 /.well-known/carddav，它们活在你的 Web 服务器配置里，而不是应用里。配错了，账户设置就会在 iOS 上报出一个毫无帮助的错误，在 Android 上却一切正常。管理概览页面会明确标出这个问题，这也是让你在别人使用之前先清空那个页面的又一个理由。

还有两个小提示，能实实在在省下时间。系统支持挂载 WebDAV，对于不想在某台机器上装任何东西、只是偶尔访问一下的场景，这确实很方便；但它也很慢，因为每一次操作都是一次 HTTP 往返，所以用来当工作目录很糟糕，用来抓一个文件倒是不错。另外，给每台设备都建一个应用密码，而不是把账户密码直接发出去：这样撤销一台丢失的手机，就只是删掉一个令牌，而不必去改密码、再给你拥有的每一个其他客户端重新做一遍认证。再给账户配上双因素认证，并且让一个日常没人用的管理员账户，和你真正用来同步的账户分开。

司法管辖地不再是个抽象概念的地方

对于你可能自建的大多数东西来说，机器放在哪里主要是一个延迟决定，带一条法律方面的脚注。但对你的整个文档档案、照片、联系人和日历而言，优先级反过来了——这是唯一一台法律问题的分量超过网络问题的机器，因为它上面的数据，正是法律程序真正会针对的那一类。

要理解离开一家超大规模云服务商之后，改变的到底是什么。当你的文件放在一家大型服务商那里时，针对这些文件的要求会送到这家服务商手上，由它的法务部门权衡自身利益之后评估，而且多半会在一份保密令下照办——你可能永远都不会知道发生过这件事。当文件放在你租来的服务器上时，不存在这样的部门，也不存在这样的条件反射，索要数据的一方得自己去找人。这不是什么神奇的护盾；而是结构上的改变：谁会被问到、这次询问有多显眼、一份请求和一份你的数据副本之间，隔着多少道摩擦。我们的法律解读详细讲了这层摩擦具体是什么、又不是什么。

由此带来两个实际后果。第一，司法管辖地应该是刻意选出来的，而不是凭延迟高低条件反射地选出来的——管辖地对比和关于“十四眼联盟”的说明讲清楚了这四个地点各自有什么不同，对于个人档案而言，答案通常是：在你能忍受的往返延迟范围内，选法律底线最强的那一个。第二，主机方永远只能被迫交出它自己能触及到的东西，这正是为什么上面那几层加密不是摆设：全盘加密，再加上在需要的文件夹上启用端到端加密，意味着面对一份要求，诚实的答复就是一份密文的磁盘镜像。

这里确实存在一个延迟上的取舍，但比大家担心的要小。同步是一个后台过程——没人会盯着一张照片上传——所以多出来的一百毫秒往返延迟，在你整天都在做的这件事上，感觉不到任何影响。真正能显出来的地方，是在网页编辑器里打开一份文档，或者滚动一个很大的图库，这些是交互式的，同样的一百毫秒会在每一次操作上都被感知到。如果人在欧洲，阿姆斯特丹或苏黎世能让这两种体验都保持迅捷；如果法律姿态才是重点所在，雷克雅未克会让你的交互响应速度明显变慢、但仍在可接受范围内，而在同步上则完全没有影响。

有一项义务值得直说清楚，因为自建会悄悄把它转移到你身上。一旦别人的文件出现在你的服务器上——家人的照片、同事的文档、客户的合同——你就成了对这些数据负责的一方，而在欧洲，这份责任是有名字的，还附带一整套义务。在家庭规模上，这算不上什么沉重负担，也不该等到吵起来的时候才发现：提前想清楚谁能访问什么，告诉数据的主人他们的数据放在哪里，并且让管理员账户不参与日常使用，这样读取别人的文件夹，才会是一个刻意的举动，而不是一次意外。

备份，以及你必须演练的那次恢复

需要保留的东西恰好是三样，而且三者必须来自同一个时间点：装着文件内容的数据目录、装着这些文件全部元数据的数据库，以及 config.php——里面有实例标识符、数据库凭据，如果你启用了服务器端加密，还有没有它们其余一切都读不出来的那些值。三样只备份两样，你得到的就是一次饶有趣味的考古活动，而不是一次恢复。

一致性是那个很容易在不知不觉中出错的部分。在数据库正被写入的同时复制文件，得到的备份会是两半互相对不上的备份，这种不一致会在几周之后浮现出来，表现为磁盘上存在、界面里却看不到的文件，或者界面里指向的条目其实什么都没有。直接的解决办法，是把实例切换到维护模式，导出数据库，打包数据目录，再关掉维护模式——这是一次凌晨四点没人会注意到的短暂停机。备份文档把这套顺序讲得很清楚，如果你的存储支持文件系统快照，在应用静默期间打一个快照，能用更短的时间达到同样的效果。

然后把它发送到别处，而且要在离开之前就加密好。Restic 和 Borg 都在客户端加密，并且对“边缘不断变化”的数据集去重效果很好，而这正是文件服务器数据的形态。把远端仓库设成只能追加，这样即使主机被攻破，也删不掉自己的历史记录——正是这一点，把备份从“只能对付一块坏掉的硬盘”，变成了“能对付勒索软件”；再把远端放在和本地不同的司法管辖区，因为一份可能和原件在同一次行动中一起被查封的副本，算不上真正的第二份副本。把仓库的密码短语放在服务器之外的地方保管。

有两个常被误认成备份的功能，值得点名说一说。文件版本和回收站是活在同一个实例、同一块磁盘、同一个数据库里的便利功能；它们能很好地找回一次意外覆写，但服务器本身出的任何事，它们都扛不住。同样，我们每一档套餐都自带、保留七天的每小时服务商快照，用来撤销一次糟糕的升级非常好用，但它不是异地备份，因为它和它所依托的基础设施共享同一个命运。三个都用上。但真正能依靠的，是那份放在别处的备份。

最后，在一切正常的时候，把恢复流程演练一遍。开一台用完即弃的服务器，把数据库和数据目录恢复进去，修正 config.php 里的受信任域名条目，然后登录看看。你会发现点什么——一个缺失的 PHP 模块、一个你从没记下来的数据库用户、一把放在你忘记的地方的加密密钥——而你会在一个只花掉你一个小时的下午发现它，而不是在一个会让你搭上整个档案库的日子里才发现。如果恢复还需要用文件重新扫描来对齐目录树，那正是命令行工具存在的意义，提前知道这一点，就是这次演练的全部意义所在。

对外分享，但不向内泄露

让这套系统对别人真正有用的那项功能，同样也是那个会把指向你文件的 URL 摆到公网上的功能，所以值得花五分钟认真配置一下，而不是照用默认值。公开链接应该按策略、而不是按每个链接单独决定，来强制附带密码和过期时间——这两项都可以在整个实例范围内强制启用，也就是说，这个设置由你设一次就好，而不是每次都指望别人别忘了设。仅上传的投递文件夹，是一个被低估的用法：一个只接收文件、却不暴露文件夹里已有内容的链接，能取代你现在所有那些别扭的邮件附件流程。

在反向代理之后运行——几乎所有人都是这么部署的——有一项配置值，会引发不成比例的困惑。如果没有告诉应用该信任哪些地址作为代理，每一个请求看起来都像是从代理本身发出的。这样一来，速率限制就会把全世界都算成同一个访客，暴力破解防护最终会把那一个地址给限流，效果就是一个实例莫名其妙地变慢，或者把合法用户锁在外面，而日志里显示的却是一个 IP 在做所有事情。按照反向代理文档所说的那样，设置受信任代理列表和协议覆盖，各用一行配置，就能同时修好日志和防护机制。

受信任域名列表，是另一个值得真正理解、而不是照抄了事的设置。它是一份允许列表，列出实例会响应的主机名，之所以存在，是因为应用会用它收到的 Host 请求头，来拼出各种绝对 URL——密码重置链接、分享链接、联合功能的回调。如果不设限，这是一种众所周知、能让你自己的链接指向别处的手法。只添加你实际会用到的主机名，如果你发布了洋葱地址，也把它加进去，除此之外什么都不要加。

如果其中有些内容根本不该能从公网访问到，不要指望靠一条防火墙规则加祈祷来解决。有两个干净的答案：把实例放到一条 WireGuard 隧道后面，让它只能被持有密钥的设备访问到，这对个人档案库效果很好，但不适合对外人分享；或者把它作为一个洋葱服务，和明网主机名并列发布，让同步客户端能通过 Tor 继续工作，同时完全不暴露任何地址。两者都是可叠加的——你可以在保留一个正常公网主机名的同时运行其中任意一个，让敏感内容活在那条私密路径之后。

什么时候你不该自建这一套

一份从来不说这种话的指南，就是在推销什么东西，所以这里把清单列出来。如果这些数据属于一家企业，而这家企业的运营会随着文件服务器一起停摆，那你就是在用一台机器和一个人的注意力，去承保一份可用性保证，而单台 VPS 不是干这个的合适工具。这类应用要做到高可用，确实相当复杂——共享存储、复制的数据库、能理解会话保持的负载均衡器——如果你需要这些，你需要的是预算和第二个人，而不是一个更大的套餐。

如果没人会做每月的维护，就别开始。这份工作量很小——打上更新、瞄一眼管理概览、确认备份跑过了、每出一个新主版本就一个一个地升级——但要是被晾上一整年，它是不会轻易饶过你的。一个落后好几个主版本的实例，没法一步升级到位，与此同时也不该继续面向互联网，而从这种处境里脱身，要比原本按时做维护费的工夫多得多。

如果你的资料库以 TB 计并还在增长，那出问题的是形态，而不是大小。我们出售的 VPS 档位没有一档能到 1 TB 的本地 NVMe，而在实例背后硬接一个对象存储，只是把问题挪了个地方，没有解决它：数据库变得更加关键，每一次文件操作的延迟都会上升，而且你已经悄悄地把一个第三方重新引入了这套设计——而这套设计存在的全部意义，就是去掉一个第三方。要么买带镜像硬盘的专用服务器，要么就接受档案库和同步枢纽本来就是两套不同的系统。

还有，如果你真正想要的其实是 Google Docs 那种效果——三十个人同时在同一张表格里打字，光标延迟不到一秒——那就得对自己诚实：自建的办公套件是“好”，而不是“等价”，而且它需要独立的内存和独立的 CPU。运行它，是因为你想让文档留在自己的磁盘上，而不是因为你指望协作体验会一模一样。

至于其他所有人——一个厌倦了为自己的照片付租金的家庭、一个不想让自己的合同被某家设有政策部门的公司拿去建索引的小团队、一个只是单纯想让文件待在自己选的地方的个人——这是你能放到服务器上的、回报最丰厚的事情之一。这套软件很成熟，客户端也做得好，失败模式都有文档记录，唯一真正不饶人的，是那份从来没测试过的备份。开一台服务器大约只要一分钟，在你忙着给手机装好客户端的时候，预览图还在后台继续生成，而且你完全可以用买它所图的那份隐私姿态，去为它付款。