LEARN. PRACTICE. GROW.Concept and mechanism
Begin with the failed phase and supporting evidence. 502 indicates an invalid upstream response received by a gateway; 504 indicates no timely response. Neither code alone proves database deadlock or DNS failure. Correlate identifier, endpoint, total time, and upstream timings with relevant logs. Avoid storing complete tokens and bodies by default: identifiers and bounded fields can support the required comparison. A 429 with Retry-After guides waiting and reduced pressure; bound attempts and concurrency according to contract and budget. The next attempt is not guaranteed to succeed merely because it waited.
Guided application
Interpret each metric definition. On a fresh direct HTTPS connection without proxy or redirects, curl time_connect and time_appconnect are cumulative milestones. At 0.15 and 0.35 seconds, their 0.20 difference approximates the TLS phase after TCP in that context. Connection reuse and other paths require additional care. In NGINX, proxy_read_timeout limits intervals between reads rather than the entire response duration. In a fictional case, the upstream stays silent for 75 seconds and the client gives up at 70. Raising only the proxy from 60 to 90 moves the failure. Investigate regression and define coherent end-to-end limits while retaining recovery criteria and functional validation.
A 75 s upstream exceeds a client with a 70 s deadline even if the proxy waits 90 s.
Common pitfalls
Adding cumulative milestones; confusing intervals with total duration; 504 as an identified cause; retries without a budget.
Related topics: The request and intended representation · Methods, statuses, and controlled retries · Caching, variants, and validation
Use metrics with known definitions and validate the complete request budget.
Reference: NGINX upstream response timing · DR HTTP/HTTPS 2026-09; HTTP RFCs 9110–9114; selected TLS 1.3 and NGINX/curl guidance