⌚ About 2 min read
A 504 must be broken down between the proxy network and backend processing time.
Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.
Étapes à suivre
-
1
Identify the component that returns 504
Proxy, CDN or load swing.
-
2
Tester backend direct
If possible without bypassing security.
-
3
Measure duration
Find the timeout threshold.
-
4
Read /10 application
Look for slow request or dependency.
Commands utiles
Ü -I https://example.com
À retenir
- Adding timeout is not a lasting correction.
- Compare with CPU, DAB and backend network.
HTTP 504 / 429: distinguish upstream timeout from rate limiting
Technical checkpoints
- 504 usually means a proxy/gateway did not receive an upstream response in time; the code is produced by the intermediary, not necessarily the final application.
- 429 means the client exceeds a rate/quota policy; Retry-After, rate-limit headers and client identity are important.
- Total time should be split into DNS, connect, TLS, backend wait and transfer to locate a 504.
curl timing
Measure phases rather than only the final status code.
curl -sS -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} start:%{time_starttransfer} total:%{time_total}\n" https://example.com/Topic-specific pitfalls
- Increasing every timeout may only make failure slower if the backend is actually stuck.
- Trying to bypass a 429 with more concurrency often worsens throttling.
How to validate
- For 504, latency or failure is localized to a specific chain component.
- For 429, the client respects quota/Retry-After and the error rate drops.