同样的网页，直连时好好的，一走代理就频繁”转圈、重连、掉线”。很多人把锅扣在出口速度上，其实更常见的原因藏在请求头里——Connection、Keep-Alive 这类”逐跳头”在代理链路里被悄悄处理，处理不当，连接就续不上。
代理会吞掉哪些请求头
HTTP 报文里有一类头叫逐跳头（hop-by-hop），它们只对”相邻一跳”有意义，代理收到后不会转发给下一跳。最常见的包括 Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、TE、Upgrade、Trailer。如果代理原样把这些头透传下去，下游会把”对代理说的话”误听成”对服务器说的话”，协议就乱了。
| 请求头 | 作用 | 代理如何处理 |
|---|---|---|
| Connection | 声明本跳连接选项 | 消费后移除，重建自己的连接 |
| Keep-Alive | 请求保持连接 | 两端各自维持，不直接透传 |
| Proxy-Authorization | 向代理认证 | 自己验完即删，绝不外传 |
| Upgrade | 协议升级（如WebSocket） | 是否支持要看代理实现 |
Keep-Alive 到底由谁维持
代理把客户端到服务器的一条连接拆成了两段：客户端—代理一段，代理—服务器一段。两段的存活时间、空闲超时互不相干。客户端的 Keep-Alive 设得再长，只要代理那一端空闲超时先到，连接照样被回收。下次请求来时，代理要重新向目标建连，这个重建动作用户侧感知就是”卡一下”或”多等一拍”。
反复重连的三个常见根因
一是两端超时配置不匹配：客户端以为连接还在，代理却早已断开，请求发出后只能等超时重连。二是代理的连接复用池太小，并发一高就频繁新建连接。三是目标服务对代理这一跳做了连接数限制，超了就断开最老的连接。排查顺序是：先看代理日志里有没有大量”重新连接”记录，再对比客户端超时与代理空闲超时，最后确认并发是否顶到了代理的连接上限。
- 先看日志：代理端出现大量重连记录，多半是空闲超时或连接上限
- 对比超时：客户端 Keep-Alive 与代理空闲超时对齐，避免”客户端以为还连着”
- 看并发：确认是否顶到套餐连接上限，超了会被迫断开老连接
- 留余量：给复用池留出空间，避免高并发时频繁建连
代理像快递中转站：你盼着车一直等着，中转站却有自己的发车时间——两边时间对不上，你的包裹就得重新排队。
与 IP 代理的关系：代理链路的连接管理与请求头处理直接决定使用体验的稳定程度；在遵守平台规则与法律法规的前提下，理解逐跳头的边界、把两端超时与并发余量调对，才能让代理连接少断、少卡、少重连。