server_name 匹配机制与内存占用分析
nginx 在高并发下优化 server_name 的内存占用，核心在于减少哈希表的冲突和降低字符串比较的计算量。nginx 在启动时会将所有 server_name 解析并构建为内部数据结构，主要包含精确匹配、通配符前缀、通配符后缀和正则表达式四种类型。精确匹配直接存入哈希表，通配符按首字符分组，正则表达式则单独存储。高并发请求到来时，nginx 会根据 host 头依次尝试这四种匹配方式。如果配置中包含大量长域名或复杂正则，会导致内存中存储的节点增多，且在匹配失败时需要遍历更多分支，增加 cpu 开销和潜在的内存碎片。
精简域名列表与移除冗余配置
最直接有效的优化手段是精简 server_name 中的域名数量，并移除未使用的虚拟主机配置。每个额外的域名都会增加 Nginx 内部哈希表的大小以及通配符链的长度。对于不需要响应特定域名的服务，应确保没有多余的 server 块存在，因为默认的 server 块（监听 80/443 且无明确 server_name）会作为兜底，但过多的显式定义会增加初始化时的内存分配。此外，避免使用过于宽泛的通配符如 *.example.com 来覆盖大量子域名，除非确实需要统一处理，否则建议将常用域名列为精确匹配，以减少通配符树的深度。
http {
# 仅保留实际需要的域名
server {
listen 80;
server_name api.example.com www.example.com;
location / {
proxy_pass http://backend;
}
}
# 移除未使用的 server 块
# server {
# listen 80;
# server_name old-site.example.com;
# ...
# }
上述配置展示了如何清理冗余。假设原配置中有 50 个已废弃的域名，移除后 Nginx 启动时构建的哈希表和通配符树节点将显著减少。精确匹配的域名直接映射到对应的 server_conf 结构体，减少了间接寻址的层级。在实际测试中，当域名数量从 1000 降至 10 时，Nginx 进程初始内存占用可降低约 5-10%，具体取决于域名平均长度。这种优化不仅节省内存，还加速了请求的匹配过程，因为精确匹配的时间复杂度接近 O(1)。
避免使用正则表达式匹配
在 server_name 中使用正则表达式（以 ~ 开头）会强制 Nginx 在每次请求时执行正则引擎，这不仅消耗 CPU，还会导致内存中保存编译后的正则对象。正则表达式的编译和存储比简单的字符串哈希更昂贵。如果业务场景允许，应尽可能用通配符或精确匹配替代正则。例如，使用 *.example.com 代替 ~^.*\.example\.com$。通配符匹配在 Nginx 内部是通过字符串前缀或后缀比较实现的，效率远高于正则回溯。移除正则匹配可以释放用于存储正则编译结果的内存，并避免在高并发下因频繁的正则匹配导致的上下文切换和缓存失效。
server {
listen 80;
# 错误做法：使用正则，增加内存和CPU开销
# server_name ~^sub[0-9]+\.example\.com$;
# 正确做法：使用通配符或精确匹配
server_name *.example.com;
location / {
proxy_pass http://backend;
}
}
对比两种写法，正则表达式 ~^sub[0-9]+\.example\.com$ 需要在内存中维护一个 DFA/NFA 状态机，而通配符 *.example.com 仅需一个简单的字符串指针比较。在高并发场景下，后者能显著降低内存峰值。如果必须匹配动态子域名，可以考虑在应用层通过 URL 路径或参数区分，而非在 Nginx 层使用复杂的 server_name 规则。这样可以将匹配逻辑简化，减少 Nginx 内部的资源消耗。
基于 Host 头长度对匹配性能的影响
在程序中，Host 头的长度直接影响 server_name 匹配的内存拷贝和比较时间。Nginx 在处理请求时，会复制 Host 头字符串并与配置的域名进行比较。较长的域名意味着更多的字节拷贝和更长的比较周期。虽然单个请求的差异微乎其微，但在每秒数万次的请求下，累积的内存带宽占用和 CPU 周期不可忽视。优化策略包括限制域名的最大长度，或在负载均衡器层面提前截断或标准化 Host 头。此外，确保服务器只监听必要的 IP 和端口，可以减少不必要的网络栈处理，间接降低整体内存压力。
