Nginx 多 server 块匹配按优先级：精确匹配 > 最长前导通配符 > 最长后缀通配符 > 正则；无匹配时启用显式 default_server 或隐式首个 server；HTTP/HTTPS 必须分设独立 server 块。
当 Nginx 配置中存在多个 server 块时，请求到底匹配哪一个，并不取决于它们在配置文件中的书写顺序，而是由一套明确的优先级匹配规则决定。理解这个机制，是避免“配置写了却不生效”“域名跳转错乱”“HTTPS 被 HTTP 拦截”等典型问题的关键。
server_name 匹配优先级：精确 > 通配符 > 正则
Nginx 在同一端口（如 80 或 443）下，会先筛选出所有监听该端口的 server 块，再根据 server_name 字段逐级比对：
-
完全匹配：比如
server_name example.com;仅匹配example.com（不含 www、子域或带端口的 Host） -
最长前导通配符：如
server_name *.example.com;匹配api.example.com、www.example.com，但不匹配example.com或test.api.example.com -
最长后缀通配符：如
server_name example.*;匹配example.org、example.net（Nginx 1.11.10+ 支持） -
正则表达式：以
~开头（区分大小写）或~*（不区分），例如server_name ~^www\d+\.example\.com$;；正则匹配成功后立即终止搜索，不再比较后续 server 块
注意：通配符和正则不会混用比较。Nginx 先找所有精确匹配，没有就找最长前导通配符，还没有才看后缀通配符，最后才执行正则匹配——且一旦正则命中即停止。
默认 server 的判定逻辑
当 Host 头无法匹配任何 server_name 时，Nginx 会启用“默认 server”。它的选择规则是：
- 显式标记：
listen 80 default_server;或listen 443 ssl http2 default_server;的 server 块，无论server_name是什么，都作为兜底 - 隐式 fallback：若未设
default_server，Nginx 将使用**该端口下第一个出现的 server 块**（按配置文件加载顺序，非语法顺序）作为默认项——这容易引发意外行为
建议始终显式声明 default_server，尤其在多站点共用 80/443 端口时，可单独建一个返回 444（关闭连接）或 404 的最小化默认块，防止信息泄露或误响应。
端口与 SSL 配置影响匹配范围
不同 listen 指令会让 server 块处于不同匹配池中：
-
listen 80;和listen 443 ssl;完全隔离——HTTP 请求永远不会进入只监听 HTTPS 的 server 块 - 同一端口但协议不同（如
listen 443;vslisten 443 ssl;）会被视为冲突，Nginx 启动时报错 - IP 绑定也参与区分：
listen 192.168.1.10:80;和listen *:80;属于不同监听上下文，前者仅响应发往该 IP 的请求
常见陷阱：把 HTTP 和 HTTPS 配置写在同一 server 块里（如 listen 80; listen 443 ssl;），会导致非 HTTPS 请求被强制走 SSL 流程而报错；应拆分为两个独立 server 块，分别处理明文与加密流量。
调试与验证方法
光看配置难判断实际匹配结果，需结合工具验证：
- 运行
nginx -t检查语法，再用nginx -T（大写 T）输出**最终合并后的完整配置**，确认 server 块加载顺序和 default_server 标记是否符合预期 - 用
curl -H "Host: test.example.com" http://127.0.0.1模拟特定 Host 请求，配合access_log中的$server_name变量记录实际匹配到的 server_name - 在关键 server 块中临时添加
return 200 "matched: $server_name\n";，直观查看响应来源
不复杂但容易忽略：server 块是否被 include 进主配置、是否因语法错误被静默跳过、SSL 证书路径是否存在，都会导致看似“已配置”的块实际未生效。
