HTTP 504 Gateway Timeout vs. Your Client’s Timeout
Distinguish a gateway's timed-out upstream request from the timeout configured in your own proxy client.
Your client is willing to wait sixty seconds. Ten seconds later, it receives HTTP 504. Increasing the client's timeout to two minutes does not give the gateway another fifty seconds to work.
504 describes a gateway or proxy that did not receive a timely upstream response while trying to complete the request. The gateway has already made its decision and returned a response. Your client can read that response successfully.
Which intermediary returned it?
The forward proxy may be the issuer. So might a later gateway operated by the website. With ordinary end-to-end TLS inside CONNECT, an HTTP response from within that protected destination exchange is not the same as a rejection of CONNECT itself.
Keep the stage, response headers, error-page wording, and matching logs where available. A server label can be a clue, but should not be treated as infallible attribution. The route may contain more intermediaries than the one configured in your client.
Then inspect why that upstream operation failed to complete. Reachability, overloaded services, a request body the upstream cannot process as expected, and application behavior can all matter. The numeric status alone does not prove that changing a User-Agent or adding one timeout option is the universal fix.
Compare the same request
When another tool works, compare method, target, body encoding, authentication, and route. “The URL opens in a browser” is not a complete comparison with a multipart submission through a service client.
If you operate the issuing gateway, align its upstream budget with the supported workload and the surrounding deadlines. If you do not, keep its result as evidence and use the operator's documented access or support path. Waiting longer locally cannot change a response that has already arrived.