去年有段时间，我把提取接口直接塞进了 for 循环里，一次取一条，20个线程一起敲。前半小时一切正常，之后接口开始回"请求过于频繁"，整个采集链路卡住。后来我把参数重新配了一遍——改成批量取、加上缓存、按剩余有效期筛，同样的业务量，接口调用次数降到原来的五分之一，也没再被限流过。这篇把这几个参数怎么配讲清楚。
最费的用法：一次只取一条
qty 默认是1，也就是每调一次接口只给你一条IP。如果你有50个线程要跑，按这个用法就是50次接口调用，接口不限流才怪。
正确做法是批量取：一次取"未来一到两分钟要用的量"，比如20条、30条。调用次数立刻降一个量级。但别反过来一次取几百条囤着——短效IP是按分钟计时的，囤太多等于让它们在池子里白白过期。
缓存参数：短时间复用同一批IP
接口支持缓存模式：Cache=1 配合 Cachetimems（毫秒），在设定的时间窗内重复调用，拿到的是同一批IP，而不是每次都给新的。
这个参数解决两个问题。一是接口调用量：窗口内调多少次都只算一批，供给压力小很多。二是会话连续性：带登录态的业务，几个连续请求必须走同一个出口，缓存模式正好给你这个保证。
反过来，如果你就是要高频换IP做采集，那就别开缓存，或者把窗口设得比单请求耗时还短，否则等于自己在给自己限速。
按"还能用多久"挑IP：bufferTime 与 endTime
这两个参数容易被忽略，但很实用。bufferTime 是要求IP至少还剩多少秒有效——短效IP按分钟计时，你要是没设这个，很容易提到一条还剩几秒的，请求还没发完它就失效了。endTime 是上限，只接受剩余有效期不超过某个值的IP，配合你的轮换节奏用。
我一般把 bufferTime 设成30到60秒。就这一项，能挡掉大部分"提到手就快死"的IP，成功率提升挺明显。
按业务分三套参数
| 业务类型 | qty | 缓存 | bufferTime |
|---|---|---|---|
| 高频采集 | 并发数以内批量取 | 关闭 | 30 秒 |
| 会话保持类 | 1 到 3 条 | 开启，窗口≈会话时长 | 60 秒 |
| 多城市比价 | 按城市分次取 | 关闭 | 30 秒 |
顺便说下 Area 和 Isp：这两个是按城市、按运营商指定的，一次调用只能给一个值。要多城市就分多次调用，别指望一次调用里混着几个城市——那不叫批量，叫超范围。
调用间隔和并发怎么控
接口本身也有并发承受力。别用60个业务线程直接去打接口，先拿3到5个并发试，看接口响应的稳定程度。
更稳的做法是把"取IP"和"用IP"解耦：单独跑一个补货逻辑，按节奏把IP填进本地小池子，业务线程只从池子拿。这样接口侧的调用曲线是平的，不会被自己顶到限流。
我的做法是本地维护一个有效期30秒左右的小池子，水位低于三分之一就补货，补货一次取20条。真遇到限流提示也别硬撞——退避1到2秒在试，连续几次失败就把补货频率降下来。
返回格式也别忽略
接口的返回分隔符可以指定，Split=json 直接给结构化数据，省得自己拼解析；也可以指定 \n、\t 这类分隔符。用文本格式时记得处理换行，我见过有人没处理，把两条IP粘成了一条，代理参数直接解析失败。
我踩过的两个坑
一是把返回文案当成IP用。有一次接口回的是"抱歉，当前没有可用IP"这种提示，脚本没校验格式，直接塞进代理配置，结果报了一堆看不懂的错。现在第一件事就是校验 IP:端口 的格式，不合法就丢掉并记录原文。
二是取IP的请求自己走了代理。图省事把提取请求也配上了代理，结果代理一失效，整个供给链就断了。取IP这一步必须直连，或者把它加入白名单走直连通道。
我现在用的是星月代理，池子覆盖全国300多个城市，可用率标的90%以上，短效IP自动轮换，API实时提取支持批量、缓存、城市与运营商指定和白名单。新用户能领免费试用IP，拿试用把上面这几套参数各跑一遍，接口调用量和成功率的变化很直观，心里有数了再定正式套餐的用法。
参数配得好，接口调用能省下七成，成功率还能往上走；配得不好，就得天天跟"请求过于频繁"较劲。
提取接口配置要点：用 qty 批量取代替一条条取，用 Cache 加 Cachetimems 在时间窗内复用同一批IP，用 bufferTime 挡掉即将失效的IP，Area 与 Isp 分次调用，取IP的请求走直连并校验返回格式，再配一个本地小池子按需补货。