Nginx作为全球范围内应用最广泛的高性能Web服务器和反向代理服务器，其处理多域名请求的能力是构建现代网络服务的基础。Nginx主要通过解析HTTP请求头中的Host字段或SSL握手过程中的SNI（Server Name Indication）信息来获取域名，并依据配置文件中的server_name指令进行精确匹配、通配符匹配或正则表达式匹配，从而定位到具体的虚拟主机配置块。 这一机制使得单一服务器实例能够高效托管成百上千个不同的网站,实现资源的集约化利用。
HTTP协议层与SSL层的域名获取机制
在深入配置之前，必须理解Nginx在不同网络协议层级获取域名的底层逻辑，对于HTTP/1.1及后续版本的HTTP明文传输，Nginx依赖请求头中的“Host”字段，当客户端浏览器发起请求时，会在HTTP头部包含Host信息，告知服务器它想访问的是哪个域名，Nginx接收到请求后,直接提取该字段的值进行后续的路由匹配。
在HTTPS加密传输场景下，情况则更为复杂，由于SSL/TLS握手发生在HTTP请求解析之前，服务器在建立加密连接时需要立即返回正确的SSL证书，为了解决这一问题，Nginx利用SNI（Server Name Indication）技术，SNI是SSL/TLS协议的扩展，允许客户端在发送握手请求的初始阶段，也就是证书交换之前，就将目标域名发送给服务器。Nginx通过解析SNI信息获取域名，进而选择对应的SSL证书和虚拟主机配置，这是实现HTTPS多域名虚拟主机的关键技术前提。
server_name指令的匹配规则与优先级
获取到域名后，Nginx核心的工作是将该域名与配置文件中的server_name指令进行匹配。server_name指令不仅决定了请求由哪个Server块处理，还直接影响Nginx的哈希表查找效率，其匹配遵循严格的优先级顺序,理解这一顺序对于排错至关重要。
精确匹配，如果Nginx获取到的域名与配置中的server_name完全一致（例如server_name example.com;），则立即停止搜索并使用该配置块,这是优先级最高且性能最好的匹配方式。
通配符匹配，如果在精确匹配中未找到结果，Nginx会尝试通配符匹配，通配符分为前缀通配符（如*.example.com）和后缀通配符（如example.*）。值得注意的是，前缀通配符和后缀通配符的匹配优先级高于正则表达式，但低于精确匹配。 在通配符匹配中，Nginx优先匹配长名称，例如*.www.example.com会优先于*.example.com被匹配。
正则表达式匹配，如果上述匹配均失败，Nginx会按照配置文件中的出现顺序，依次检查使用正则表达式定义的server_name（例如server_name ~^(?<subdomain>.+)\.example\.com$;），一旦匹配成功，Nginx不仅会选中该Server块,还会将正则捕获的变量赋值给内部变量供后续使用。
核心内置变量的深度解析与应用
在Nginx获取域名并进行处理的过程中，有几个核心内置变量经常被混淆，但在实际业务逻辑中却有着截然不同的用途，精准区分$host、$server_name和$http_host,是编写复杂重定向或日志记录规则的关键。
$http_host代表的是客户端请求头中Host字段的原始值，这个变量最为“诚实”，它包含了客户端发送的所有信息，包括端口号（如果客户端显式指定了非标准端口），正因为它是原始值，如果客户端构造恶意的Host头，直接使用$http_host可能会导致安全漏洞。
$server_name则是Nginx配置文件中被选中的server_name的值，它是服务器端的配置定义，不随客户端请求而改变，在需要强制使用配置中定义的标准域名进行跳转时，使用$server_name是最安全、最规范的做法。
$host变量是Nginx根据优先级逻辑处理后的结果，它的取值顺序依次是：请求行中的域名、Host请求头中的域名、最后回退到匹配到的server_name。在实际生产环境中，推荐优先使用$host变量，因为它既保留了客户端的意图，又在客户端未提供Host头时提供了合理的默认值，具备较好的容错性。
反向代理场景下的域名传递与获取
在作为反向代理服务器部署时，Nginx获取域名的职责不仅仅是路由，还包括将域名信息传递给后端的上游服务器，默认情况下，Nginx会将原始请求的Host头传递给后端,但这并不总是符合业务需求。
如果后端服务器需要识别原始访问的域名（例如在多租户SaaS应用中），必须确保Nginx正确透传了域名信息，通常使用proxy_set_header Host $host;指令来显式设置。但在某些特殊架构下，如果后端服务器配置了特定的虚拟主机监听名，则需要将Host头修改为后端服务器的域名，例如proxy_set_header Host backend.internal.com;，为了防止后端服务器获取到包含端口的Host头导致校验失败，建议结合proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;使用,构建完整的透传上下文。
生产环境下的域名获取优化与安全
在掌握了基础获取机制后，从专业运维的角度，还需要关注域名获取过程中的性能优化与安全加固，Nginx使用哈希表来存储静态的精确匹配和通配符匹配的server_name，这使得查找速度极快，时间复杂度接近O(1)，正则表达式匹配是线性遍历的。在高并发环境下，应尽量避免在server_name中使用复杂的正则表达式，或者将高频访问的域名配置为精确匹配，以减少不必要的计算开销。
安全方面，必须定义一个默认的Server块来处理非法域名的请求，当Nginx获取到的域名无法匹配任何server_name时，它会默认使用第一个配置的Server块，为了防止域名劫持或混淆攻击，应当显式配置listen 80 default_server;，并在该块中直接返回444状态码（直接关闭连接）或重定向到规范的错误页面。这一配置是防御未授权域名解析指向服务器的最后一道防线。
相关问答
Q1：为什么在配置了HTTPS后，Nginx总是返回默认网站的证书，而不是对应域名的证书？
A： 这种情况通常是因为Nginx没有正确获取到SNI信息，或者配置中缺少对应的server_name，请确保客户端（浏览器或测试工具如curl）支持SNI（现代环境基本都支持），检查Nginx配置文件，确保每个域名的SSL证书配置都在独立的server块中，并且该块正确配置了server_name，如果多个域名共用一个IP和端口，Nginx依赖SNI来选择证书，如果SNI不匹配或缺失,它将回退到使用默认的Server块证书。
Q2：在Nginx配置中，server_name设置为下划线“_”有什么特殊含义？
A： 在Nginx的配置惯例中，server_name _;并不是一个特殊的匹配规则，它仅仅是一个被当作无效域名的字符串，由于它永远不会匹配真实的客户端Host头，因此常被用于定义“默认”Server块，配合default_server标记使用，它可以优雅地处理所有未明确配置的域名请求，例如丢弃请求或返回自定义的“域名未解析”错误页面,这是一种有效的防御性配置手段。
如果您在Nginx域名配置与获取的实际操作中遇到任何疑难杂症，或者有更复杂的场景需要探讨，欢迎在评论区留言,我们将为您提供更具针对性的技术解决方案。
