LB禁用TLS<1.2后SSO低版本TLS接口延迟故障原因咨询

这事儿其实挺常见的，核心原因是TLS连接/会话的复用机制以及客户端侧的缓存、长连接策略，导致禁用低版本TLS的影响不是立刻生效，而是延迟了几天。下面具体拆解几个最可能的原因：

• TLS会话复用（Session Resumption）
  当LB还允许低版本TLS时，客户端和LB已经建立过TLS会话，LB或客户端会缓存会话凭证（比如会话ID或者会话票证）。这些凭证的有效期通常是几小时到几天不等（不同LB的默认配置有差异，比如有的是24小时，有的更长）。在凭证有效期内，客户端不需要重新发起完整的TLS握手，直接复用之前的会话就能正常通信——哪怕LB已经禁用了低版本TLS，只要复用的是旧会话，依然能正常传输数据。直到会话凭证过期，客户端才会尝试发起新的握手，这时就会因为LB拒绝低版本TLS而失败。

• 客户端长连接的持续存活
  很多客户端（比如浏览器、HTTP客户端库）会和LB保持长连接（Persistent Connections），这些连接是在LB变更前建立的，使用的是低版本TLS协议。只要这个长连接没被LB或客户端主动断开（比如超时时间设置为几天），就能一直用来传输数据。只有当长连接断开，客户端需要新建连接时，才会触发新的TLS握手，这时才会遇到LB的新限制。

• SSO会话的有效期延迟
  你的场景是SSO应用，用户登录后获得的SSO会话凭证（比如Cookie）通常有效期较长（比如7天）。在SSO会话有效期内，客户端不需要重新登录，也就不需要和LB发起新的TLS握手来获取令牌——只要之前的连接还能用，就一直走旧连接。直到SSO会话过期，客户端需要重新登录时，才会发起新的TLS连接，这时才会暴露问题。

• 非实时的客户端访问
  有些接口是定时任务、批量任务或者低频访问接口，它们不会在LB变更后立刻发起请求，而是隔几天才触发一次。比如某个每周执行一次的同步任务，LB变更后它还没到运行时间，等几天后任务启动时，才第一次尝试用新的TLS握手连接LB，这时才会发现连接失败。

总结来说，本质就是旧的合法连接/会话还在有效期内，所以能继续正常工作；当这些旧连接/会话过期或需要新建时，才会触发新的TLS握手，进而被LB的新规则拦截。

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