⌚ About 2 min read
This guide provides a structured method for diagnosing http 429 and the limiting spleen without multiplying unnecessary changes.
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
Set perimeter
Identify the equipment, service, affected users and start time.
-
2
Collect Elements
Record the exact messages, logs and useful settings.
-
3
Test methodically
Start with the basic dependencies before the application components.
-
4
Apply correction
Change only the identified parameter or component.
-
5
Validate
Rewrite the full scenario and document the result.
À retenir
- Keep the initial values for a backwards.
- Avoid multiple simultaneous changes.
- Compare with a functional configuration when possible.
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.