先看现象。自建网关透传上游 503 的 Retry-After，值是 Wed 21 Oct 2026 07:28:00 GMT，客户端按秒数 float() 解析，直接抛 ValueError，整批任务中断。
原因不止一个，得分开看。Retry-After 允许秒数与 HTTP-date 两种格式。也可能是代理把原始头改写成了日期。
还有一种情况，客户端没有 try 兜底。
另外，时区没按 GMT 解析，等待时间算错。
第一件事是看响应头原值
curl -sI https://api.example.com/v1/chat | grep -i retry-after然后按日期格式解析一次
python -c "from email.utils import parsedate_to_datetime;print(parsedate_to_datetime('Wed, 21 Oct 2026 07:28:00 GMT'))"再往下写一个两种格式都能吃的函数
python -c "v='12';print(int(v) if v.isdigit() else 5)"等前面都确认过，再用恢复时间减去当前时间
python -c "from email.utils import parsedate_to_datetime;from datetime import datetime,timezone;print(int((parsedate_to_datetime('Wed, 21 Oct 2026 07:28:00 GMT')-datetime.now(timezone.utc)).total_seconds()))"当时还开着另一个排查窗口，两边日志对照着看才定位到。
同一份数据我导出了两份，一份留底，一份拿来试。
改完先别撤，确认这几项。客户端遇到日期格式不再抛异常，等待时长与目标时间相差不超过 1 秒，任务能继续。
容易忽略的是，重试逻辑最怕在解析响应头时崩掉，任何头部字段都要按最宽松的类型处理。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。