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 のフォルダー表示1回が数百リクエストなので、そのペナルティは数百回払われます。アプリパスワードなら、この検証コストがなくなります。

作り方は、ウェブ画面にログインしてアバターをクリックし、Personal settings > Security を開いていちばん下までスクロール、アプリパスワードを作ってクライアントに設定するだけ。後からログインパスワードを変えずに失効させられます。

URL も同時に確認してください。サードパーティ製クライアント向けの形は 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」とはっきり書いています。よくある訴えの大半は次の3つです。

1. macOS の Finder。 Finder はディレクトリ一覧だけを要求しません。エントリごとの繰り返しのプロパティ要求、フォルダーごとの .DS_Store 読み書き、そしてほぼ全ファイルについて AppleDouble 側（._ 付き）の探索。数百ファイルなら、中身が1バイトも動く前に千回以上の往復になります。計算と、実行する価値がある defaults コマンドは macOS の Finder で WebDAV が遅い理由 にあります。サーバー側の設定では変わりません。
2. Windows のリダイレクター。 公開されている上限が2つあり、どちらも性能の話ではありません。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 で指すのが正しく、検証を切るのは間違いです。

追いかけなくていい仕様がもう1つ。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、ロック、チャンク分割

アプリパスワードで改善せず、クライアントもボトルネックでないなら、公開ドキュメントが名指ししている圧力点は3つ（＋小さいものが2つ）です。

1. PHP-FPM のワーカー数。 既定のプールは pm.max_children = 5、つまり同時に処理できる PHP リクエストは5本だけです。ドキュメントはこれを「a common cause of gateway timeouts, slow page loads, and sync client errors」と呼んでいます。適正値は RAM から見積もり、ワーカー1つは 50〜100 MB が目安。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」と書いています。この2つを上げても WebDAV には効きません。存在するつまみはチャンクサイズで、既定値は 104857600（100 MiB）です。
4. 小さいもの2つ。 config.php の loglevel の既定は 2（WARN）で、切り分け後に 0 のまま残ると出力量がサーバー性能に影響します。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 秒を挙げています。逆に、入れる必要がないものが1つあります。PHP の opcache です。Zend OPcache は PHP 5.5 から本体に同梱されているので、別途インストールするものではありません。

ネットワーク側：TLS、SNI、リバースプロキシ

1. `MOVE` での nginx タイムアウト。 チャンクアップロードは最後に MOVE でパーツを結合し、大きなファイルではこの1リクエストが長時間かかります。ドキュメントは設定名まで書いています。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 問題2つ。 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」を使うのが推奨だと書かれています。デスクトップクライアントはローカルにコピーを持ち、リクエストをまとめ、再開もでき、マウントのようにリクエストごとの認証コストを払いません。目的が「このノート PC に Nextcloud のファイルを置く」なら、どの WebDAV マウントよりも速く、比較にもなりません。

WebDAV が効くのはローカルコピーを持たずにファイルへ届きたいときです。256 GB のノート PC と 2 TB のインスタンス、あるいは同期フォルダーではなくパスを欲しがるアプリ。その用途なら、ネットワーク越しに WebDAV を話すデスクトップアプリが loopback からマウントを出す形で、リクエストごとの遅延の層を1つ減らせます。AnyStorage はその形です。Nextcloud を remote.php/dav/files/USERNAME/ の URL とアプリパスワードで一度だけ登録し、マウントが欲しければアプリが自分のマシン上で WebDAV サーバーを動かします。サイドバーの Services、WebDAV タブ、Start、既定は http://127.0.0.1:3211、Basic 認証は常に有効でユーザー名 anystorage、パスワードは生成される24文字。macFUSE も WinFsp も管理者権限も不要です。

正直に書くと 0.2.x の若いアプリで、Nextcloud 公式クライアントと比べれば歴史はありません。無料プランは接続2つまで、マウントは読み取り専用（書き戻しは Pro）、商用利用は可能。macOS 11+、Windows 10+、Ubuntu 20.04+ で動きます。一般論は クラウドストレージをローカルドライブとしてマウントする、ハブは WebDAV クライアントの選び方 です。

次に読むもの

遅さの正体がファイルマネージャーなら macOS の Finder で WebDAV が遅い理由。Windows が「遅い」ではなく「拒否する」なら Windows 11 で WebDAV が動かない と 50 MB 制限。向こう側が Nextcloud ではなく NAS なら NAS の WebDAV 導入と速度 です。