Handle Proxy 429 Responses Without Creating a Traffic Spike

#devops

HTTP 429 is a request to reduce pressure. It is not a signal to rotate proxy exits faster.

Identify the limiting scope

Capture the destination, proxy route, operation, response time, and relevant headers. The limit may belong to an account, token, endpoint, region, session, or entire destination.

Do not record credentials or authorization headers.

Parse Retry-After safely

Retry-After can be a number of seconds or a date. Treat it as the minimum wait for the affected scope. Clamp negative date-derived delays to zero and set a maximum consistent with the job deadline.

If the header is absent, use capped exponential backoff with full jitter.

if response is 429:
  scope = classify(destination, account, endpoint, proxy route)
  delay = valid Retry-After or jittered backoff
  pause new work for scope
  schedule a small probe after delay

Limit starts and active work

Request rate and concurrency are separate controls. Use a token bucket for starts and a semaphore for active operations. Put overflow into a bounded queue.

Monitor queue depth and oldest-job age. An unbounded queue only postpones the failure.

Share state across workers

If ten workers receive the same limit and each creates its own timer, they may all resume together. Store the pause deadline and probe ownership centrally. Allow one or a small number of half-open probes.

Do not evade the signal

Changing the exit is justified only when the limit is proven to be a failed-route condition and the alternate route is authorized and independently capacity-limited. Do not use rotation to bypass target policy, quotas, or blocks.

Preserve results

Use operation IDs and checkpoints. Mark work as delayed or limited, not empty. Protect state-changing operations with idempotency before retrying.

Test the control loop

Before production, simulate a limiter that returns several 429 responses with changing Retry-After values. Run multiple workers and verify that only the intended scope pauses, one probe owns recovery, and the queue stays within its bound.

Also test malformed or missing timing headers. The client should fall back to its own capped jittered delay rather than retrying immediately. A date in the past should never create a negative sleep, and an excessively distant date should not keep a job alive beyond its deadline.

Finally, confirm that dashboards distinguish initial requests, retries, deferred tasks, and cancelled work. If all attempts are reported as ordinary traffic, operators cannot see amplification or data gaps.

Recovery checklist

pause the correct scope;
respect Retry-After;
apply jitter when server timing is absent;
drain or pause bounded queues;
resume with a small probe rate;
increase gradually while success stays stable;
pause again if 429 repeats;
report retries separately from initial requests.

Disclosure: I work with 98IP. This guide is for authorized, policy-compliant automation. Additional resources: https://en.98ip.com/?k=dev

DEV Community