pnpm Proxy Timeouts: Check Download Concurrency
Reduce unnecessary parallel pressure on a constrained proxy and distinguish request concurrency from per-origin connection limits.
If one package request works but an install produces timeouts, compare a smaller amount of parallel work over the same route before replacing the proxy. For a pnpm version supporting these project settings, a modest diagnostic starting point is:
networkConcurrency: 8
maxsockets: 4Use the location supported by the installed release, such as current pnpm-workspace.yaml. These numbers are illustrative, not measurements or a speed recommendation for your proxy.
| Setting | Resource |
|---|---|
networkConcurrency | Concurrent network work. |
maxsockets | Connections per origin: protocol, host and port. |
Run the same intended package operation and record connection errors, completed requests and retries. A cached second install cannot be compared as bandwidth against an uncached first download. Lower concurrency may help a constrained intermediary or merely slow a healthy run; there is no fixed improvement without workload evidence.
Check version behavior too. Current pnpm documents automatic concurrency and certain timeout-related adjustments, including treating traffic through the same proxy as one host for that adjustment. An explicit setting makes the experiment clearer but does not make every release schedule identically.
If even one request fails, investigate protocol, endpoint, authentication, TLS or target policy first. Parallelism limits cannot repair those failures.