Nginx通配符匹配优先级为前缀通配符（如.example.com）>后缀通配符（实际不被原生支持，example.无效）>正则表达式，且只允许在最左或最右单点出现；.example.com匹配一级子域（如www.example.com、api.example.com），不匹配根域example.com或二级子域dev.test.example.com；多个前缀通配符共存时取最长匹配；精确匹配始终最高优先级，与配置顺序无关。
通配符匹配不是“写在哪就用哪”，而是按固定优先级参与整体比对，且写法受限——只允许 * 在最左或最右单点出现，中间带星号（如 www.*.com）或多个星号（如 *.ex*.com）均无效。
前缀通配符 *.example.com
匹配任意一级子域名，比如 api.example.com、shop.example.com，但不匹配 example.com（无子域）或 dev.test.example.com（二级及以上子域）。它也不匹配 www.example.com 吗？——会匹配，因为 www 是一级子域。注意：该规则仅支持单层通配，不能跨层级泛化。
- 多个前缀通配符共存时，选“最长匹配”：若同时配置
*.example.com和*.api.example.com，则请求backend.api.example.com会命中后者 - 它优先级高于后缀通配符，但低于所有精确匹配
- 书写建议统一小写，虽然 Nginx 内部转小写比较，但混写易引发维护歧义
后缀通配符 example.* 不被原生支持
Nginx 官方并不识别 example.* 这类写法，配置后会被当作非法语法或退化为字符串匹配，导致不可预期行为。所谓“后缀通配”实际是误传；真正能实现多 TLD 匹配（如 example.com / example.cn）的，只能靠正则表达式，例如：
server_name ~^example\.(com|cn|org)$;- 必须加引号包裹，且以
~或~*开头，否则会被当成普通文本处理 - 这种写法性能较低，仅建议在必要场景使用，避免高频请求路径依赖它
通配符与精确匹配共存时的真实逻辑
哪怕你把 *.example.com 写在配置文件最前面，只要请求 Host 是 www.example.com，而你又单独写了 server_name www.example.com;，Nginx 就一定会选这个精确项——不是看顺序，而是看匹配类型优先级。常见误区是以为“先写先生效”，其实完全相反。
- 可在一个
server_name指令中并列多个精确值：server_name example.com www.example.com shop.example.com; - 多个精确值之间无优先级差异，只要 Host 头与其中任一完全一致（大小写不敏感），即命中
- 若多个 server 块都含相同精确域名，Nginx 采用“首个定义”的块，这是唯一依赖顺序的地方
为什么通配符有时不生效？常见陷阱
最常踩的坑不是写错优先级，而是 DNS 或客户端请求本身没发对 Host 头。比如浏览器访问 http://example.com 却没带 Host: example.com（极少见），或反向代理透传丢失 Host，都会导致通配符形同虚设。
- 检查请求是否真实携带目标 Host：用
curl -H "Host: api.example.com" http://your-server-ip手动模拟 - 确认没有遗漏
default_server，否则未匹配请求可能落入第一个 server 块，掩盖通配符失效问题 - 避免混用通配符和正则在同一作用域，尤其当正则未加引号或漏写
~，Nginx 可能静默降级为文本匹配，行为难以调试
