A reverse proxy is a boundary, too
The questions to answer before copying another server block.
A reverse proxy makes several services look like one tidy system. It also creates a boundary: requests arrive from one place, identity information gets forwarded, and timeouts start interacting.
Before reaching for a familiar configuration, write down where that boundary is.
Three questions first
- Where is TLS terminated?
- Can the upstream application be reached without going through the proxy?
- Which proxy addresses does the application trust?
Forwarded headers are useful only when the application knows which sender is allowed to supply them. The right trusted-proxy configuration depends on the application and deployment, so this is not a setting to copy blindly.
WebSockets need an explicit upgrade
NGINX documents special handling for the Upgrade and Connection headers when proxying WebSockets. If ordinary requests work but a live interface never connects, inspect that path separately.
This is one of those bugs where “the page loads” is an incomplete test. Open the interface, trigger the live feature, and check the connection in the browser's network panel.
Keep the failure understandable
Choose timeouts to match the application. A long-running request, a streaming response, and a small API call have different needs. Avoid raising every timeout just to make one symptom disappear.
Keep access and error logs available, and retain enough context to trace a request across the boundary. The next debugging session should start with evidence, not with a guess about which service answered.
Reference: NGINX WebSocket proxying.