Why do large uploads to Nextcloud fail behind a reverse proxy?

Because one layer between the client and Nextcloud refuses a request that big, or that slow. Which layer it is depends on how the client uploads. The web UI and the desktop client cut a large file into chunks of 100 MiB (104,857,600 bytes), so only one chunk has to get through. curl and other plain WebDAV tools send the whole file in one request, so the whole file has to get through every layer at once.

Chunked upload or single PUT: the difference that decides the fix#

A request body limit is the largest upload a server or proxy accepts in one HTTP request. Above it, the layer answers 413 Request Entity Too Large and never passes the request on.

A single PUT is one WebDAV request that carries the whole file. curl does this, and so do most generic WebDAV clients.

A chunked upload is Nextcloud's own method. The client creates a temporary folder, sends the file in numbered pieces, one request each, and then sends a MOVE that tells the server to join them. The chunk size comes from files.chunked_upload.max_size, which the admin manual says defaults to 104857600.

Who uses which:

• Web UI. Chunks any file bigger than the chunk size. Its upload library reads the server's value, so the default is 100 MiB. A smaller file goes as one PUT.
• Desktop client. Starts at 100 MiB and adjusts the size during an upload. Its docs say a maximum set by the server takes precedence.
• rclone. Chunks since v1.63.0, with a default of 10 MiB (--webdav-nextcloud-chunk-size).
• curl, scripts, most WebDAV mounts. One PUT per file.

This is why forum threads go in circles. One person raises a limit and the web UI starts working. Someone else raises the same limit and their curl or WebDAV upload still fails. Both are right about their own client.

A worked example: one 1.5 GiB video, two clients#

Take Nextcloud in the official nextcloud:apache image, behind Nginx Proxy Manager, with every setting at its default.

From the web UI. The file is cut into 15 chunks of 104,857,600 bytes and a smaller last one. NPM's nginx.conf sets client_max_body_size 2000m, and the image's Apache allows 1 GiB per request. Each chunk is far below both, so the upload goes through.

From curl or an old rclone. The file goes as one request of 1,610,612,736 bytes. That is under NPM's 2000 MiB, so NPM passes it on. Apache then refuses it, because it is over 1,073,741,824 bytes. The reply carries Server: nginx, because nginx does not pass a backend's Server header to the client. So the error looks like it came from the proxy. The body says otherwise: "The requested resource does not allow request data with PUT requests". That text is Apache's.

The fix for this case is in the Nextcloud container, not the proxy: APACHE_BODY_LIMIT=0. If the same file is ever over 2000 MiB, NPM refuses it too, and then the proxy needs a higher limit as well.

Put Cloudflare's proxy in front of the same setup and the picture changes. Cloudflare documents a cap of 100 MB per request on Free and Pro. The single PUT is refused at the edge before it reaches your server. The chunked upload is close to the line, because a default chunk is 104,857,600 bytes. Lower the chunk size and the question goes away.

What answered, measured#

We ran Nextcloud 35.0.2 in nextcloud:apache with its defaults: PHP_UPLOAD_LIMIT=512M and APACHE_BODY_LIMIT=1073741824. In front of it went nginx 1.30.6, Caddy 2.11.7 and Traefik 3.7.15. We sent single PUTs with curl. For chunks we sent the requests the web UI's library sends: MKCOL, numbered chunk PUTs and a final MOVE. We did not drive a browser.

Three results are worth reading twice.

Exactly 104,857,600 bytes passes a 100 MiB limit. nginx with 100m and Traefik with 104857600 both accepted a single PUT and a chunk of exactly that size. 101 MiB was refused.

Caddy's 100MB is not 100 MiB. Caddy refused the 104,857,600-byte chunk, because MB there means a million bytes. The same Caddy accepted chunks of 100,000,000 bytes, and the 1,100 MiB file arrived in 12 of them. Write 100MiB in Caddy if you mean it.

PHP's limit never came into it. With APACHE_BODY_LIMIT=0, a 5 GiB PUT arrived while PHP_UPLOAD_LIMIT was still 512M. The admin manual agrees: upload_max_filesize and post_max_size "may not apply" to single PUTs or chunked uploads.

Behind nginx with 2000m, the 1,100 MiB PUT got Apache's 413 in 9 of 10 runs, after about 2 s. nginx first wrote the whole body to a temporary file, and its log said so: "a client request body is buffered to a temporary file". Only then did it pass the request to Apache, which refused it. In the tenth run Nextcloud answered instead, with a 400 saying it had read 0 bytes.

