server_name 匹配客户端请求的 Host 头，按精确名→左通配符→右通配符→正则顺序优先级匹配，不依赖配置顺序；未匹配时交由 default_server 处理。

server_name 指令到底匹配什么

server_name 不是“绑定域名”，而是定义 Nginx 如何根据 Host 请求头选择虚拟主机。它只在 HTTP/1.1 协议下起作用，且必须与客户端实际发送的 Host 字段完全（或按规则）匹配，Nginx 才会把请求路由到该 server 块。

常见误解是以为配置了 server_name example.com 就能通过 IP 直接访问该站点——其实不会，除非你额外配了 default_server 或用 listen 80 default_server 显式指定兜底。

• 精确匹配优先：比如 server_name api.example.com 只响应 Host: api.example.com
• 通配符只支持前导 *：如 server_name *.example.com 匹配 foo.example.com，但不匹配 example.com 或 foo.bar.example.com
• 正则匹配需加波浪线：server_name ~^www\d+\.example\.com$，注意转义点号和美元符
• 空字符串 server_name "" 可匹配 Host 为空或缺失的请求（某些代理或旧客户端可能发这种）

多个 server_name 共存时的匹配顺序

Nginx 对 server_name 的匹配不是“从上到下”，而是按**三类优先级分组比对**：精确名 → 左通配符（*.example.com）→ 右通配符（www.*）→ 正则（按配置文件中出现顺序）。同一组内才按书写顺序。

这意味着：

server_name example.com *.example.com www.example.com;

server_name *.example.com example.com www.example.com;

• 不要指望靠写序控制通配符优先级；想让 www.example.com 走特定配置，就单独写一行 server_name www.example.com
• 正则匹配最慢，且一旦命中就停止查找，所以把高频正则放前面
• 如果所有 server_name 都不匹配，Nginx 会交给标记为 default_server 的那个 server 块处理

server_name 配置错误导致 404 或跳转到错误站点

典型现象是：浏览器输入 https://a.com 却打开 b.com 的页面，或者返回 404 —— 很可能是因为 server_name 写错、漏写，或没设 default_server 导致请求被第一个 server 块“误收”。

• 检查是否遗漏了 www 变体：server_name example.com www.example.com 比只写一个更稳妥
• HTTPS 站点必须在 listen 443 ssl 的 server 块里也配对应的 server_name，否则 SNI 后仍可能选错块
• 使用 curl -H "Host: wrong.com" http://your.ip 可模拟异常 Host 请求，验证匹配逻辑
• 日志里看 $host 和 $server_name 变量值，确认实际匹配到了哪个块

泛域名与本地开发场景下的特殊写法

开发时常用 *.test 或 localhost，但要注意系统 hosts 文件、DNS 解析和浏览器限制。

• server_name ~^(?[^.]+)\.test$ 可捕获子域到变量 $subdomain，后续可用在 root 路径里，比如 root /var/www/$subdomain;
• server_name _ 是“无效名称占位符”，常用于兜底 server，但它不匹配任何真实 Host，仅当无其他匹配且未设 default_server 时生效（不推荐依赖）
• Chrome 对 .localhost 和 .test 有特殊解析策略，但 Safari 和某些移动浏览器可能不认，建议开发环境统一用 127.0.0.1 xxx.test 并配好 hosts
• 容器或 Docker 环境中，宿主机 hosts 不影响容器内 Nginx，得在容器内维护或用 --add-host