429 heißt, dass eine Grenze erreicht wurde. Die nützliche Frage ist: wessen Grenze — Ihr eigener Webserver, ein vorgelagerter Proxy oder ein CDN, eine API, die Sie aufrufen, oder die Anwendung selbst. Jedes verlangt eine andere Lösung, und die Antwort-Header sagen meist, welche.

Lesen Sie zuerst die Antwort

curl -sSI https://yourdomain.com/api/thing | grep -i -E 'retry-after|ratelimit|x-'

Retry-After sagt Ihnen, wie lange Sie warten sollen. Die RateLimit-Header nennen die Obergrenze und den Rest. Ein 429 ohne solche Header stammt meist von Ihrem eigenen Server oder einem Proxy, der nicht so eingerichtet wurde, dass er sich erklärt.

Wenn es Ihr eigenes Nginx ist

grep "limiting requests" /var/log/nginx/error.log | tail
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
}
Hinter einem CDN oder Load Balancer ist $binary_remote_addr der PROXY — alle Besucher teilen sich also einen Eimer, und eine Handvoll von ihnen löst die Grenze für alle aus. Richten Sie zuerst die echte Client-Adresse ein — siehe Cloudflare und die echte Besucher-IP.

Wenn Sie derjenige sind, der begrenzt wird

  • Halten Sie sich an Retry-After. Sofort erneut zu versuchen verlängert die meisten Sperren.
  • Warten Sie exponentiell länger, mit Zufallsstreuung, damit eine Flotte von Workern nicht im Gleichschritt erneut anfragt.
  • Cachen Sie, was Sie holen. Die meisten Ratengrenzen werden erreicht, indem dieselbe Frage immer wieder gestellt wird.
  • Bündeln Sie, wo die API es kann — ein Aufruf für fünfzig Datensätze statt fünfzig Aufrufe.
for i in 1 2 3 4 5; do
  curl -fsS "$URL" && break
  sleep $(( (2 ** i) + RANDOM % 3 ))
done

Wenn es ein Login-Endpunkt ist

Dann funktioniert es wie vorgesehen. Siehe Ratenbegrenzung für einen Login-Endpunkt.