504 Gateway Timeout during long-polling upstream responses

In an Nginx HTTP proxy configuration, the proxy_read_timeout directive is used to manage the duration the proxy waits for a response from the proxied server. This is critical for applications utilizing long-polling or streaming data where the upstream server may maintain an open connection without sending data for extended periods.

The current behavior resets the timeout timer whenever new data is received. However, in scenarios where the upstream server is intentionally silent for a duration that exceeds the proxy_read_timeout but is still processing a valid request, Nginx terminates the connection and returns a 504 Gateway Timeout.

When balancing the need to prevent worker connection exhaustion against the requirement for long-lived upstream responses, the following uncertainties arise:

• Is there a mechanism to implement a hard request timeout that differs from the incremental read timeout?
• How does the interaction between proxy_read_timeout and keep-alive settings affect the frequency of 504 errors during periods of upstream inactivity?