Nginx仅通过主配置文件中的include指令按书写顺序加载配置，通配符匹配的文件按字典序展开；配置生效取决于上下文位置与运行时匹配规则，验证应使用nginx -T查看完全展开的配置。
Nginx 并不按“目录结构”本身来加载配置文件，而是通过主配置文件（如 /etc/nginx/nginx.conf 或 /usr/local/nginx/conf/nginx.conf）中明确的 include 指令，按书写顺序引入其他配置片段。所谓“默认目录结构中的加载顺序”，本质是 include 路径的展开顺序，而非文件系统层级自动扫描。
主配置文件是唯一入口
Nginx 启动时只读取一个主配置文件，路径由编译参数或启动命令指定（可通过 nginx -t 查看实际加载路径）。所有其他配置都必须由它显式引入：
-
include /etc/nginx/conf.d/*.conf;—— 按字母顺序加载该目录下所有.conf文件（如default.conf、ssl.conf） -
include /etc/nginx/sites-enabled/*;—— 常见于 Debian/Ubuntu，通常配合sites-available和符号链接使用，加载顺序仍取决于通配符展开后的文件名排序 -
include modules-enabled/*.conf;—— 若启用动态模块，也按文件名顺序加载
include 展开严格遵循书写顺序
多个 include 行之间，先写的先加载；同一行中通配符匹配到的文件，按操作系统 readdir() 返回顺序（通常是字典序）加载：
- 例如：
include conf.d/a.conf; include conf.d/z.conf;→a.conf一定在z.conf之前生效 - 而
include conf.d/*.conf;匹配到00-default.conf和99-ssl.conf→ 前者先加载，其server块可能被后者覆盖（若监听相同端口且无server_name精确区分）
配置块作用域决定最终行为
即使文件被加载，指令是否生效还取决于上下文位置：
-
user、worker_processes必须在全局块（main context），写在http块里会报错 -
root、index可出现在http、server或location中，越靠近请求路径的配置优先级越高 - 同级
server块不按文件加载顺序匹配，而是运行时根据listen+server_name构建匹配树，精确匹配 > 通配符 > default_server
验证当前实际加载顺序的方法
最可靠的方式不是猜目录结构，而是让 Nginx 自己“说出来”：
- 运行
nginx -T（大写 T）：输出完全展开后的全部配置，含注释标明每个片段来自哪个文件及行号 - 检查
nginx -t输出：提示“using configuration file /path/to/nginx.conf”，确认主入口 - 观察
error.log：若某include路径不存在或语法错误，会在此处报出具体文件名和位置
