SafeLine WAF 与 APISIX 集成中的 SNI 问题解析与解决方案

问题背景

在企业级 Web 应用架构中，SafeLine WAF 作为安全防护层，经常需要与 APISIX 这类高性能 API 网关配合使用。当两者以 HTTPS 方式协同工作时，可能会出现 SNI(Server Name Indication)信息传递异常的问题，导致后端服务无法正确识别请求的目标域名。

技术原理

SNI 是 TLS 协议的扩展，允许客户端在握手阶段指明要连接的主机名。这对于现代多租户架构尤为重要，因为同一 IP 地址可能托管多个 HTTPS 站点。当 SafeLine WAF 作为反向代理处理 HTTPS 流量时，需要确保 SNI 信息能够正确传递给上游的 APISIX 网关。

问题现象

在 SafeLine 4.1.1 版本中，当配置 SafeLine 作为 APISIX 的前置代理时，APISIX 无法正确解析 SNI 信息，导致以下典型症状：

1. APISIX 日志中出现 SNI 解析失败的错误
2. 请求无法正确路由到后端服务
3. 虽然证书配置相同，但访问时提示源站点错误

根本原因

SafeLine 的 Nginx 代理配置默认未开启 SNI 信息传递功能。当 WAF 处理 HTTPS 请求后转发给上游 APISIX 时，SNI 信息未被包含在代理请求中，导致 APISIX 无法识别原始请求的目标域名。

解决方案

在 SafeLine 的 Nginx 代理配置中添加以下关键参数即可解决问题：

proxy_ssl_server_name on;
proxy_ssl_name $http_host;

这两个配置的作用分别是：

1. proxy_ssl_server_name on：启用 SNI 信息传递
2. proxy_ssl_name $http_host：指定使用原始请求的 Host 头作为 SNI 值

最佳实践建议

1. 对于 SafeLine 4.2.0 及以上版本，该功能已内置实现
2. 在混合架构中，建议明确规划 SNI 信息的传递路径
3. 当上游服务为 HTTPS 时，应确保 SNI 信息的连续性
4. 在多租户环境中，证书管理应保持一致性

架构设计思考

这种问题的出现反映了现代 Web 安全架构中一个常见的设计考量：安全组件与流量路由组件的协同工作。WAF 作为安全层，在提供防护功能的同时，应尽可能保持原始请求的完整性，包括 TLS 层面的元数据信息。

总结

SafeLine WAF 与 APISIX 网关的集成问题，本质上是代理链中 SNI 信息传递的完整性问题。通过正确的配置，可以确保安全防护不破坏原有的服务路由机制。对于使用类似架构的企业，理解并处理好这类底层协议细节，是构建稳定、安全的应用交付体系的关键。