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 加载了新代码。
