当采集出现 403/429 或者页面明显“变短”，多数时候不是单点 IP 被封那么简单，而是节奏、会话与出口质量共同触发了软硬结合的防护策略。最稳妥的修复路径是先用完整性校验把坏样本拦住，再按从低风险到高风险的顺序依次调整：先降速与退避、再稳会话、最后才扩大出口与地区切换。
先定位异常是从哪一层开始的
把错误分成三类：硬拦截（403/429）、软性降级（200 但字段缺失）、结构变体（返回不同模板或跳转到同意页）。不同类型对应不同的修复动作。
如果页面体积与模块数量突然下降，即使没有 403/429，也应优先当作软性降级处理。
先做“低风险动作”再谈换出口
第一步通常是降低并发、增加随机抖动与指数退避，让目标站看到更自然的请求节奏，同时减少重试风暴。
第二步是保持会话连贯：同一会话内尽量不频繁切换出口，避免登录态与风险画像在短时间内剧烈波动。
什么时候才需要更激进的轮换
当你确认节奏与会话已稳定，但仍持续出现硬拦截，才考虑扩大出口池与更换地区。否则你无法判断改善来自哪一层。
更换地区时要配套做地区一致性校验，避免把“地区被推断错”误判成“反爬升级”。
恢复后如何防止复发
把关键字段完整性与有效页面率接入监控，出现趋势性下滑就自动降速并触发小样本复测。
同时保留一组哨兵页面与固定节奏配置，作为每天的回归基线，便于快速发现结构变化。
FAQ
只要看到 429 就直接换 IP 可以吗？
不建议。先降速与退避更稳，因为很多 429 是节奏触发，盲目换 IP 只会放大成本。
为什么会出现 200 但数据明显缺失？
这常见于软性防护或渲染退化，必须用字段校验拦住坏样本，否则下游分析会被污染。
会话连贯要怎么做才算到位？
把出口分配到会话而不是分配到请求，按会话统计失败并只替换失败会话的出口。