Nginx server_name匹配混乱的核心是生效顺序而非配置书写，需用nginx -T确认真实加载结构，重点排查default_server、隐式兜底、Host头大小写及通配符覆盖规则，避免请求被静默路由至错误server块。
排查 server_name 匹配顺序混乱，核心不是看“写了什么”，而是确认“实际生效的是哪一个”。Nginx 不报错、不中断，只默默把请求交给错误的 server 块——比如访问 api.example.com，结果返回了默认站的 404 或跳转到了测试环境。
查最终加载的配置结构
用 nginx -T 输出合并后的真实配置，这是唯一可信依据：
-
nginx -T 2>/dev/null | grep -A 10 "server_name.*api\.example\.com"—— 查该域名是否被加载、出现在哪个文件、是否重复 -
nginx -T 2>/dev/null | grep "listen.*80" -A 5—— 列出所有监听 80 的 server 块，观察顺序、default_server 标记、以及是否有多个块都声明了相同 server_name - 重点留意警告：如
conflicting server name "api.example.com" on 0.0.0.0:80, ignored，说明后加载的同名块已被静默丢弃
验匹配优先级是否被绕过
匹配不是“找到就停”，而是严格按固定顺序逐级筛选。常见误判点：
- 只配了
server_name api.example.com，但用户访问的是www.api.example.com或API.EXAMPLE.COM（区分大小写），完全不匹配 - 用了
*.example.com，但它不匹配example.com；若需支持主域，必须显式加上example.com - 正则匹配（如
~^api\..*）一旦命中，立即终止搜索，后续更精确的块也无效
测真实请求路由路径
别依赖文件名或目录位置，用真实 Host 头验证谁在响应：
- 用
curl -H "Host: api.example.com" http://127.0.0.1绕过 DNS，直连本地 Nginx，看返回内容是否符合预期 - 临时重命名疑似“抢流量”的兜底配置（如把
00-default.conf改为99-default.conf），重启后观察问题是否反转 - 在可疑的兜底块里加
return 444;或access_log /var/log/nginx/catch-all.log;，检查日志中是否有不该进来的 Host 请求
盯 default_server 和隐式兜底
没设 default_server ≠ 安全。Nginx 会把同一端口下第一个定义的 server 块当作隐式兜底：
- IP 直接访问（如
http://192.168.1.100）时 Host 头为空，必然落入第一个块或带default_server的块 - 用
nginx -T 2>/dev/null | awk '/^server {/,/^}/ {if (/listen.*80/) print FILENAME ":" NR; if (/server_name/) print " " $0}'快速定位所有 80 端口块及其加载顺序 - 兜底块建议统一命名为
99-default.conf，且明确带listen 80 default_server，避免被其他 include 顺序干扰
