Nextcloud 的 WebDAV 很慢：按顺序排查

先做 Nextcloud 自己写明的那一步

在动 PHP、Redis 或反向代理之前，先看你的 WebDAV 客户端送的是哪个密码。2026 年 9 月我们读到的用户手册（版本 36）在 Known problems 里写着：

Problem:  WebDAV access is very slow or times out.
Solution: When using a third-party WebDAV client (including your
          operating system's built-in client), you should authenticate
          with an application password rather than your regular
          account password.

原因就在同一段：用常规密码会带来「a significant performance penalty」，因为 Nextcloud「must perform additional work to verify it on every request」。是每一个请求。Finder 展开一个文件夹就是几百个请求，这笔开销要付几百遍。换成应用专用密码，这层校验开销就没了。

创建方法：登录网页端，点头像，进 Personal settings > Security，拉到最底部生成一个应用专用密码，填进客户端。以后可以单独吊销，不用改登录密码。

顺手确认地址。第三方客户端的形式是 https://cloud.example.com/remote.php/dav/files/USERNAME/，装在子目录里则是 https://example.com/nextcloud/remote.php/dav/files/USERNAME/。你的账号里 Files settings 的 WebDAV 也会直接显示它。

客户端：时间其实大多花在这里

Nextcloud 对第三方客户端的评价是直白的：它们「may not be optimized for use with Nextcloud」。抱怨的大头是三种行为。

1. macOS 的 Finder。 Finder 要的远不止一个目录列表：逐项重复的属性请求、每个文件夹一次 .DS_Store 读写、几乎对每个文件都探一次 AppleDouble 兄弟文件（._ 前缀）。几百个文件就意味着在任何内容开始传输之前先来上千次往返。算式和唯一值得跑的那条 defaults 命令在 macOS Finder 上 WebDAV 为什么这么慢，服务端怎么调都改不了它。
2. Windows 重定向器。 两个写明的上限，都不是性能问题。net use 返回 System error 67 说明 WebClient 服务没跑；Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved 说明 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters 下的 FileSizeLimitInBytes 还是默认值。Nextcloud 的指示是选 Decimal 填 4294967295（4 GB 上限），然后重启系统或重启 WebClient 服务。Windows 11 上变了什么见 Windows 11 上 WebDAV 不能用，大小上限见 50 MB 限制专页。
3. Linux 的 `davfs2`。 它在本地缓存，所以写入看着瞬间完成、其实还在上传——不是挂载快，是它在礼貌地撒谎。创建文件返回 Resource temporarily unavailable 时，文档给的做法是在 /etc/davfs2/davfs2.conf 里写 use_locks 0。自签证书应该把 .pem 放进 /etc/davfs2/certs/ 再用 servercert 指过去，而不是关掉校验。

还有一个别再去追的行为：Windows 上映射的 Nextcloud 驱动器显示的是 C: 盘的容量和剩余空间。Nextcloud 说这是「a limitation of WebDAV itself, because it does not provide a way for the client to retrieve available free space from the server」。

服务端：PHP-FPM、文件锁与分块上传

如果换了应用专用密码没改善，客户端也不是瓶颈，官方文档点名的压力点有这几个。

1. PHP-FPM 的 worker 数。 默认池是 pm.max_children = 5，也就是同时只能处理 5 个 PHP 请求。文档把它称作「a common cause of gateway timeouts, slow page loads, and sync client errors」。合适的值按内存估：文档给的单个 worker 是 50–100 MB。并且明确不建议 Nextcloud 用 pm = ondemand，因为客户端每 30 秒轮询一次，会不断触发冷启动。
2. 建在数据库上的事务性文件锁。 锁的默认后端是数据库，而这「places a significant load on your database」；设置 memcache.locking 能降低数据库负载并提升性能。官方后端是 Redis 或 Valkey，Memcached 被明确排除，理由是「it is not designed to store locks」。
3. 分块上传，以及那两个其实不生效的 PHP 设置。 upload_max_filesize 和 post_max_size 对 WebDAV 的单请求 PUT 和分块上传可能不适用，文档说此时「PHP and webserver timeouts are the limiting factor on the upload size」。所以调这两个对 WebDAV 没用。真正存在的旋钮是分块大小，默认 104857600（100 MiB）。
4. 两个小的。 config.php 里 loglevel 默认是 2（WARN），排障后忘了从 0 改回来会输出大量信息并影响服务器性能。还在用 SQLite 的实例，文档以「高并发应用下 SQLite 的性能限制」为由建议迁到 MariaDB、MySQL 或 PostgreSQL。

'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => ['host' => 'localhost', 'port' => 6379],

sudo -E -u www-data php occ config:system:set --type int --value 20971520 files.chunked_upload.max_size

要处理大文件，php.ini 里的 max_input_time 和 max_execution_time 也在调整名单上，文档建议按长时间上传的需要放大，给的例子是 3600 秒。反过来，有一样东西不用装：PHP 的 opcache。Zend OPcache 从 PHP 5.5 起就随本体附带。

网络：TLS、SNI 与反向代理

1. `MOVE` 时的 nginx 超时。 分块上传最后用一个 MOVE 把分片拼起来，大文件时这一个请求会很久。文档直接点出设置名：fastcgi_read_timeout 是「often the solution to 504 timeouts during MOVE transactions that occur even when using chunking」。不分块的上传还要放大 client_max_body_size。
2. Apache 的请求体上限。 LimitRequestBody 在较新的 Apache 上默认 1 GiB（2.4.53 及更早是无限制）。超过这个值的单个 PUT 与 PHP 设置无关，照样失败。
3. Windows 客户端特有的两个 TLS 问题。 Nextcloud 写明 Windows 的 WebDAV 客户端「might not support Server Name Indication (SNI)」，也「might not support TLSv1.1 and TLSv1.2 connections」。前者会让与其他 TLS 站点共用 IP 的 Nextcloud 根本挂不上，后者会让只开放新版 TLS 的服务器连不上。两者表现为连不上而不是慢，所以特别容易浪费一个下午。
4. 输出缓冲。 文档要求在 .htaccess、.user.ini 或 php.ini 里设 output_buffering = 0，否则大文件上传会返回内存相关的错误。

诚实的替代方案：别用 WebDAV 做同步

Nextcloud 手册开头就给出了自己的推荐，而那不是 WebDAV：推荐用「the official Nextcloud sync clients」。桌面客户端在本地留副本、把请求合批、能断点续传，也不像挂载那样为每个请求付认证开销。如果你的目标是「把 Nextcloud 的文件放到这台笔记本上」，它会赢过任何 WebDAV 挂载，而且不是接近的比较。

WebDAV 真正的用处是在不留本地副本的前提下拿到文件：256 GB 的笔记本对 2 TB 的实例，或者某个只认路径、不认同步文件夹的软件。这种场景下，一个在真实网络上说 WebDAV、再从 loopback 把挂载交给系统的桌面客户端能少掉一整层逐请求延迟。AnyStorage 就是这个形状：Nextcloud 用 remote.php/dav/files/USERNAME/ 地址加一个应用专用密码配置一次；需要挂载卷时，应用在你自己的机器上跑 WebDAV 服务器——侧栏 Services、WebDAV 标签、Start，默认 http://127.0.0.1:3211，Basic 认证始终开启，用户名 anystorage，密码是生成的 24 位随机串。不需要 macFUSE、WinFsp 或管理员权限。

说清楚：这是一个 0.2.x 的年轻应用，和 Nextcloud 自家客户端比没有资历。免费版最多两个连接，挂载是只读的（写回需要 Pro），允许商业使用；支持 macOS 11+、Windows 10+ 与 Ubuntu 20.04+。一般性的论述见 把云存储挂载为本地磁盘，协议总览页是 WebDAV 客户端怎么选。

接着读

如果慢的其实是文件管理器：macOS Finder 上 WebDAV 为什么这么慢。如果 Windows 是拒绝而不是慢：Windows 11 上 WebDAV 不能用 和 50 MB 限制。如果对面是 NAS 而不是 Nextcloud：NAS 的 WebDAV 设置与速度。