Nextcloud WebDAV Is Slow: The Causes, in Order

Start with the fix Nextcloud itself documents

Before touching PHP, Redis or your reverse proxy, check which password your WebDAV client is sending. Nextcloud's own user manual, which we read in September 2026 at version 36, lists this under 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.

The reason is in the same passage: a regular password "carries a significant performance penalty because Nextcloud must perform additional work to verify it on every request", and an app password "removes this overhead and can improve transfer speeds substantially". Every request. A folder listing in Finder is hundreds of requests, so the penalty is paid hundreds of times.

To create one: log in to the web interface, click your avatar, choose Personal settings, open Security in the left sidebar, scroll to the bottom, create an app password, and use that in the client. It can be revoked later without changing your login.

While you are there, confirm the URL. For third-party clients the documented form is https://cloud.example.com/remote.php/dav/files/USERNAME/, or with a subdirectory install https://example.com/nextcloud/remote.php/dav/files/USERNAME/. Nextcloud also shows it to you: Files settings, under WebDAV.

Client side, which is where most of the time actually goes

Nextcloud says the quiet part out loud about third-party clients: they "may not be optimized for use with Nextcloud". Three specific behaviours account for most complaints.

1. macOS Finder. Finder asks for far more than a directory listing — repeated property requests per entry, a .DS_Store read and write per folder, and a probe for the AppleDouble sibling of nearly every file. Several hundred files becomes over a thousand round trips before any file content moves. The arithmetic and the one defaults command worth running are on why WebDAV is slow in macOS Finder. Nothing on the Nextcloud server changes this.
2. The Windows redirector. Two documented ceilings, neither of them performance: net use returning System error 67 means the WebClient service is not running, and Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved means FileSizeLimitInBytes in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters is still at its default. Nextcloud's own instruction is to set it in Decimal to 4294967295, the 4 GB maximum, and reboot or restart the WebClient service. What changed on Windows 11 is on WebDAV not working on Windows 11; the size ceiling has its own page.
3. `davfs2` on Linux. It caches locally, so a write can look instantaneous while the upload is still running — the mount is not fast, it is lying politely. And if creating a file returns Resource temporarily unavailable, the documented fix is use_locks 0 in /etc/davfs2/davfs2.conf. For a self-signed certificate, copy the .pem into /etc/davfs2/certs/ and point servercert at it rather than disabling verification.

One more documented oddity, so you stop chasing it: a mapped Nextcloud drive on Windows shows the size and free space of your C: drive. Nextcloud calls this "a limitation of WebDAV itself, because it does not provide a way for the client to retrieve available free space from the server."

Server side: PHP-FPM, locking and chunking

If the app password did not help and the client is not the bottleneck, the server has three documented pressure points.

1. PHP-FPM worker count. Nextcloud's tuning page is blunt: the default pool has pm.max_children = 5, which "limits Nextcloud to five simultaneous PHP requests and is a common cause of gateway timeouts, slow page loads, and sync client errors under any real load". Estimate the value from RAM — the docs put a typical worker at 50–100 MB — and note that they advise against pm = ondemand, because clients poll every 30 seconds and keep paying cold-start latency.
2. Transactional file locking on the database. Locking "will use the database locking backend by default. This places a significant load on your database. Setting memcache.locking relieves the database load and improves performance." The documented backends are Redis or Valkey; Memcached is explicitly ruled out because "it is not designed to store locks".
3. Chunked uploads, and the PHP limits that do not apply. The docs state that upload_max_filesize and post_max_size "may not apply to file uploads through WebDAV single file PUT requests or Chunked file uploads. For those, PHP and webserver timeouts are the limiting factor on the upload size." Raising those two fixes nothing for WebDAV. The knob that exists is the chunk size, default 104857600 (100 MiB).
4. Two smaller ones. loglevel in config.php defaults to 2 (WARN), and a 0 left behind after troubleshooting "outputs a lot of information, and can affect your server performance". And on SQLite the docs recommend moving to MariaDB, MySQL or PostgreSQL "because of the performance limitations of SQLite with highly concurrent applications, like Nextcloud".

'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

One thing you do not need to install: a PHP opcache. Zend OPcache has been bundled since PHP 5.5.

Network: TLS, SNI and the reverse proxy

1. nginx timeouts during `MOVE`. Chunked uploads finish with a MOVE that assembles the parts, and that request can take a long time on a large file. The docs name the setting: fastcgi_read_timeout is "often the solution to 504 timeouts during MOVE transactions that occur even when using chunking". client_max_body_size also has to be raised for non-chunked uploads.
2. Apache's body limit. LimitRequestBody defaults to 1 GiB in newer Apache versions, where 2.4.53 and earlier were unlimited. A single PUT above that fails regardless of PHP.
3. Two TLS problems specific to the Windows client. Nextcloud documents that the Windows WebDAV client "might not support Server Name Indication (SNI) on encrypted connections" — so a Nextcloud sharing an IP with other TLS hosts may simply refuse to mount — and that it "might not support TLSv1.1 and TLSv1.2 connections", so a server restricted to modern TLS can fail to connect at all. Both present as failures rather than slowness, which is exactly why they waste an afternoon.
4. Output buffering. The docs require output_buffering = 0 in .htaccess, .user.ini or php.ini, "or PHP will return memory-related errors" on large uploads.

The honest alternative: stop using WebDAV for sync

Nextcloud's manual opens with its own recommendation, and it is not WebDAV: "The recommended way to synchronize a computer with a Nextcloud server is by using the official Nextcloud sync clients." The desktop client keeps a local copy, batches requests, resumes, and does not pay per-request auth overhead the way a mounted volume does. If the goal is "my Nextcloud files on this laptop", it beats any WebDAV mount and the comparison is not close.

WebDAV earns its place when you need the files without a local copy — a 2 TB instance on a 256 GB laptop, or an application that wants a path rather than a sync folder. For that case, a desktop client that talks WebDAV over the network and serves the mount from loopback removes a whole layer of per-request latency. That is how AnyStorage does it: Nextcloud is configured once with its remote.php/dav/files/USERNAME/ URL and an app password, and for a mounted volume the app runs its own WebDAV server locally — sidebar, Services, WebDAV tab, Start, default http://127.0.0.1:3211, Basic authentication always on with username anystorage and a 24-character generated password. No macFUSE, no WinFsp, no admin rights.

Stated honestly: a 0.2.x application, young next to Nextcloud's own client. The free tier allows two connections and serves that mount read-only — writing back needs Pro — and permits commercial use. It runs on macOS 11+, Windows 10+ and Ubuntu 20.04+. The general argument is mount cloud storage as a local drive; choosing a WebDAV client is the protocol hub.

Next steps

If the slowness is really your file manager: why WebDAV is slow in macOS Finder. If it is Windows refusing rather than crawling: WebDAV not working on Windows 11 and the 50 MB limit. If the server on the other end is a NAS rather than Nextcloud: NAS WebDAV setup and speed.