I need help understanding Vercel WAF fixed-key rate limiting on a Hobby staging project.
Setup:
- Preview deployment; function runtime region: iad1.
- Active firewall rule: fixed window, 1 request per 60 seconds.
- Counting-key configuration: keys: [].
- Conditions match the staging hostname and rate-limit API identifier.
- Two independent callers use the same rate-limit API endpoint, API identifier and fixed x-vercel-rate-limit-key value.
- Callers: a local computer and a deployed server function.
Controlled test:
- The local caller received HTTP 429, with response region prefix hkg1.
- About 2 seconds later, it received HTTP 204, establishing a counter-reset interval.
- About 2 seconds after that, it received HTTP 429, confirming that the new allowance was exhausted.
- About 12 seconds after the allowed local request, the independent deployed caller received HTTP 204, with response region prefix hkg1:iad1.
The deployed request completed well before the next possible reset of the observed local window.
Important: hkg1:iad1 was extracted from the x-vercel-id RESPONSE HEADER of the function’s OUTBOUND rate-limit API request—not from the incoming browser request.
Support AI gave conflicting explanations about whether hkg1 or iad1 owned the deployed request’s counter. It later clarified that its explanation was architectural inference, not inspection of request logs.
Could a Vercel engineer clarify:
- Can identical fixed keys produce separate counters despite these response region prefixes?
- For the rate-limit API endpoint, which part of the outbound response’s x-vercel-id, if any, reliably identifies the counter’s region?
- Is there a supported way on Hobby to verify that independent function instances share one regional counter across restarts, and skip reporting when that region cannot be verified?
We understand that WAF counters are regional. We do not require a worldwide counter. Our application can skip diagnostic reporting outside one verified region.
Diagnostic collection remains disabled. Project identifiers and exact request timestamps have been omitted from this public post; they can be supplied through an appropriate private Vercel support channel if needed.