Apache APISIX 中处理空 SNI 问题的技术方案

在云原生 API 网关 Apache APISIX 的实际部署中，当与 Oracle Cloud Infrastructure (OCI) 负载均衡器集成时，可能会遇到一个特殊场景：由于 OCI 负载均衡器不支持后端服务器的 mTLS 认证，导致客户端请求时未携带 SNI(Server Name Indication) 信息。这种情况下，APISIX 会抛出 "failed to find SNI" 的错误，中断 TLS 握手过程。

SNI 的工作原理与问题本质

SNI 是 TLS 协议的扩展，允许客户端在握手阶段指明要连接的主机名。现代 TLS 实现普遍依赖 SNI 来选择正确的证书。当请求通过 IP 直接访问或使用旧版协议时，SNI 字段可能为空，这会导致以下问题：

1. 网关无法确定应该使用哪个证书
2. TLS 握手在初始阶段就会失败
3. 后续的 HTTP 通信（包括获取 $host 头）根本无法建立

APISIX 的解决方案：fallback_sni 机制

APISIX 提供了优雅的解决方案——通过配置 fallback_sni 参数指定默认 SNI 值。这个机制的工作流程是：

1. 客户端发起 TLS 连接但未携带 SNI
2. APISIX 检测到空 SNI 后自动使用预设的 fallback_sni
3. 系统根据 fallback_sni 值选择对应的证书完成握手

实施配置要点

要实现这个方案，需要完成以下配置步骤：

1. 在 config.yaml 中启用 fallback_sni 参数并指定默认域名
2. 为该域名预先配置好 SSL 证书资源
3. 建议使用自签名证书并在负载均衡器端配置信任

生产环境注意事项

在实际部署时还需考虑：

1. 证书管理：确保 fallback_sni 对应的证书有效且安全
2. 协议兼容性：某些旧客户端可能不支持 SNI 扩展
3. 监控告警：对空 SNI 请求建立监控机制
4. 安全审计：定期检查此类特殊连接的合法性

这种方案不仅解决了 OCI 负载均衡器的兼容性问题，也为其他可能产生空 SNI 的场景提供了标准化的处理方式，体现了 APISIX 在复杂网络环境下的适应能力。