From 870db6c72b90019a1b681f9d825cd6193ab53760 Mon Sep 17 00:00:00 2001 From: RazvanLiviuVarzaru Date: Mon, 29 Jun 2026 10:27:22 +0300 Subject: [PATCH 1/2] Rate limit Buildbot by client IP Old behavior used request_uri as the rate-limit key, so the bucket was shared globally per exact URL. One aggressive client hammering a common URL could consume that URL's allowance and cause unrelated users to be rate-limited too. It also did not catch scanners that spread requests across many unique URLs, since each URL had its own bucket. New behavior uses binary_remote_addr as the key and allows 10 requests per second with a burst of 200 before returning 429. This isolates aggressive scanners to their source IP and leaves other client IPs unaffected. The tradeoff is that users behind the same NAT, VPN, or proxy still share one client-IP bucket. --- docker-compose/nginx/templates/bb.conf.template | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docker-compose/nginx/templates/bb.conf.template b/docker-compose/nginx/templates/bb.conf.template index 208dc270c..8493097d0 100644 --- a/docker-compose/nginx/templates/bb.conf.template +++ b/docker-compose/nginx/templates/bb.conf.template @@ -14,8 +14,9 @@ server { } } -# Default rate limited zone, with 30 requests per minute -limit_req_zone $request_uri zone=bb:10m rate=30r/m; +# Per-client rate limited zone. This catches scanners walking many unique +# URLs without sharing one bucket across all visitors of a popular URL. +limit_req_zone $binary_remote_addr zone=bb:10m rate=10r/s; client_max_body_size 10M; server { @@ -32,9 +33,9 @@ server { proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Host $host; - # Use default zone for rate limiting, allow burst of 10 requests with - # no delay - limit_req zone=bb burst=10 nodelay; + # Allow normal page/API bursts, but reject sustained aggressive clients. + limit_req zone=bb burst=200 nodelay; + limit_req_status 429; location / { proxy_pass http://127.0.0.1:8010; From 7d56c491eeb15e74b339e6a95a8f10b8473a2718 Mon Sep 17 00:00:00 2001 From: RazvanLiviuVarzaru Date: Mon, 29 Jun 2026 13:53:32 +0300 Subject: [PATCH 2/2] Fine tune r/s and burst Will probably need future changes if we identify 429 reponses for normal operation. Buildbot pages can generate short request spikes when developers open or refresh builds with many steps, changes, avatars, and websocket/API calls. Treat those page-load clusters as burst traffic rather than raising the sustained request rate too far. Use the request rate as the long-term per-client ceiling, and use burst to absorb normal UI fan-out from heavy build pages or a small number of tabs. This keeps the developer workflow responsive while still rejecting clients that continue sending requests above the sustained rate. --- docker-compose/nginx/templates/bb.conf.template | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docker-compose/nginx/templates/bb.conf.template b/docker-compose/nginx/templates/bb.conf.template index 8493097d0..d9b68c2f9 100644 --- a/docker-compose/nginx/templates/bb.conf.template +++ b/docker-compose/nginx/templates/bb.conf.template @@ -16,7 +16,7 @@ server { # Per-client rate limited zone. This catches scanners walking many unique # URLs without sharing one bucket across all visitors of a popular URL. -limit_req_zone $binary_remote_addr zone=bb:10m rate=10r/s; +limit_req_zone $binary_remote_addr zone=bb:10m rate=35r/s; client_max_body_size 10M; server { @@ -34,7 +34,7 @@ server { proxy_set_header X-Forwarded-Host $host; # Allow normal page/API bursts, but reject sustained aggressive clients. - limit_req zone=bb burst=200 nodelay; + limit_req zone=bb burst=150 nodelay; limit_req_status 429; location / {