How Many Reverse-Proxy Worker Connections Do Resumable Uploads Need?
There is no safe universal worker-connection number for resumable uploads. Size it from the highest simultaneous socket demand you can reproduce, then add measured headroom.
On a home server, a single visible upload may hold a client connection, an upstream connection, and idle time between chunks while the browser retries or resumes. Begin with live connection counts during the busiest normal upload window, compare them with the proxy and operating-system ceilings, and stop increasing the proxy setting if file descriptors, upstream workers, memory, or the application fail first.
Measure Live Upload Demand Before Choosing a Limit
Count connections during the workload that matters, not while the proxy is idle. Start the same number of uploads your household or small team is likely to run, pause and resume several transfers, and include any mobile client that reconnects after sleep. Record accepted client sockets, established upstream sockets, and connections waiting on an upstream response.
A worker limit is consumed by all open connections handled by that worker, not only by completed HTTP requests. That is why proxied server connections must be included in the measurement alongside client connections.
Use the highest repeatable total as the working baseline. If the total rises only during reconnect storms and falls quickly, keep that burst separate from sustained demand. If it keeps rising while upload throughput stays flat, do not call the growing number legitimate capacity; inspect the upstream application, timeouts, and stalled sessions before raising anything.
Translate Socket Demand Into Per-Worker Capacity
For a reverse proxy, one active upload commonly occupies a client-side connection and an upstream-side connection at the same time. HTTP keepalive, health checks, WebSocket sessions, and administrative traffic consume additional slots. Treat twice the simultaneous upload count as a starting model, not a finished answer, because your measured socket total is more reliable than a rule of thumb.
A visible worker connection ceiling can reject new clients even while established transfers continue. Compare the busiest worker with its configured limit, then check the service process's open-file limit; a larger proxy value cannot create file descriptors the process is not allowed to open.
Choose a target above the busiest repeatable worker, with enough room for the observed retry burst and ordinary non-upload traffic. Do not multiply by every possible client and chunk if those connections never exist simultaneously. If the operating-system ceiling is lower, align that layer first or keep the proxy target below it.
Test the Original Resume Path and Interpret the Failure
Repeat the exact trigger: start the full upload set, interrupt several clients, then resume them while the remaining transfers are active. Watch new-connection acceptance, retry timing, upload throughput, proxy error text, upstream response time, and open file descriptors. A synthetic request that never uploads a body does not test the same resource path.
If the proxy reports that worker connections are exhausted at the same moment new uploads fail, the limit is a supported bottleneck. If new requests fail with body-size, timeout, upstream-unavailable, or application queue errors while connection use remains below the ceiling, a higher worker setting will not fix the failure. A connection-limit calculation still has to respect the open-file limit and the proxy's two-sided sockets.
Change one layer at a time. Raise the worker limit only after the log and socket evidence identify it, reload the proxy, and rerun the same interruption pattern. If the error moves to the upstream service or file-descriptor ceiling, stop; you have reached the next constraint rather than proved that still more proxy connections are useful.
Keep Enough Headroom and Define the Stop Condition
Keep a margin between the busiest observed worker and the configured ceiling, but define it from real variation. A small server with stable household traffic needs less speculative reserve than a public service that receives unpredictable bursts. Record the baseline, target, worker count, process file limit, and peak result so the next change can be compared rather than guessed.
Connection capacity is only one layer of the upload path. When a dashboard works but a specific sync or upload path fails, the failing endpoint and method still need to be isolated before treating the proxy as healthy.
The change passes when two full resume tests complete, new connections remain accepted, error logs stay clear, and the busiest worker retains a stable margin. Roll back the increase if memory pressure or latency worsens without reducing failures. Escalate to the application or storage layer when connection use is comfortably below the limit but uploads still queue, time out, or corrupt their resume state.
Recommended products
Support & Tips
More to Read
How to Schedule Restic Backup, Forget, and Prune Jobs Without Lock Conflicts
A complete multi-host Restic schedule that separates frequent backups, scoped retention, physical prune, checks, retries, and restore validation.
How to Prevent Restic Prune Jobs From Blocking Scheduled Backups
A prevention plan for shared Restic repositories that separates backup windows from prune and keeps locking, retries, and alerts intact.
How to Clear a Stale Restic Lock Without Interrupting an Active Backup
A least-invasive Restic unlock workflow that protects active backups, removes only stale state, and confirms recovery under the normal schedule.
