代理空闲超时与长连接测试：避免陈旧连接故障
一次代理请求成功后，连接可能在空闲期间被某一层关闭，而客户端仍认为套接字可用。源站、代理网关、负载均衡器、防火墙、NAT 设备和客户端连接池都可能采用不同的空闲期限。若只在真实任务到来时才发现差异，就会出现连接重置、空响应、尾延迟上升或多余重试。
本指南用于测出可安全复用窗口，并把 HTTP 持久连接、TCP Keepalive、代理会话寿命和应用超时作为独立控制项。
先列清所有超时
分别记录：代理连接建立、目标连接与 TLS 握手、响应头、正文无数据、客户端连接池空闲、网关或中间设备空闲、TCP 探测起始与间隔、HTTP/2 或 HTTP/3 会话与流限制、住宅代理粘性会话寿命、总请求截止时间和重试预算。
这些参数不是同一件事。粘性会话寿命描述出口选择，不一定等于单条 TCP 连接寿命；TCP Keepalive 可帮助发现无响应对端，却不能保证 HTTP 连接仍可复用或上游映射仍存在。
建立确定性测试资源
只使用自有或明确授权的端点。准备小型已知摘要响应、可暴露正文中断的大响应、返回脱敏连接编号的端点、可控延迟响应头或正文块的测试端点、正常关闭与异常关闭样本，以及业务需要的 HTTP/1.1 和 HTTP/2 路径。
固定请求方法、请求头、代理凭据、市场、地址族和客户端构建。不断变化的公共页面不能作为唯一复用证据。
在三层收集证据
每次尝试记录脱敏字段：试验编号、代理路由与会话别名、协议、地址族、请求与观测市场、连接编号、空闲间隔、套接字年龄、是否复用、状态码、响应摘要、失败阶段、错误类别、尝试次数和有效结果耗时。
条件允许时加入客户端连接池计数、操作系统套接字状态和服务商遥测。不得保存代理密码、令牌、Cookie、客户原始数据或无限制正文。
找到实际复用边界
先完成一次经过内容验证的请求，然后使用同一连接池按 0、1、5、15、30、60、120、300 秒逐级等待，再发送相同请求。每个间隔重复多次以发现偶发关闭；一旦开始失败，就增加中间间隔缩小边界。跨路由随机化顺序，避免临时源站故障只影响最长等待组。
只有完整响应、摘要与语义断言、市场和会话行为全部正确，才能算复用成功。若连接池悄悄新建连接并成功，它是请求成功，但不是复用成功，应单独记录。
对比直连与代理路径
政策允许时先做直连对照，再覆盖 HTTP/HTTPS 代理、指定 DNS 模式的 SOCKS5、轮换与粘性住宅代理、静态出口、IPv4/IPv6，以及实际使用的 Global、North America、Europe、APAC 市场。
若直连与代理在同一间隔失败，先检查源站、客户端或共享网络；若仅代理失败，再隔离网关、隧道、NAT 与路由策略。不要把每个重置都直接归因于代理服务商。
区分四类结果
- 安全复用： 原连接返回完整有效响应。
- 干净淘汰： 发送应用数据前已识别关闭并新建连接。
- 透明恢复： 陈旧复用失败，但一次安全且受限的重试成功。
- 用户可见失败： 请求丢失、损坏、重复或超出服务目标。
通常应优先让连接池提前干净淘汰。只有操作可安全重试且额外延迟和成本在预算内时，透明恢复才可接受。
测试半开连接与竞态
在受控环境中覆盖：代理先关闭而客户端仍标为空闲、源站关闭隧道另一端、网络状态无序消失、空闲清理与新请求同时发生、多个工作进程选择同一老化连接、复用时取消或关机，以及 HTTP/2 GOAWAY 或流重置靠近新请求。
验证单条连接故障不会重放不安全操作、泄漏监听器、影响其他多路复用流或引发重试风暴。
设置客户端淘汰余量
客户端空闲上限应短于所有中间设备中最低的可靠边界，并为调度抖动、网络延迟和配置漂移留出余量。不要直接复制中位数阈值，应按路由和市场的保守分位数确定。
若不同路由差异很大，可使用独立连接池或采用最安全的共享值。代理套餐、网关、系统、运行时、客户端库或区域基础设施变化后必须复测。
TCP Keepalive 应作为独立实验，确认探测能否穿过完整路径、错误是否足够早地传给应用；不要为了保持连接而无限期占用无用套接字。
设计安全重试
仅在操作幂等或具备批准的幂等控制、失败发生在不含糊的提交前、陈旧连接已从池中移除、新尝试使用新连接、严格限制次数并带退避与抖动、总截止时间和成本仍合规时重试。
非幂等请求不能因为“没有收到响应”就重复发送；没有响应并不证明源站没有执行。
指标与告警
按服务商、路由类别、市场、地址族和协议跟踪：各空闲区间的验证复用成功率、干净淘汰率、陈旧复用失败率、新连接回退率、每个有效结果重试数、p50/p95 有效结果耗时、失败时连接年龄、测试结束后的套接字与句柄，以及粘性会话连续性。
边界变化本身也应告警。安全窗口从数分钟降至数秒时，握手负载和尾延迟可能已上升，而总体成功率尚未明显恶化。
验收检查清单
- [ ] 所有超时及负责人已记录。
- [ ] 测试资源确定、可控且已获授权。
- [ ] 直连和代理使用相同客户端设置。
- [ ] 空闲间隔覆盖常用值与边界值。
- [ ] 复用与新建连接分别计量。
- [ ] 响应摘要和语义完成均已验证。
- [ ] 正确区分 HTTP/1.1 与多路复用协议。
- [ ] 已覆盖所需地址族、路由和市场。
- [ ] 客户端淘汰值包含保守余量。
- [ ] 重试安全、有上限且使用新连接。
- [ ] 已检查套接字、句柄和内存恢复。
- [ ] 证据中无密钥或多余个人数据。
常见问题
HTTP keep-alive 与 TCP Keepalive 相同吗？
不同。HTTP 持久连接允许一条连接承载多个请求；TCP Keepalive 通过传输层探测识别无响应对端，两者控制项与错误信号不同。
客户端空闲超时应等于代理超时吗？
不应相等。客户端应在最低可靠中间边界之前淘汰连接并留出余量，相等会在最差时刻形成竞态。
每次请求都新建连接能解决问题吗？
它能避免陈旧复用，但会增加握手、延迟与资源成本。应先验证保守连接池是否能保持正确性。
成功重试会掩盖陈旧连接故障吗？
会。应分别报告首次失败、新连接回退和最终有效结果，否则重试放大不可见。
合规与安全操作
只使用已授权的账号、目标、数据和市场；遵守访问控制、隐私要求、平台条款与速率限制。不得通过保持连接绕过会话政策或访问限制。保护凭据，保持 TLS 验证，并最小化证据留存。
继续阅读代理响应完整性测试、住宅代理会话粘性测试和Node.js 代理客户端灰度方案。
标准依据：RFC Editor，《HTTP Semantics》《HTTP/1.1》，2022 年 6 月；《Transmission Control Protocol》，2022 年 8 月。2026 年 9 月 12 日核查。
