Users keep failing to upload hundreds of MB videos and see both 413 and 504: does raising the gateway limit alone help?

Opening conclusion: When users fail to upload hundreds of megabytes, 413 and 504 are often signals from two different layers: 413 means the request body exceeded a configured limit at some layer, while 504 means a node in the chain did not receive an upstream response or finish writing to disk within the set time. Based on common 2026 delivery experience, raising only the gateway size limit usually removes 413; timeouts, temporary file writes to disk, application memory, and object storage chunking then surface in turn. So locate the layer first, then decide whether to keep tuning parameters or switch to chunked upload.

Which layer reports 413 and 504? First distinguish the three layers

413 Request Entity Too Large generally happens before the request body has been fully read and is rejected directly by a reverse proxy or application framework; it is a “did not get through the door” error. 504 Gateway Timeout means the request has entered some layer, but that layer exceeded its threshold while waiting for the backend, waiting to write to disk, or waiting for an upstream response. The same upload code will report whichever error corresponds to the layer whose limit it hits first under different deployment shapes.

There is a simple way to distinguish them: look at when the response code is returned and where the logs appear. If 413 returns within a few seconds, it is most likely a size limit; if 504 appears only after the progress bar has moved most of the way, it is most likely a timeout or buffer-to-disk issue. If only one side has a log entry, the limit is on that side; if both sides have records, the request has already passed through to the inner layer.

• Entry gateway: request body limit, read timeout, whether buffering is enabled, and the temp directory used for buffering;
• Application and framework: multipart per-file and total size thresholds, temp directory, request body limit;
• Business processing: whether the entire stream is read into memory, object storage single-write timeout, chunk size, and retry policy.

Check in three layers: identify the layer first, then change only one parameter

Why divide from outside to inside? The outer layer decides whether the request can get in, the middle layer decides whether it can be accepted, and the inner layer decides whether processing can finish. Skipping the outer layer to change inner-layer parameters often produces no visible change, because the request is rejected at the outer layer; conversely, opening only the outer layer without checking the inner layer pushes the error to a later stage, making troubleshooting take longer.

1. Reproduce and record first: the response code, response time, and server identifier in the response headers in the browser network panel, while saving logs from both the gateway and application sides to confirm which side rejects first;
2. Check the entry gateway: request body limit, read timeout, buffering switch, and free space in the temp directory. Change only one layer at this step, then reproduce immediately once after the change;
3. Check the application layer: whether the framework request body settings, multipart thresholds, and temp directory quota are smaller than the gateway's;
4. Check the processing layer: whether it reads and writes to object storage as it streams, whether the single-write timeout is shorter than the wait time users can accept, and whether failed retries repeatedly occupy connections and disk.

Reproduce once after each layer change and record whether the error moves position; this is the main basis for judging whether you truly fixed it or only pushed the problem later. Raising parameters across all three layers at once commonly results in errors appearing at a later node, while the logs become no clearer.

Why raising the limit often just moves the error to another layer

In one project delivery, the constraints were like this: ops gave only one window to change configuration, the assets were several videos of hundreds of MB each, and it was not convenient to immediately roll out a chunked upload solution within budget and schedule. The usual approach is to raise the gateway request body limit from its default to cover a single file, then casually bump the read timeout from tens of seconds to several minutes. The 413 did disappear, but the error changed to 504 and the progress bar stuck at 80–90%—because with buffering enabled, the file first had to be written to the gateway temp directory, and the slow disk plus merge-to-disk time exceeded the timeout. That night they could only revert the configuration and add disk and timeout, then add chunked upload the next day, pushing the overall schedule back by about a day. This kind of process shows that parameter tuning can validate direction, but cannot replace solution selection.

Synchronous direct upload vs. chunked upload: choosing by scenario

The decision depends not only on file size, but also on network stability, whether resumable upload is needed, and whether compliance requires files to pass through the server. The comparison below gives experience ranges based on common delivery practices, for reference when estimating the amount of rework.

