代理IP超时，很多人的第一反应是"重试"。但最常见的错误也恰恰在这里：不看失败原因，同一个IP硬重试三次，然后放弃。
这么干有两个后果。超时要是因为目标站把这个IP封了，三次重试等于白扔三次请求额度，还把风控画像画得更深。超时要是只是网络抖了一下，你直接换IP，下一个IP可能碰上同样的抖动，重试次数又被毫无意义地消耗掉。更麻烦的是Scrapy这类框架的默认机制：内置的RetryMiddleware只对[500, 502, 503, 504, 522, 524, 408]重试，403和429被当成"正常响应"直接放行，Spider拿到空数据，解析报错，数据就这么永久丢了。而且默认重试会沿用原来的meta，代理字段原样保留——原IP要是已经失效，三次重试全打在死节点上。
所以超时重试的第一步不是写重试逻辑，是先把失败分类。
先分类，再决定要不要重试
2026年一篇实测文章给过一个可以直接套用的分类框架，核心原则就一句：不是所有失败都值得重试，更不是所有失败都该用同一种方式重试。
一次请求的结果，先归到下面几类里，再对应不同动作。
target_reject（401/403/451），不重试。这是目标站明确拒绝，大概率是IP被识别或者被封了，继续用同一个IP重试没有意义。直接标记这个IP在当前目标上不可用，换IP，重试次数归零——这是分级重试里最重要的一条规则。
rate_limited（429），退避后重试，但不优先换IP。429是限流信号，不是封禁。该做的是放慢速度，不是换个IP继续用同样的频率猛打。响应里带Retry-After的，尊重它。
proxy_error和connect_timeout，重试，但要换IP。连接代理本身失败，或者连目标超时，说明当前代理链路有问题。快速切一个代理再试，比在死节点上耗着有效。
read_timeout，谨慎重试。已经连上了，但响应没在时限内完成，可能是目标站慢，也可能是代理链路后半段堵。重试前先看看超时设置合不合理，别盲目重试。
target_5xx，中等间隔重试。目标服务器端的问题，通常跟代理没关系，退避后再试就行，不用频繁换IP。
分类的意义在于，只有你清楚这次超时属于哪一类，重试才是有决策依据的动作，不是条件反射。
退避：指数增长加随机抖动，但别齐步重试
确定要重试，间隔怎么设？固定间隔是最差的选择。所有失败线程同一时刻重试，一次短抖动直接放大成持续雪崩。正确做法是指数退避，等待时间随失败次数翻倍。urllib3的Retry里，backoff_factor=1意味着第一次重试等1秒，第二次2秒，第三次4秒，以此类推。
一个常用的生产配置长这样：
Retry(total=3, connect=3, read=2, status=2,
backoff_factor=0.5,
status_forcelist={429, 502, 503, 504},
respect_retry_after_header=True)顺手把另一条一起记住：只对幂等方法（GET、HEAD、OPTIONS）开自动重试，POST这类非幂等操作别让它自动重试，不然重复提交比超时更麻烦。
但光有指数退避还不够。纯指数的重试时刻依然可预测，多个线程同步失败的话，退避曲线会重合。加上随机抖动——在算出的等待时间上叠一个随机偏移，比如±30%，把重试时刻打散，才能躲开"齐步重试"造成的二次冲击。
超时类的失败还有更具体的建议，一篇调优指南里提过：超时失败可以快速重试，间隔2到4秒，大概率就是网络抖了一下；403、418这种明确拒绝，才需要退火重试，间隔指数增长。
重试要和"换IP"绑定，不是和"同一个IP"绑定
分类和退避解决的是"什么时候重试"，代理场景下还有个更关键的问题：重试的时候用哪个IP。
Scrapy默认行为的问题就卡在这：重试沿用原meta，代理字段不变，一个已经失效的IP会被重试三次。阿里云那篇文章的实测案例也印证了这一点——用动态代理时底层节点不稳定，请求卡在建立连接阶段，连续3次重试都碰上坏节点，Scrapy直接把URL抛弃，数据永久丢失。
正确的绑定关系是，重试动作触发时，代理选择器要在请求发出之前重新取IP。尤其是target_reject和proxy_error这两类，重试的前提本来就是换个节点。要是用的隧道代理，脚本侧固定入口地址，重新发起请求时服务端自动分配新IP，这个绑定天然成立。要是用的短效代理或者本地IP池，就得在重试逻辑里显式走一遍"标记当前IP失败，从池里取下一个"。
防雪崩：重试率是比成功率更灵敏的警报
最后一条也最容易被忽略：重试机制本身会制造流量。失败率一升，重试量跟着升，重试量升又可能把失败率再推高，形成自激振荡。
所以除了单请求的重试上限（通常2到3次），还得有个全局的重试率熔断。某个目标域名的重试率持续超过阈值，比如10%，这时候不是加大重试，而是降低这个目标的并发数。高并发场景下，429和ReadTimeout间歇性冒出来，很多根源是并发超过了代理或目标站的吞吐上限，不是IP数量不够。这种时候加代理、加重试，只会让情况更糟。
重试的正确位置是兜底，不是主力。重试率应该被监控，而不是被容忍。
免费代理场景，重试参数要更保守
谷德免费代理这类免费渠道，超时和失效的占比本身就高，重试参数得针对性调。
total重试次数别超过2。免费IP的失效概率摆在那，给一个大概率已经死的IP三次机会，不如把次数压到两次，省下来的请求额度用在换IP之后那次干净尝试上。
连接超时设短，读取超时适当放宽。免费代理的链路质量波动大，连接阶段（TCP握手到代理）3秒内没建起来，基本可以判定这个节点当前不可用；读超时可以放到15到20秒，给慢节点留点余地，但别无限等。
还有一条，优先用"存活时间"做前置筛选，把重试的弹药留给真正有机会成功的节点。谷德页面上存活超过2小时的IP，初始连通率明显高于刚上线的节点。进重试循环之前先筛一道，比在循环里反复消耗无效节点划算得多。
一条能直接套用的决策顺序
拿到响应或异常，先分类。不可恢复的（403/401）不重试，标记IP不可用；可恢复的（超时、连接错误）指数退避加抖动后重试；重试前先换IP，别在旧IP上耗；重试率超过全局阈值，降并发，别加次数。
重试做对了，代理消耗会降下来，数据完整性会升上去。做错了，它自己就会变成一个新的故障源。