Joining chunks takes time too. The final MOVE for 5 GiB took 16.5 to 20.1 s on this host's local SSD. Slow disks take longer, and the proxy waits for that reply. The admin manual calls fastcgi_read_timeout "often the solution to 504 timeouts during MOVE transactions that occur even when using chunking".

Uploads that fail at 60 seconds: a time limit, not a size limit#

Some uploads die on the clock instead. Traefik's entry points have a readTimeout of 60 s, and its docs describe that as "the maximum duration for reading the entire request, including the body". We limited curl to 1 MB/s. A 101 MiB PUT through Traefik got 499 Client Closed Request after 60.06 s. So did a single 100 MiB chunk. The same 101 MiB PUT took about 101 s through Caddy and through nginx, and arrived both times.

On a home connection with 8 Mbit/s of upload, a 100 MiB chunk takes longer than a minute. Chunking does not save you here, because the limit applies to each request. Set the entry point's timeout to 0 (off) or to a long value:

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0

With readTimeout=0 the same slow chunk arrived. Caddy has no total upload timeout by default, but its docs give read_body_idle a default of 1m for an upload that stalls. nginx's client_body_timeout of 60 s also counts only the gap between two reads, not the whole upload.

How to tell which layer sent the 413#

Send one file with curl and look at the headers and the body:

curl -sS -D - -u alice:app-password -T test-1100M.bin \
  https://cloud.example.com/remote.php/dav/files/alice/test-1100M.bin

Never trust the Server header behind nginx. nginx's docs say it does not pass a backend's Server field to the client, so even Apache's own 413 arrives labelled nginx.

The fix, layer by layer#

The image's README says 0 means unlimited for APACHE_BODY_LIMIT, and the change applies when the container is recreated. Apache only got this limit in version 2.4.54. Up to 2.4.53 it was unlimited, which is why older guides never mention it.

For nginx, the example proxy config in the nextcloud/docker repository sets client_max_body_size 10G; and proxy_request_buffering off;. nginx's docs say that with buffering on, the entire request body is read from the client before the request goes to the backend. That is the temporary file from our log. Turning it off streams the upload instead.

In Nginx Proxy Manager, the 2000m lives in the shared nginx.conf. Put client_max_body_size 10G; in the proxy host's Advanced tab to raise it for that host only.

For Cloudflare, set the chunk size on the server and both the web UI and the desktop client follow it:

docker compose exec -u www-data app php occ config:system:set \
  --type int --value 52428800 files.chunked_upload.max_size

Cloudflare's docs offer three ways past the cap: smaller chunks, a DNS-only record, or a higher plan. Pangolin vs Cloudflare Tunnel compares a tunnel you host yourself, where your own proxy sets the limit.

When this answer stops applying#

• The FPM image. With nextcloud:fpm behind your own nginx, the FastCGI and PHP-FPM time limits join the chain. The admin manual's fastcgi_read_timeout advice is aimed at that setup. We tested only the Apache image.
• Cloudflare itself. We did not send traffic through Cloudflare. The cap and the 413 come from its docs. We did not test whether a chunk of exactly 104,857,600 bytes passes its "100 MB".
• Object storage as primary storage. Chunks are staged on local disk first. Nextcloud server issue 29589 describes a 26 GB upload filling a small /tmp.
• The macOS client with virtual files. If only that client fails above about 100 MB while the web UI works, that matches desktop issue 9883, which was still open when we checked. That is a client bug, not a proxy limit.
• Slow storage. Our MOVE timings come from a local SSD and will not carry over to a NAS or a USB disk.

What to do next#

Send one test file with curl and read the 413 body to find the layer. Fix that layer, then repeat until Nextcloud's own XML answers. If your users only use the web UI and the desktop client, a proxy limit of 101 MiB or more is enough. If anyone uses curl, WebDAV mounts or an older rclone, raise every layer, including APACHE_BODY_LIMIT. Reverse proxy and TLS covers the rest of the proxy setup. Nextcloud "Access through untrusted domain" behind a reverse proxy fixes the trusted domain and http:// redirect problems that usually turn up in the same week. If the proxy answers 502 or 504 instead of 413, Why Nginx Proxy Manager returns 502 Bad Gateway reads the log line for you.