Ce guide montre comment diagnostiquer HTTP 429 et le rate limiting à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. 504 signifie généralement qu’un proxy/gateway n’a pas reçu de réponse amont à temps ; le code est produit par l’intermédiaire, pas forcément par l’application finale.
Étapes à suivre
-
1
Identifier les critères déterminants
504 signifie généralement qu’un proxy/gateway n’a pas reçu de réponse amont à temps ; le code est produit par l’intermédiaire, pas forcément par l’application finale.
-
2
Recouper le contexte technique
429 signifie que le client dépasse une politique de débit/quota ; Retry-After, headers de rate limit et identité du client sont importants.
-
3
Mesure curl
Mesurer les phases plutôt que seulement le code final.
-
4
Écarter les erreurs de diagnostic
Augmenter tous les timeouts peut seulement rendre l’échec plus lent si le backend est réellement bloqué.
-
5
Valider le résultat
Pour 504, la latence ou erreur est localisée sur un composant précis de la chaîne. Pour 429, le client respecte le quota/Retry-After et le taux d’erreur retombe.
Commandes utiles
curl -sS -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} start:%{time_starttransfer} total:%{time_total}\n" https://example.com/
À retenir
- Le temps total doit être découpé entre DNS, connexion, TLS, attente backend et transfert pour localiser un 504.
- Contourner un 429 avec plus de concurrence aggrave souvent la limitation.
- Pour 429, le client respecte le quota/Retry-After et le taux d’erreur retombe.
HTTP 504 / 429 : distinguer timeout amont et limitation de débit
Repères techniques
- 504 signifie généralement qu’un proxy/gateway n’a pas reçu de réponse amont à temps ; le code est produit par l’intermédiaire, pas forcément par l’application finale.
- 429 signifie que le client dépasse une politique de débit/quota ; Retry-After, headers de rate limit et identité du client sont importants.
- Le temps total doit être découpé entre DNS, connexion, TLS, attente backend et transfert pour localiser un 504.
Mesure curl
Mesurer les phases plutôt que seulement le code final.
curl -sS -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} start:%{time_starttransfer} total:%{time_total}\n" https://example.com/Pièges spécifiques
- Augmenter tous les timeouts peut seulement rendre l’échec plus lent si le backend est réellement bloqué.
- Contourner un 429 avec plus de concurrence aggrave souvent la limitation.
Comment valider
- Pour 504, la latence ou erreur est localisée sur un composant précis de la chaîne.
- Pour 429, le client respecte le quota/Retry-After et le taux d’erreur retombe.