关键在于用nginx -T查看最终合并配置以确认加载顺序与覆盖关系，Nginx按字典序读取/etc/nginx/conf.d/*.conf，同端口同server_name会冲突并静默忽略后者，应统一数字前缀命名、避免域名命名，并通过nginx -T定位重复server块及location错位问题。
排查 Nginx 配置文件加载顺序混乱，关键不是“找哪一行写错了”，而是看清 Nginx 实际合并后的配置结构——因为最终生效的不是你写的单个文件，而是所有 conf 按序合并、覆盖、裁剪后的结果。
看最终生效的完整配置
运行 nginx -T（注意是大写 T），它会输出 Nginx 启动时实际解析并合并后的全部配置，包括所有 include 进来的块、按字典序加载的 conf 文件内容、以及 server 块的实际排列。这是唯一能确认“谁覆盖了谁”的权威依据。不要只依赖 nginx -t，它只校验语法，不反映加载逻辑。
检查 conf 文件名排序是否合理
Nginx 默认按字典序读取 /etc/nginx/conf.d/*.conf。如果存在 aa.com.conf、ab.com.conf、bb.com.conf，那么 ab.com.conf 会先于 bb.com.conf 加载。一旦它们监听相同端口（如 80）且都声明 server_name bb.com，后者就会被静默忽略，并在 error.log 中报：
conflicting server name "bb.com" on 0.0.0.0:80, ignored
- 统一用数字前缀规范命名：如
00-main.conf、10-api.conf、99-default.conf - 避免用域名直接命名（如
example.com.conf），易因字母序导致意外交替 - 用
ls -1 /etc/nginx/conf.d/确认当前加载顺序
定位重复的 server 块冲突点
在 nginx -T 输出中搜索 server {，逐个查看每个 server 块的 listen 和 server_name 组合。同一端口下，以下任一情况都会引发冲突：
- 两个块都写
listen 80;+server_name example.com; - 一个写
listen 80 ssl;，另一个也写listen 80;且未加default_server标识 - HTTPS 和 HTTP 混在同一块里（如同时有
listen 80和listen 443 ssl）——Nginx 不允许，会拒绝加载
发现重复后，删掉冗余定义，或改用 include 抽离公共配置（如日志格式、SSL 参数），避免复制整个 server 块。
验证静态资源和 location 是否被错误覆盖
加载顺序混乱常导致 location 匹配错位。例如：app1.conf 定义了 location /static/，而 99-default.conf 里有个兜底的 location / 且排在后面，就可能让 /static/logo.png 被 proxy_pass 到后端而非本地返回。
- 在
nginx -T输出中搜索具体路径（如/static/），确认其所在 location 块归属哪个 conf 文件 - 对关键静态路径使用
^~前缀强制前缀匹配优先级，如location ^~ /app1/static/ { alias /path/app1/static/; } - 确保不同服务的静态路径有明确区分前缀（如
/app1/static/、/app2/static/），不共用根级/static/
