失败率偏高的时候，很多人会一直在参数上打转：超时调长一点，重试多几次，切换阈值改一改。改来改去效果有限，因为如果问题的根源是资源类型和任务不匹配，参数层面是解决不了的。代理IP的调参能处理波动，处理不了结构性不适配。
看失败的分布。参数问题通常表现为偶发、分散，时间上不集中；方案问题表现为集中、重复，往往集中在某一类资源或者某一个时段。代理IP的失败一旦显示出聚集特征，就该往方案层面想了。把分布画出来看，聚集与否一目了然，比凭感觉判断可靠得多。
方案层面的检查顺序
先看类型是不是对口，需要贴近普通用户环境的任务用了不对口的类型，怎么调都不会好；再看规格是不是够用，并发和时长的限制是不是卡住了任务；最后才回头看参数。代理IP的检查顺序从大往小，比从小往大省时间得多。
还有一个判断办法：换一批同类资源试一次。如果换完之后表现明显改善，说明是这一批的问题；如果换了还是一样，那就是类型或规格层面的事。代理IP的排查用这种替换法，几次就能收敛到方向。
- 先看失败分布是否聚集
- 再看类型是否对口
- 然后看规格是否够用
- 最后才是参数微调
需要注意的是：参数调整的记录也要留，否则过一段时间你分不清当前这套数值是调优的结果，还是随手改的遗留。
方向不对，调参是白费。
代理IP的排查顺序决定了效率。先确认是不是方案层面的问题，再回到参数上，能省下大量反复试错的时间。代理IP的排查先定方向，再谈参数，这是最省时间的一条路。