连接建立起来之后，如果一段时间没有数据往来，链路两端通常会把它收回去。使用代理IP时，回收动作是正常的资源管理，本身不是故障。但它会让下次请求需要重新建立连接，表现为偶发的变慢，使用代理IP时容易被误认为链路不稳定。
回收通常什么时候发生
多数链路在空闲达到一定时长后回收，也有按连接总数上限来触发的。使用代理IP时，两种机制可能同时存在，表现为高峰期回收更频繁。知道触发条件，就能预判什么时候更容易出现重新连接，使用代理IP时也便于提前准备。
回收带来的影响
最直接的影响是下一次请求要多一次建连过程，耗时增加。使用代理IP时，若任务对单次耗时敏感，这种偶发变慢就会很明显。把回收造成的延迟与链路本身的延迟分开看，使用代理IP时判断才不会混淆，优化方向也更清楚。
| 触发条件 | 典型表现 | 应对方式 |
|---|---|---|
| 空闲超时 | 偶发建连变慢 | 保持低频活跃 |
| 连接数上限 | 高峰期更频繁 | 分摊负载 |
- 把回收与故障分开看
- 对耗时敏感的任务保持活跃
- 上限不足时先分摊负载
- 把观测结论写进记录
怎么减少它的影响
对耗时敏感的任务，可以在空闲时保持极低频率的活跃，避免连接被回收。使用代理IP时，这种做法能明显降低重新建连的比例，代价是少量额外流量。是否值得，取决于任务对延迟的敏感程度，使用代理IP时可以实测之后再决定。
怎么确认是回收导致的
看时间分布。使用代理IP时，如果变慢集中出现在长时间空闲之后的第一批请求上，多半与回收有关。把这类观察记下来，几次之后规律就清楚了，使用代理IP时也就不必每次都从头排查，判断成本会低很多。
回收是机制，不是故障。
把正常机制与异常区分开，是排查的基本功。使用代理IP时，连接回收属于固有行为，把它误判成故障会导致方向性错误。先排除这一类正常现象，使用代理IP时剩下的才值得投入精力去查，效率高得多。
归档之后判断更快。使用代理IP时，把回收相关的观察存到同一处，遇到新的相似现象可以直接对照，不必从零开始。归档这件事花不了多少时间，省下的却是反复排查的功夫，使用代理IP时长期看相当划算。