• File size and network: within tens of MB per file, on an intranet or stable network, synchronous direct upload is enough; hundreds of MB to GB level on mobile networks, chunked upload is more reliable;
• Gateway pressure: sending the whole file through the gateway occupies a connection for a long time and may trigger disk buffering; each chunk is smaller, spreading pressure across multiple requests;
• Resumable upload: if a synchronous direct upload disconnects, it basically needs to resend the whole file; chunked upload can retry by chunk, and the front end only needs to record completed chunk numbers;
• Implementation cost: synchronous upload needs almost no front-end changes; chunked upload must handle slicing, merging, state recording, and expired cleanup. Based on experience ranges, implementation plus integration typically adds a few days to two weeks, depending on team familiarity with object storage;
• Direct upload to object storage: the front end gets a temporary signature and uploads directly, while the server only handles signing and callback confirmation. It suits large public-network assets, but the single-file size limit, signature validity period, and content type must be written into the policy.

These forms are not mutually exclusive. A common practice in 2026 is: small files use synchronous upload, large files use chunked or direct upload, and the server keeps a metadata validation step to prevent clients from bypassing business rules and writing directly.

Pre-launch acceptance criteria: what counts as qualified

• Reproduce once under a real weak network and on mobile, not only on the office intranet;
• On failure, users see a clear message, not a stuck progress bar with no feedback;
• Under both success and failure paths, temp files and half-written objects are cleaned up;
• A single upload does not exhaust gateway connections, application memory, or disk quota;
• Retrying the same file does not create two records in the business database.

Putting these criteria into the delivery acceptance checklist is far more useful than verbally agreeing to “watch out for large files,” and it reduces back-and-forth during integration.

Applicable scenarios and boundaries

When to switch to chunked or direct upload: public-network users, single files often above tens of MB, unstable networks, and services that need resumable upload or instant upload. In these scenarios, the rework benefit usually covers the implementation cost.

When not to adopt it: intranet admin systems, Excel imports that are generally only a few MB, and low upload frequency. First pair the size and timeout settings of the gateway and application; forcing in chunked upload only increases front-end complexity and integration time.

Boundary statement: Whether to change the architecture does not depend on the file size limit number itself, but on whether failures affect core processes, whether retransmission is frequently required, and whether gateway disk and timeouts have repeatedly become bottlenecks.

Common questions

Upload fails with 413 halfway through, then becomes 504 after a change—did we configure something wrong?

Usually the limit has moved from one layer to the next: once the size limit is relaxed, the request actually starts transferring, and timeout and buffer-to-disk problems surface for the first time.

If chunked upload merging fails, will it leave a half-written file in storage?

Yes. A common practice is to make the object visible only after merging succeeds, set states and expiration cleanup for upload sessions, and have a scheduled task reclaim failed chunks.

With front-end direct upload to object storage, does the server no longer need to care about file size?

No. When signing, you must include the single-file size limit, validity period, and content type restrictions, and configure bucket-side policies too; otherwise you are handing control of limits to the client.

For an intranet system uploading a tens-of-MB Excel file, does it also need chunked upload?

Generally not. Intranet bandwidth is stable and failures can be retried; it is more cost-effective to first pair-check the size and timeout settings of the gateway and application.

How can you tell whether the connection was cut by a timeout or by a firewall?

Check whether the timestamps in the logs on both sides match. A timeout usually has a clear duration boundary, while a middle-device disconnect often appears as a connection reset with no corresponding record at the application layer.

If this is the first time you are dealing with it, check the gateway, application, and processing layers once each before deciding whether to change parameters or change the solution. Only when public network, large assets, and resumable upload needs all hold true is chunked or direct upload worth scheduling. For intranet small-file scenarios, prioritize clear messaging and thorough temp file cleanup; do not add delivery complexity just to make the architecture look good.