Nginx绝大多数第三方模块（如lua-nginx、echo、headers-more）必须静态编译，仅少数模块支持动态加载；静态集成需复用原configure参数、指定源码路径及--add-module，且须验证模块符号是否嵌入二进制。
静态编译第三方模块不是“避免动态加载失败”的补救手段，而是根本性选择——Nginx 本身不支持运行时插拔第三方模块，所谓“动态加载”仅对少数官方模块（如 image_filter、geoip）或明确适配了 --add-dynamic-module 的第三方模块有效。绝大多数第三方模块（比如 headers-more、lua-nginx、echo、njs 扩展等）必须静态集成，否则压根无法启用。
确认模块是否支持静态编译
不是所有第三方模块都默认支持静态链接。关键看两点：
- 模块根目录下必须存在可执行的
config脚本（由 Nginx 构建系统调用），且该脚本未强制要求动态模式； - 模块文档或 README 明确说明兼容当前 Nginx 版本（例如：支持 1.20–1.24，而你用的是 1.22.1）；
- 避免使用仅标注 “for dynamic module only” 或依赖
ngx_http_dyups_module等运行时机制的模块版本。
严格复用原 configure 参数 + 全量静态重编译
静态集成 ≠ 只加 --add-module。它要求整个 Nginx 二进制从头构建，且所有依赖（pcre、zlib、openssl）也需静态链接。操作要点：
- 执行
nginx -V获取完整 configure 命令，重点记录：nginx version（精确到 patch 版，如 1.22.1）、configure arguments（含 --with-http_ssl_module 等开关）； - 下载完全一致的 Nginx 源码包（不能是 1.22.2），并同步下载对应版本的 pcre、zlib、openssl 源码（如 pcre-8.45、zlib-1.3.2、openssl-3.2.1）；
- 将所有源码解压至同一父目录（如
/usr/src/build/），结构清晰便于引用； - 在 nginx 源码目录中执行 configure，保留全部原参数，并追加
--add-module=/usr/src/build/headers-more-nginx-module（绝对路径！）； - 显式指定静态链接选项：
--with-pcre=/usr/src/build/pcre-8.45 --with-zlib=/usr/src/build/zlib-1.3.2 --with-openssl=/usr/src/build/openssl-3.2.1； - 务必加上
--with-compat（即使静态编译也建议开启，为未来可能的模块升级留兼容余地）。
验证与上线前检查
编译完成后不能直接 make install 覆盖线上环境：
- 先用
make生成 objs/nginx，不执行make install； - 备份原二进制：
cp /usr/sbin/nginx /usr/sbin/nginx.bak； - 仅替换二进制：
cp objs/nginx /usr/sbin/nginx； - 运行
nginx -V，输出中应出现你添加的模块名（如--add-module=.../headers-more-nginx-module）； - 执行
nginx -t确保配置无语法错误； - 用
strings /usr/sbin/nginx | grep -i "module_name"检查模块符号是否真实嵌入二进制（尤其防 config 脚本静默失效）。
为什么不用动态模块方式？
动态模块看似方便，但实际限制多：
- 模块作者需主动适配动态加载接口（很多老模块没更新）；
- 即便支持，仍需用
--add-dynamic-module编译，再make modules单独生成 .so，步骤不比静态少； - so 文件依赖运行时环境（glibc、openssl 版本），跨机器迁移极易报错；
- 生产环境若追求确定性与最小依赖，静态二进制反而更可靠——一个文件，无共享库冲突，启动即生效。
