技术帮助 · 发布时间：
回源超时不一定是源站处理慢。清洗节点与源站之间可能复用连接，也可能因空闲连接被中间设备关闭而反复重建；若超时后又集中重试，请求积压会更严重。处理“清洗型网络防护的回源超时与连接保持参数调校”，应先定位卡在哪一段，再决定缩短还是延长保持时间。
先分清超时发生在哪个阶段
查看清洗平台、反向代理和源站的访问日志及指标，按时间对齐请求 ID 或时间戳。连接建立失败、已连接但响应停顿、连接池无可用连接，是三类不同问题，不能只靠提高一个超时值处理。
- 连接建立超时：关注清洗节点到源站的网络可达性、源站监听状态及连接队列。若 TCP 握手未完成，延长读取超时通常无效。
- 响应读取超时：已建连但等待响应超过代理的读取期限。Nginx 的 proxy_read_timeout 通常表示两次读取之间允许的最长间隔，并非整个请求的总时长。
- 连接池等待或耗尽：观察活动连接、空闲连接、文件描述符和等待队列。连接数持续接近上限时，继续延长空闲保持时间可能占住资源。
连接保持要对齐，不要只调大
HTTP keep-alive用于复用应用层连接，减少重复握手；操作系统的TCP keepalive则通过探测判断长时间无数据的连接是否仍可用，两者不能互相替代。还要核对清洗节点、负载均衡器与源站的空闲超时：若中间一层先关连接，代理仍把它当作可复用连接，下一次请求就可能遇到重置或重试。
可先把代理到源站的空闲保持时间设在约 30—60 秒作为排查起点，再依据请求间隔、设备空闲超时和连接资源调整；这不是通用最优值。对持续时间较长的请求，应另行评估读取超时，而不是把所有空闲连接都保留更久。Nginx 的 upstream keepalive限制的是每个 worker 缓存的空闲连接数量，不是源站连接总量；设置时还要考虑 worker 数量及源站承载能力。
按顺序调校，避免重试风暴
- 建立基线：记录回源连接建立时间、首字节时间、超时数、活动与空闲连接数、源站队列长度及重试次数；区分正常时段和流量突增时段。
- 核对超时链：列出清洗节点、代理或负载均衡器、源站各自的连接超时和空闲超时。让连接复用的一方不晚于可能提前关连接的中间层，避免复用已失效连接；对请求读取期限，则按业务最长处理时间设置并保留有限余量。
- 小步调整连接池：先减少过量空闲连接，或在源站有余量时逐步增加可复用连接数；每次只改一项，观察连接失败和等待队列是否下降。不要把池上限直接设到源站连接容量。
- 限制失败重试：确认重试次数、间隔和适用请求类型。超时后立即对所有请求重试会形成重试风暴；宜采用有限次数、带退避的重试，并避免对非幂等请求盲目重放。
- 回滚验证：若活动连接、文件描述符或队列上升而成功率没有改善，恢复上一组参数，再检查源站处理能力与上游限流，不能靠延长连接保持掩盖过载。
常见问题
连接保持时间越长，回源就越快吗？
不一定。请求密集且源站有余量时，复用连接可减少握手；低频流量或连接资源紧张时，长时间保留空闲连接反而会占用资源。
TCP keepalive 能解决 HTTP 超时吗？
不能直接解决。它可帮助发现部分失效的 TCP 连接，但不会延长应用代理的读取期限，也不会增加源站处理能力。
应该先增加连接池还是提高超时？
先依据日志确认瓶颈。若是建连失败，应查网络和监听；若是响应慢，应查源站耗时；只有确认池容量不足且源站有余量时，才逐步扩大连接池。
归根结底，清洗型网络防护的回源超时与连接保持参数调校，要让超时边界、连接池容量和源站承载相互匹配。以分段指标验证每次变更，并控制重试，才能降低超时而不把请求推成更大的积压。
