nginx master process 在启动或重载时统一解析所有 include 文件，按字典序读入并文本拼接后整体校验，任一语法错误即失败回退；配置加载为全量重建，无运行时动态加载或热插拔机制。
Nginx 的 Master Process 本身不直接解析或加载配置文件，它的核心职责是读取、校验并初始化配置，再派生 Worker Process 执行实际请求处理。当涉及多个配置文件（如通过 include 指令引入的 .conf 文件）时，整个加载过程发生在 Master 启动或重载阶段，由 Master 主导完成，但关键动作是一次性合并、解析、构建内存配置树，而非“动态逐个加载”。
以下是 Master Process 处理多配置文件加载的关键逻辑：
Master 启动或重载时统一解析所有 include 文件
-
nginx.conf是入口配置文件，其中常见类似语句：include /etc/nginx/conf.d/*.conf; include /usr/share/nginx/http_servers/*.conf;
- Master 在启动（
nginx命令）或收到reload信号（如nginx -s reload或kill -HUP <pid></pid>）时，会递归扫描匹配路径下的所有.conf文件，按字典序读入。 - 所有被 include 的文件内容，会被文本级拼接进主配置上下文，然后整体进行语法解析、语义校验（比如
server块嵌套是否合法、listen是否冲突等）。 - 若任一文件存在语法错误（如缺少分号、括号不匹配），整个 reload 失败，Master 继续使用旧配置，Worker 不重启。
配置加载不是运行时行为，而是周期性重建
- Master 不维护“已加载配置列表”，也不监听文件变化。
- 多配置文件的管理完全依赖
include路径的静态声明——没有自动发现、热插拔或条件加载机制。 - 每次
reload都是全量重建：释放旧配置内存池 → 重新 open + read 所有 include 文件 → 重新 parse → 构建新ngx_cycle_t→ 校验 → 成功则 fork 新 Worker，通知旧 Worker 优雅退出。
实际生效依赖两个前提
-
路径可访问且文件可读：
include路径需对 nginx 运行用户（如nginx或www-data）有读权限；通配符匹配失败（如目录不存在或无.conf文件）不会报错，只是静默跳过。 -
无全局冲突：例如多个
http块、重复的upstream名、相同listen地址+端口的server，都会在nginx -t或 reload 时被拒绝。
推荐做法确保多配置稳定生效
- 使用
nginx -t测试后再 reload，避免服务中断 - 将功能模块拆分（如
ssl.conf、proxy.conf、cors.conf），用语义化文件名便于维护 - 避免跨目录循环 include（如 A.conf include B.conf，B.conf 又 include A.conf），会导致解析失败
- 修改任意一个被 include 的文件后，都必须执行 reload，不能只靠改某个子文件就生效
Master Process 在这个过程中就像一位严谨的建筑师：它不关心砖块（单个 conf 文件）从哪来，但会把所有图纸（全部 include 内容）摊开核对一遍，确认无误才下令开工。
