Nginx Master进程不支持运行时动态加载模块，所有模块必须在编译阶段静态链接；其仅通过配置指令开关、二进制切换或热升级等方式实现类动态能力。

Nginx 的 Master 进程本身不直接支持运行时动态加载模块，这是其架构设计的核心限制之一。所谓“动态加载模块”，在 Nginx 中并不存在类似 Linux 内核模块（insmod）或某些应用服务器（如 Apache 的 DSO）那样的热插拔机制。所有模块必须在编译阶段通过 --add-module 或 --with-xxx-module 显式启用，并静态链接进最终的 nginx 二进制文件中。

Master 进程的角色与模块初始化时机

Master 进程主要负责配置解析、工作进程（Worker）生命周期管理、信号处理和日志轮转等全局控制任务。它在启动初期（main() → ngx_init_cycle()）完成以下关键动作：

• 读取配置文件，构建内存中的配置树（ngx_conf_t）
• 调用所有已编译模块的 ngx_module_t.init_module 钩子（若有），进行全局初始化
• 为每个 Worker 进程预分配共享内存、监听套接字等资源
• 随后 fork 出 Worker 进程，自身进入事件循环等待信号

注意：模块的注册（通过 ngx_modules[] 数组）和核心结构（如 ngx_http_module_t）均在编译期固化，Master 不具备在运行时修改该数组或重新链接代码的能力。

为什么不能动态加载？根本约束在哪

这一限制源于 Nginx 的轻量级、高并发设计哲学和 C 语言运行时特性：

• 无符号/符号表依赖：Nginx 不保留模块导出符号的运行时索引，Worker 进程直接通过函数指针数组调用模块钩子（如 preconfiguration, postconfiguration），这些指针在编译链接时已确定
• 内存布局固化：配置结构体（如 ngx_http_core_main_conf_t）大小和字段偏移在编译时固定，动态插入模块会导致结构体不兼容
• 无模块生命周期管理框架：缺少类似 init/destroy、引用计数、依赖解析等基础设施，无法安全卸载或重载模块上下文
• Master 不执行请求处理：实际 HTTP/Stream 处理完全由 Worker 进程承担，而 Master 从不调用模块的 handler 或 filter 函数，仅协调配置与进程

替代方案：如何实现“类动态”模块能力

虽然不能真正动态加载，但可通过以下方式达成近似效果：

• 配置驱动开关：模块编译进 nginx 后，通过 nginx.conf 中的指令（如 limit_req, ssl_protocols）控制其启用/参数，无需重启即可生效（需 nginx -s reload）
• 多版本二进制切换：构建多个含不同模块集的 nginx 可执行文件（如 nginx-full, nginx-light），配合 systemd 或容器调度实现快速替换
• 第三方扩展尝试：极少数实验性项目（如 OpenResty 的 ngx_lua）通过嵌入 Lua 解释器，在运行时加载 Lua 脚本逻辑——但这仍是“脚本层动态”，底层 C 模块（如 lua-nginx-module）仍需静态编译
• 热升级（Binary Upgrade）：用新编译的 nginx 二进制替换旧版，通过 kill -USR2 触发平滑过渡，旧 Worker 处理完请求后退出，新 Worker 使用新二进制启动——这属于进程级更新，非模块级热插拔

reload 操作中 Master 对模块的实际影响

执行 nginx -s reload 时，Master 进程的行为是：

• 重新解析配置文件，生成新的 ngx_cycle_t
• 对每个已编译模块，调用其 create_main_conf, create_srv_conf 等钩子创建新配置实例
• 调用模块的 init_main_conf 和 init_worker（后者由 Worker 执行）完成重配置
• 向旧 Worker 发送 QUIT 信号，启动新 Worker

整个过程未新增或删除模块，只是复用原有模块代码，用新配置重建内部状态。因此，“模块是否启用”完全取决于配置指令是否存在，而非 Master 加载了新代码。