Ratenbegrenzung konfigurieren
Pro-IP-Obergrenzen je Anwendung und je Route setzen, die Reihenfolge der Grenzen verstehen und begrenzte Anfragen nachvollziehen.
obhut begrenzt Anfragen am Edge pro Client-IP mit einem Token-Bucket — bevor sie Ihren Origin erreichen. Sie konfigurieren eine Obergrenze je Anwendung und optional strengere Grenzen je API-Route.
Eine Ratenbegrenzung bremst Lastspitzen pro IP. Sie unterscheidet nicht zwischen legitimen und bösartigen Anfragen und kann eine verteilte Quelle nicht stoppen. Für Bot-Erkennung nutzen Sie obhut Gate.
Grenze je Anwendung
Es gibt genau drei Auswahlmöglichkeiten:
| Auswahl | Wert |
|---|---|
| Aus | keine Grenze auf Anwendungsebene (null) |
| Starter | 600 pro Minute und IP (Eimer fasst 600, füllt mit 10/s nach) |
| Eigen | ganze Zahl von 1 bis 2.147.483.647 |
Die Grenze ist ein Token-Bucket, kein feststehendes Minutenfenster. Der Eimer fasst den vollen Minutenwert als Burst und füllt gleichmäßig nach (bei 600/min also 10 Tokens pro Sekunde). Ein Client mit vollem Eimer darf 600 Anfragen sofort senden — und im Lauf der folgenden Minute weitere ~600. Rechnen Sie daher mit dem Burst, nicht mit „höchstens 600 in jeder Minute".
Per API (Rolle admin):
curl --fail-with-body -X PATCH \
"https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID" \
--header "Authorization: Bearer $OBHUT_PAT" \
--header 'Content-Type: application/json' \
--data '{"rateLimitPerMinute": 600}'null schaltet die Grenze ab. Werte außerhalb von 1 bis 2.147.483.647 werden
abgelehnt.
Reihenfolge der Grenzen
Es gibt keine „gewinnende" Grenze — jeder konfigurierte Eimer muss die Anfrage
erlauben. Trifft eine Anfrage auf eine Route mit eigener Grenze, gelten
Route- und Anwendungsgrenze gleichzeitig; der zuerst erschöpfte Eimer antwortet
mit 429.
Zusätzlich gilt das Mengengerüst Ihres Tarifs. Diese aggregierte Tarifgrenze ist nur Kontext, kein Regler — sie ist nicht editierbar. Ebenso sind Grenzen für den verwalteten Ingress und die Authentifizierungs-Endpunkte Betriebskontrollen und gehören nicht Ihrer Organisation.
Was ein Client sieht
Eine begrenzte Anfrage erhält 429 Too Many Requests mit einem
Retry-After-Header:
| Fall | Antwort |
|---|---|
| Pro-IP-Grenze (Anwendung oder Route) erschöpft | 429 mit Retry-After: 1 |
| Aggregierte Tarifgrenze erschöpft (gesamter Verkehr Ihrer Organisation) | 429 mit Retry-After: 1 |
| Grenze des verwalteten Ingress erschöpft (Betriebskontrolle) | 429 mit Retry-After: 1 |
| Monatliches Kontingent überschritten — nur bei Tarifen mit Hard Cap | 429 mit Retry-After: 3600 |
Der letzte Fall gilt ausschließlich für Tarife mit Hard Cap. Tarife ohne Hard Cap führen am Edge kein Kontingent: Verkehr darüber wird nicht begrenzt, sondern weitergeleitet und abgerechnet.
Client-Schlüssel
Gezählt wird pro Client-Schlüssel: bei IPv4 die vollständige Adresse der tatsächlichen Verbindung, bei IPv6 das /64-Präfix.
Ein IPv6-Client kann die niedrigen 64 Bit frei rotieren und sich sonst pro Anfrage einen frischen Eimer verschaffen. Deshalb maskiert obhut auf das /64-Präfix: alle Clients derselben /64-Zuteilung teilen sich einen Eimer. „600 pro Minute und IP" bedeutet für IPv6 also 600 pro Minute und /64.
Der Edge entfernt eingehende Weiterleitungs-Header, bevor er zählt — eine vom Client behauptete IP kann die Grenze also nicht umgehen.
Wann eine Änderung greift
Eine geänderte Grenze wird mit dem nächsten erfolgreichen Snapshot-Abruf des Edge wirksam, nicht sofort. Bei einer Wertänderung kann der bestehende Token-Bucket auf volle Burst-Kapazität zurückgesetzt werden; direkt nach der Änderung sind also kurz mehr Anfragen möglich. Bleibt der Wert gleich, bleiben verbrauchte Tokens erhalten.
obhut zeigt bewusst keinen genauen Zeitstempel „ab wann greift der neue Wert auf welchem Knoten". Prüfen Sie die Wirkung an den Zählern, nicht an einer versprochenen Uhrzeit.
Begrenzte Anfragen nachvollziehen
Die Nutzungsstatistik führt getrennte Zähler für Tarif-, Anwendungs- und
Routengrenzen. Die Zähler liegen hinter dem billing_reader-Gate:
curl --fail-with-body \
"https://api.obhut.io/tenants/$TENANT/usage/stats?grain=day&resourceId=$RESOURCE_ID&metrics=count429,countResourceRateLimited,countRouteRateLimited" \
--header "Authorization: Bearer $OBHUT_PAT"Im Dashboard zeigt die Anwendung die drei Ebenen getrennt und listet zuletzt betroffene Routen. Details zum Auslesen und Export stehen unter Nutzung und Abrechnung.
Zurücknehmen
Anwendungs- und Routengrenze werden getrennt zurückgenommen: Setzen Sie
rateLimitPerMinute auf null, um die Anwendungsgrenze abzuschalten — die
Routengrenzen bleiben davon unberührt und umgekehrt.