模型服务 5xx 期间，客户端仍按 429 的策略重试 5 次，故障窗口从 2 分钟拉长到 12 分钟。日志里能对上时间点，这种反而好排。
两类错误语义不同，429 是限流等一会就好，5xx 是上游故障，重试只会继续加压。代码里用了同一个重试装饰器。这一点先确认清楚，后面就不用反复试。
curl -i https://api.example.com/v1/chat -d @req.json | head -1
「429与5xx处理」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。
处理上按这个顺序：429 按 Retry-After 退避 最多 3 次；5xx 最多 1 次并快速失败 触发降级；参数类 4xx 直接不重试；把错误分类打到监控里。
结果对不对很好判断，5xx 期间请求量没有放大 故障恢复时间回到 2 分钟量级。