ReCAPTCHA Site Verify API SSL握手延迟问题排查求助

结合你描述的现象——仅20%请求在SSL握手阶段延迟、无固定Pod/地域关联、近期无自身配置变更，以下是几个高概率的原因：

• 谷歌CDN节点的临时资源瓶颈
  ReCAPTCHA的siteverify接口通过谷歌全球CDN分发，大部分请求会命中负载正常的节点，但小比例请求可能被分配到了临时CPU/内存资源紧张的节点。SSL握手需要完成证书验证、密钥交换等计算密集型操作，节点资源不足时会直接拖慢这个阶段的耗时。

• 出站网络的随机路由波动
  K8s集群的出站流量可能通过动态路由分配不同的网络路径（比如不同ISP线路、中转节点）。部分路径在7月16日后出现临时拥塞、路由跳数增加或中转节点故障，导致SSL握手的数据包往返延迟。这种波动是随机的，不会固定关联到某个Pod或用户地域。

• TLS协商流程的差异化处理
  谷歌可能在7月16日之后调整了siteverify端点的TLS策略，部分请求会触发更耗时的协商逻辑——比如 fallback到兼容性更好但速度更慢的TLS版本，或者使用计算成本更高的加密套件。这种协商结果是随机的，只会影响小比例请求，符合你观察到的20%比例。

• 谷歌侧的临时队列限流
  当某个区域的请求量出现突发波动时，谷歌可能会对部分请求启用临时队列处理，这些请求会在SSL握手前进入等待队列，导致整体延迟。这种限流是局部、临时的，不会呈现明显的地域或Pod关联规律。

• 集群DNS解析的偶发延迟
  虽然你没提到DNS问题，但www.google.com的DNS解析偶尔出现超时或缓存失效时，会间接导致SSL握手的启动时间延后。K8s Pod依赖集群DNS服务，当DNS服务出现偶发性能波动时，延迟会随机出现在不同Pod的请求中。

内容的提问来源于stack exchange，提问作者SangamAngre