接口限流触发了 429，恢复后同一批用户还是持续收到 429，持续将近十分钟，源站日志里这段时间没有他们的请求。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，CDN 把 429 当成普通响应缓存了，或者按状态码规则缓存了几分钟。限流早就解除，边缘还在返回那份错误响应。4xx 默认不一定缓存，配置里常常被一起带上。
「429 被缓存」相关的验证我通常做两遍，改完一次、隔天再看一次，确认不是临时生效。改完顺手把文档补一句，省得下次自己重新推一遍。
curl -sI https://example.com/api/query | grep -iE 'cache-control|x-cache|age' # 429 响应期望 no-store
监控和日志的时间要对上，时区不一致会多绕很大一圈。临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
具体做法是，在 CDN 规则里明确 429 和 5xx 不缓存；源站 429 响应加 Cache-Control: no-store；已经缓存的错误响应手动刷新；验证限流恢复后同一 IP 的请求是否立刻恢复。
最后用这个标准收尾，限流结束后下一次请求就回到正常状态 X-Cache 不再返回缓存的 429。