Windows
macOS
Android
iOS
看到缓存节点到源站的响应变慢时，很多人首先想到的是提升公网带宽。但服务端回源速度优化面对的往往是另一类问题：请求还没有真正传到应用层，时间已经消耗在 DNS 解析、TCP 建连、TLS 握手或跨区域网络路径上；即使网络很快，源站线程池、数据库查询和磁盘读取也可能让首字节迟迟不能返回。
因此，判断回源瓶颈不能只看出口流量。应把一次请求拆成“解析、连接、握手、发送、等待首字节、接收响应”几个阶段，再分别处理。
先区分网络慢，还是源站处理慢
用时间分段定位
在同一时间窗口内，分别记录 DNS 查询耗时、连接耗时、TLS 握手耗时、TTFB（首字节时间）和完整下载耗时。若连接耗时明显升高，优先检查路由、丢包、连接数和防火墙；若连接很快但 TTFB 偏高，问题更可能位于应用排队、数据库或后端服务。
测试时至少比较三种路径：缓存节点到源站、同地域机器到源站、源站本机访问应用。只从办公网络访问源站，不能代表真实回源链路。对动态接口、图片处理和大文件下载，也要分开统计，因为它们的等待阶段并不相同。
不要用平均值掩盖尖峰
平均响应时间可能看起来正常，但少量慢请求会拖累缓存填充和用户体验。建议同时观察 P50、P95 和 P99，并按状态码、请求路径、源站实例和响应体大小分组。若只有某个接口在高并发时变慢，单纯扩充链路带宽通常不能解决应用排队问题。
这些做法会直接拖慢回源
每次请求都重新建连
关闭 HTTP Keep-Alive，或让代理与源站之间的空闲连接过快失效，会使大量请求重复经历 TCP 建连和 TLS 握手。对于短请求，这部分固定成本可能比真正的数据传输还明显。应根据请求频率设置合理的连接池、空闲超时和最大连接数，并确认中间代理不会提前断开连接。
连接复用也不是越多越好。连接池过小会排队，过大则可能耗尽源站文件描述符、线程或后端连接。可以先按并发请求量估算池大小，再结合源站 CPU、内存和连接拒绝情况逐步调整。
盲目增加重试次数
超时重试能够应对偶发丢包，却可能把已经拥堵的源站推入更严重的排队状态。尤其是写操作、订单提交或带副作用的接口，不应在没有幂等控制时自动重试。
更稳妥的做法是：
- 只对明确可重试的网络错误或部分 5xx 响应重试。
- 设置较短的连接超时，并为读取超时单独设值。
- 采用有限次数和退避间隔，避免多个请求同时再次冲击源站。
- 把重试总耗时纳入调用方的整体截止时间。
DNS、证书和路由配置频繁变化
DNS 解析结果不稳定、权威 DNS 响应慢，或解析到距离源站更远的地址，都会延长回源建立阶段。调整记录时还要考虑 TTL 和本地缓存，不能把修改记录后立刻生效当作必然结果。
TLS 方面，证书链过长、协议配置不兼容或频繁触发完整握手，也会增加建立时间。应检查证书链是否完整，确认代理与源站支持的 TLS 版本一致，并观察会话复用是否生效。若使用双向 TLS，还需把客户端证书校验耗时和证书轮换流程纳入排查。
服务端回源速度优化的可执行步骤
- 建立基线。选择几个高频 URL，连续记录不同时间段的连接耗时、TTFB、响应大小、状态码和重试次数。
- 拆分链路。用命令行或链路监控分别测量 DNS、TCP、TLS 和应用响应，不要只看总耗时。
- 检查源站排队。查看 Web 服务工作进程、线程池、数据库连接池、CPU、内存和磁盘 I/O 是否在慢请求发生时同步升高。
- 调整连接策略。启用安全的长连接和连接复用，设置连接上限，避免代理层与应用层的空闲超时互相冲突。
- 收紧重试规则。区分连接失败、读取超时和业务错误，限制可重试请求，并记录每次重试的原因。
- 验证改动。先在低比例流量或单个源站实例上观察，再比较 P95、P99、错误率和源站资源消耗。
还要留意响应内容和缓存策略
源站每次都实时生成相同内容，会让回源请求承担不必要的计算。对可缓存的静态文件、版本化脚本和不含用户隐私的公共接口，可以设置明确的缓存控制与失效规则。相比永久缓存，按内容版本更新资源通常更容易控制一致性。
动态内容也应减少无效工作，例如只返回必要字段、避免重复查询，并为慢 SQL 建立索引。但数据库索引并非越多越好，写入频繁的表会承担额外维护成本，修改前应结合执行计划和实际查询观察。
常见问题
回源带宽没有跑满，为什么仍然很慢？
带宽只说明传输能力未达到上限，不能代表 DNS、建连、TLS、源站排队和数据库处理没有延迟。应先查看分阶段耗时。
增加源站数量一定能提速吗？
不一定。若瓶颈在数据库、共享存储、网络出口或连接池，新实例可能只是把压力转移到公共依赖上。
长连接是否适合所有请求？
高频、短响应请求通常更适合连接复用；低频或资源受限的源站则要控制空闲连接数量，避免连接长期占用资源。
缓存命中率提高后，还需要做回源优化吗？
需要。未命中请求、缓存失效、回源校验和突发流量仍会访问源站。服务端回源速度优化可以降低这些请求对整体体验的影响。
总的来说，服务端回源速度优化应从分段测量开始，再处理连接复用、超时重试、DNS、TLS、源站排队和缓存策略。只有确认瓶颈所在，扩容带宽或增加实例才不会变成成本更高但效果有限的操作。