| Tested on | RHEL 10.2 (Coughlan) |
|---|---|
| Package | kubectl v1.37.0Envoy Gateway v1.9.2ingress-nginx controller v1.15.1Gateway API CRDs v1.6.1 (standard channel) |
| Applies to | Any host with kubectl configured; any Kubernetes cluster that already runs Envoy Gateway |
| Assumes | An existing HTTPRoute, and ingress-nginx only when you are comparing an old timeout annotation |
| Privilege | Normal user |
| Scope | Which timeout page to open. Does not tune each clock. Those settings are on the pages linked below. |
| Related guides | Migrate proxy-read-timeout to Envoy Gateway Fix an Envoy Gateway 504 Fix a slow Envoy Gateway upload Migrate ingress-nginx to Envoy Gateway Gateway API with HTTPRoute |
Short on time?Beta
Get the gist of this 2-minute read in seconds, then ask follow-up questions
These are different clocks. A number copied from ingress-nginx lands on the wrong one often enough that each case has its own page.
- The response is HTTP 504 and the body is
upstream request timeout, usually at about 15 seconds. That istimeouts.request. - The client is still sending the body and the response is HTTP 408. On v1.9.2 the body was
request timeout. That isrequestReceivedTimeout. - You are moving
proxy-read-timeoutand want the same gap between upstream reads. That is nottimeouts.request. Start with the proxy-read-timeout migration. - The connection closes after the response, with no new request.
ClientTrafficPolicytimeout.http.idleTimeoutis that keep-alive clock. The default is one hour. It is not the 504 and it is not the upload timeout.
Summary
Open the 504 page when the backend is too slow to answer. Open the upload page when the request body is still arriving. Open the proxy-read-timeout page when the old annotation was a gap between reads and a long active response must keep working. Do not put one timeout number on all three.
