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 數。 預設的 pool 是 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 設定與速度。