nginx虚拟主机匹配优先级为：精确匹配 > 最长前缀通配符 > 最长后缀通配符 > 首个正则匹配；https下依赖sni在tls握手阶段快速分流，server_name顺序加载且命中即止，避免冗余配置与泛域名前置。
直接控制虚拟主机匹配顺序，比依赖大量正则或模糊匹配更有效。Nginx 不会对所有 server 块做全量字符串扫描，而是按加载顺序和 server_name 匹配逻辑快速定位——关键在于让最常用、最明确的 HTTPS 主机配置排在前面，且避免冗余或冲突定义。
优先使用精确 server_name + 独立文件管理
把高频访问的域名（如主站、API 域名）单独写成独立配置文件，用清晰命名（如 01-main.conf、02-api.conf），确保 Nginx 按字母序最先加载它们。Nginx 解析时只顺序比对 server_name，一旦命中就停止查找，不遍历后续块。
- 每个 HTTPS
server块只声明一个明确的server_name，不要堆叠多个域名（如server_name a.com b.com c.com;），除非它们完全同源同配置 - 避免通配符泛域名（如
*.example.com）放在靠前位置，它虽匹配宽泛，但会抑制后续更具体的server_name生效 - 未匹配到任何
server_name的请求，默认落到第一个 HTTPSserver块（即默认主机），可专门设一个最小化兜底块，不参与业务路由
分离 HTTP 与 HTTPS 配置，禁用无用监听
HTTP server 块即使不处理业务，也会参与初始化阶段的监听表构建。若已全站强制 HTTPS，应直接移除所有 listen 80 的 server，或仅保留一条简单重定向规则，减少内存中待匹配的块数量。
- 重定向用
return 301 https://$host$request_uri;，不走rewrite，开销更低 - 确认没有残留的
listen 443 ssl default_server之外的重复默认块，多个default_server会导致 Nginx 启动警告并隐式排序，增加不确定性 - 用
nginx -t验证后，观察nginx -T | grep "server_name"输出，确认实际加载顺序与预期一致
用 SNI 提前分流，减少 server 块内耗
Nginx 在 TLS 握手阶段就能通过 SNI（Server Name Indication）获取客户端想访问的域名，从而直接选择对应 server 块——这个过程发生在 SSL 解密之前，不涉及 location 或正则匹配，性能几乎无损。只要证书配置正确，SNI 就能天然实现“零成本”虚拟主机路由。
- 确保每个 HTTPS
server块都配有对应域名的ssl_certificate和ssl_certificate_key，否则 Nginx 会退回到默认块处理，失去 SNI 优势 - 避免共用同一组证书覆盖过多域名（尤其跨业务线），证书链过长或 OCSP Stapling 响应慢会拖累首字节时间，间接影响 perceived 匹配效率
- 老旧客户端（如 WinXP IE）不支持 SNI，若仍需兼容，应将该流量导向专用兼容块，而非混入主业务流
精简 location 块，别让内部匹配拖累 server 选择
server 块匹配是第一层筛选，真正影响性能的往往是块内大量 location 正则或嵌套判断。HTTPS 性能瓶颈通常不出在“选哪个 server”，而出在“进 server 后怎么找资源”。
- 主
location /尽量用try_files直接落盘，避免 rewrite 循环或 proxy_pass 条件判断 - 静态资源路径（如
/static/、/img/）用^~前缀匹配，比正则快一个数量级，且不回溯 - 彻底删除未使用的
location ~ \.(php|jsp)$类规则——如果后端已统一用 API 网关，Nginx 层就不该再做语言级路由
