从抓包分析SNI工作原理：为什么你的旧版curl访问Nginx会报证书错误？

从抓包分析SNI工作原理：为什么你的旧版curl访问Nginx会报证书错误？

最近在帮一个朋友排查一个奇怪的HTTPS问题。他的后端服务运行在Nginx上，配置了多个域名共享同一个IP和443端口，每个域名都有自己的SSL证书。用现代浏览器访问一切正常，但当他尝试用一台老旧的CentOS 7服务器上的curl命令去测试接口时，却总是收到一个令人困惑的证书错误：“SSL: no alternative certificate subject name matches target host name”。更奇怪的是，直接用IP地址加上Host头去访问，错误依旧。他一度怀疑是证书配置错了，反复检查了server_name和证书的SAN字段，都对得上。最后，我们把目光投向了那个几乎被遗忘的curl版本——7.29.0。问题就出在这里，而背后的核心机制，是一个叫做SNI的TLS扩展。

如果你也遇到过类似场景：在容器化环境、微服务网关或者传统的虚拟主机配置中，使用一些老旧的命令行工具、特定版本的JDK或者遗留的客户端库去访问HTTPS服务时，莫名其妙地证书验证失败，那么这篇文章就是为你准备的。我们将绕过那些泛泛的概念解释，直接深入到网络数据包层面，用Wireshark抓包对比，亲眼看看SNI是如何工作的，以及当它缺失时，整个TLS握手是如何“跑偏”的。更重要的是，我会分享一些实用的诊断方法和替代方案，让你在不得不面对老旧环境时，也能游刃有余。

1. SNI：TLS握手阶段的“自我介绍信”

在深入抓包之前，我们得先搞清楚SNI到底解决了什么问题。在早期的HTTPS世界里，一个普遍的假设是：一个IP地址对应一个域名，进而对应一张SSL证书。当客户端（比如浏览器）连接到服务器的443端口时，服务器会毫不犹豫地把它唯一的那张证书发过去。客户端用这张证书里的信息（Common Name或Subject Alternative Name）来验证自己访问的域名是否被允许。

但随着虚拟主机技术的普及，尤其是云计算的兴起，这个模型不够用了。一台服务器（一个IP）可能需要服务几十个甚至上百个不同的域名，每个域名都希望使用自己专属的、受信任的证书。如果还按照老规矩，服务器在TLS握手一开始就得发送证书，但它该发哪一张呢？它此时根本不知道客户端想访问哪个域名——HTTP请求的Host头要在TLS握手成功、加密通道建立之后才会被发送。

SNI就是为了打破这个僵局而生的。它的全称是Server Name Indication，定义在RFC 6066中。其核心思想非常简单：让客户端在TLS握手最开始发送的Client Hello消息里，就捎带上自己打算访问的服务器主机名（hostname）。这样，服务器在决定发送哪张证书之前，就已经知道了客户端的意图。

这个过程可以类比为你去一个大型写字楼的前台。以前（无SNI），你只说“我要办业务”，前台只能给你默认的、最大众的办事窗口。现在（有SNI），你一开始就说“我要找A公司办业务”，前台就能直接把你引导到A公司的专属柜台。SNI就是那句关键的“我要找A公司”。

注意：SNI信息在Client Hello中以明文形式传输。这是设计使然，因为加密通道尚未建立。因此，从隐私角度，旁观者可以知道你正在连接哪个域名，尽管还看不到后续的具体内容。

1.1 一个关键变量：$ssl_server_name

对于Nginx管理员来说，理解SNI有一个非常直接的体现，那就是内置变量$ssl_server_name。这个变量只有在客户端启用了SNI扩展的TLS连接中才会被赋值，其内容就是客户端在Client Hello里声明的服务器名称。

这个变量非常有用，它使得Nginx的配置可以变得更加动态和简洁。例如，你可以根据不同的$ssl_server_name，动态地加载不同路径下的证书和密钥，甚至代理到不同的上游服务，而无需为每个域名编写重复的server块。原始资料中提到的map指令搭配$ssl_server_name，正是这种高级用法的体现。

检查你的Nginx是否支持SNI及相关变量，可以使用：

nginx -V 2>&1 | grep -o with-http_ssl_module

只要编译时包含了--with-http_ssl_module（现在几乎是标配），SNI支持就是默认开启的。

2. 抓包实战：对比有无SNI的TLS握手

理论说再多，不如亲眼所见。让我们搭建一个简单的实验环境，用Wireshark抓包，直观地对比支持SNI和不支持SNI的客户端行为差异。

2.1 实验环境准备

假设我们有一台Nginx服务器，IP为192.168.1.