Nginx的server_name匹配按“精确→前缀通配→后缀通配→正则”优先级树执行，不依赖配置书写顺序；可通过nginx -T查看展开配置、日志记录$host与$server_name字段验证实际匹配结果。
排查 server_name 匹配顺序问题，核心是理解 Nginx 的匹配逻辑：它不是按配置文件书写顺序逐行匹配，而是先构建“精确匹配 → 通配符前缀匹配 → 通配符后缀匹配 → 正则匹配”的优先级树，再按规则选最优项。错乱往往源于对这个机制的误判。
确认 server_name 实际生效顺序
Nginx 启动时会将所有 server_name 条目归类并排序，不依赖配置位置。可通过以下方式验证：
- 运行
nginx -t -q（静默测试），不会直接显示顺序，但能发现重复或语法错误； - 启用
error_log /path/to/log notice;，然后重载配置，日志中会出现类似"*201 no resolver defined to resolve example.com"（若含变量）或更关键的"using configuration file /etc/nginx/nginx.conf"提示——虽不列顺序，但可确认是否加载了预期块； - 最可靠方法：用
nginx -T（大写 T）输出**全部展开后的配置**（含 include），人工搜索各server { ... }块，结合server_name值和上下文判断哪些可能被优先命中。
识别常见匹配冲突模式
以下情况极易导致意料外的匹配结果：
-
精确域名与泛域名共存：如同时存在
server_name example.com;和server_name *.example.com;，访问example.com会命中精确项，但访问www.example.com会命中泛域名项——这本身正确；但若误以为www.example.com应走另一个带www的精确项，就说明漏写了该条目； -
通配符方向混淆：Nginx 只支持
*.example.com（前缀通配）和example.*（后缀通配），不支持www.*.com或*.example.*；写错会导致该server块完全不参与匹配； -
正则表达式未加 ~ 符号：如写成
server_name ^www\..+（缺~），Nginx 当作普通字符串处理，无法触发正则逻辑；正确应为server_name ~^www\..+； -
空 host 或 _ 匹配兜底过度：
server_name _;或未设server_name的 default_server，会捕获所有未被其他块明确匹配的请求——若放在非预期位置，容易“吃掉”本该由其他块处理的流量。
定位具体请求落入哪个 server 块
在目标 server 块内添加临时日志，直接观测匹配结果：
- 在对应
server { ... }内加入：
access_log /var/log/nginx/debug-example-com.log main; - 或更直观地记录匹配依据：
log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$host" "$server_name"';
access_log /var/log/nginx/debug.log debug; - 发起测试请求（如
curl -H "Host: test.example.com" http://your-server-ip），检查日志中$host和$server_name字段是否符合预期。
强制指定默认 server 并控制优先级
避免隐式 default_server 干扰，显式声明且确保唯一：
- 在
listen指令后加default_server，例如：
listen 80 default_server; - 该修饰符只能在一个
server块中出现（同端口下），否则启动报错； - 若需多个域名共用同一配置，用空格分隔：
server_name example.com www.example.com api.example.com; - 避免在不同文件中分散定义相同域名——Nginx 会合并，但易引发维护混乱和覆盖误判。
