遇到地址被封，很多人的解法是换更贵的资源，结果往往撑不了多久就照旧。原因常常不在地址质量，而在请求节奏：你用什么频率、多大并发去访问目标站，这套行为特征是跟着你的操作习惯走的，不会因为你换了个出口就自动改变。节奏不调整，换多少个地址，在目标站看来都是同一个来访者。
多快算快，有没有一个通用数值
没有。不同站点的承受基线差得很远，大型站点对每分钟几十次请求毫不在意，小型站点可能每分钟十次就触发保护。比较稳妥的做法是先观测再定档：用很低的频率跑一天，记录响应码、响应时间和是否出现验证环节，然后逐步往上加档，每次加档后观察一段时间。当你发现响应开始变慢或间歇性出现验证，就说明到拐点了，把档位退回一档作为常态值，留出余量。
并发开多少合适，是一个地址拉满还是多地址分摊
建议分摊。单个地址上的并发连接数是有上限的，超过之后目标站看到的是”同一时刻涌来大量请求”，特征非常明显。同样的总量，分散到多个地址、每个地址只承担少量并发，看起来就自然得多。判断标准是单个地址上的并发数，而不是总并发数——总量翻倍时，先想着加地址，而不是把现有地址压满。
换了IP但节奏不变，还有用吗
作用有限。地址只是身份的一部分，请求间隔的分布、访问的先后顺序、失败后的反应方式，这些都属于行为特征，换地址并不会让它们改变。特别要注意固定间隔：整整齐齐每三秒一次，比随机间隔更容易被识别为程序行为。真正有效的做法是在换地址的同时，把间隔改成带随机抖动的分布，让快慢自然波动，而不是机械重复。
| 节奏问题 | 目标站看到的样子 | 怎么调 | 看什么验证 |
|---|---|---|---|
| 固定间隔 | 间隔高度一致，机械感强 | 引入随机抖动，快慢交错 | 间隔分布是否还有明显规律 |
| 瞬时突发 | 短时间内请求成堆涌来 | 加队列削峰，拉平到时间窗 | 峰值请求数是否下降 |
| 单址高并发 | 同一地址同时开大量连接 | 限制单址并发，靠加地址扩量 | 单址并发是否在上限内 |
| 失败即重试 | 出错后短时间内反复尝试 | 递增退避，超限暂停并换址 | 重试次数与成功率是否改善 |
- 先测基线：从低频起步，逐步加档找到拐点，退回一档作为常态
- 限定单址并发：给每个地址设并发上限，扩量靠增加地址数
- 加入随机抖动：间隔不要固定，让快慢自然波动
- 失败分级退避：连续失败先拉长间隔，超过阈值暂停并换地址
- 持续记录指标：响应码、响应时间、验证出现率三者一起看，趋势比单次数值重要
换地址换的是脸，改节奏改的是走路的姿势，两者都变了才像另一个人。
与 IP 代理的关系：代理IP被封的另一大原因是请求节奏没有跟着地址一起调整，固定间隔、瞬时突发、单址高并发与失败即重试这四类做法最容易触发限制——使用代理IP时应先测出目标站的频率基线并留余量、限定单址并发靠加地址扩量、给间隔加随机抖动、失败后分级退避，才能让干净的出口地址真正发挥应有的作用。