How to Match Reverse-Proxy Timeouts to Large Photo and Video Uploads

Set proxy timeouts from the slowest legitimate upload you will accept, with margin, and keep the application and any upstream proxy at least as permissive. Do not fix every failed upload by choosing an unlimited timeout.

A large photo or video can fail while the same app works normally because the request body, upstream processing, or response crosses a different limit. Capture the status code, elapsed time, file size, and proxy log first. Those observations distinguish a body-size rejection from an idle timeout, backend timeout, or client disconnect.

Identify the stage that ends the upload

Repeat with one known file and note whether failure occurs during transfer, after the progress bar reaches 100 percent, or while the server processes media. Each phase maps to a different connection and timeout.

A consistent failure at the same byte count suggests a body-size limit; failure after the same idle interval suggests a timeout. A gateway error after upload completion points toward the proxy-to-application wait or the application's own processing limit.

Read the proxy access and error logs together with application logs. If the client closed the connection first, raising only the proxy timeout cannot help; verify mobile background behavior, VPN stability, and the browser's request path.

Measure a defensible timeout budget

Divide the largest accepted file by the slowest supported upstream rate to estimate transfer time, then add room for TLS, buffering, and variable throughput. Use this as a ceiling for legitimate work, not a promise that every slow connection should remain open forever.

Distinguish total duration from idle duration. For example, NGINX documents separate proxy timeout directives, and some measure the gap between successive operations rather than the duration of the entire response.

Keep denial-of-service risk in view. Restrict upload endpoints through authentication and rate controls before substantially extending connection lifetimes, and do not expose the proxy's administration interface.

Align every layer without overcorrecting

Set the request-body size at or above the application's supported maximum. Then align client-body, upstream connect, upstream read, and upstream send timeouts according to the observed failure phase.

Check for an outer CDN, tunnel, load balancer, or second reverse proxy with a shorter immutable limit. The effective limit is the smallest one in the chain, so changing the inner proxy alone may produce no observable result.

Keep application URLs and proxy routes documented. The ZimaSpace guide for Immich on a network share helps separate upload-path errors from storage-mount latency and outages.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Retest slow, large, and interrupted uploads

Upload the original failing file at the original location and network speed. A pass requires completion, application indexing, and a playable or viewable asset—not just an HTTP success code.

Throttle a test connection to the minimum supported rate and repeat. Then interrupt one upload deliberately; temporary files and incomplete database records should be cleaned up according to application behavior.

Stop increasing timeouts when logs show a backend crash, storage error, or fixed outer-provider limit. Roll back excessive values, fix the failing layer, and retain the smallest timeout that consistently covers the measured workload.

FAQ

Should all proxy timeouts use the same value? No. Connection establishment, client-body reads, upstream response waits, and downstream sends protect different phases.

Why does a small photo work while a video fails? The video may cross a body-size threshold, take longer than an idle limit, or trigger longer server-side processing; logs and failure timing identify which one.