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 ~^wwwd+.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; 实际行为一致——example.com 这个精确匹配永远胜过 *.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
Nginx 的 server_name 表面简单，实际匹配逻辑藏在协议层和多 server 块协同里；最容易出问题的是 HTTPS + SNI 场景下两个 server 块的 server_name 和证书不一致，或者忘了给 default_server 配 SSL 参数。