load_module必须置于main context（nginx.conf开头、events前），版本需≥1.9.11且编译启用dynamic支持，路径须绝对、权限可读、ABI严格匹配，否则加载失败或运行时崩溃。
必须把 load_module 放在全局块（main context），写在 http 或 server 里直接报错，且无法启动。
确认 Nginx 版本和动态模块支持
低于 1.9.11 的 Nginx 不支持 load_module，强行使用会提示 unknown directive "load_module"。执行以下命令验证：
nginx -v nginx -V 2>&1 | grep -o 'dynamic'
输出含 dynamic 才表示编译时启用了动态模块支持；同时注意 --modules-path 路径（如 /usr/lib/nginx/modules），这是模块文件的标准存放位置。
- 若
nginx -v显示版本低于 1.9.11，只能重新编译或升级 Nginx -
nginx -V输出中没出现dynamic，说明当前二进制不支持动态加载，即使版本够也不行 - YUM/Apt 安装的官方包通常已启用
dynamic，但第三方源（如 OpenResty）需单独确认
load_module 必须写在配置文件最顶层
该指令只允许出现在 main context —— 即 nginx.conf 文件开头、events 块之前的位置。任何嵌套写法都会导致语法错误：
- ❌ 错误：写在
http { }内部 → 报错"load_module" directive is not allowed here - ❌ 错误：用相对路径但没注意
nginx.conf当前目录 → 模块加载失败，nginx -t提示module not found - ✅ 正确写法（推荐绝对路径，避免歧义）：
load_module /usr/lib/nginx/modules/ngx_http_echo_module.so; - ✅ 同一配置中可多行
load_module，每行一个模块
模块文件路径、权限与 ABI 兼容性
模块加载失败最常见的三个原因不是配置写错，而是文件本身不匹配：
- 模块
.so文件必须和当前 Nginx 主版本、GCC 版本、OpenSSL 版本、PCRE 版本完全一致，否则nginx -t可能静默失败或运行时报undefined symbol - 文件权限需为可读（如
chmod 644 /usr/lib/nginx/modules/xxx.so），Nginx worker 进程无权读取则加载失败 - 模块路径建议统一用绝对路径；若用相对路径（如
modules/xxx.so），它相对于的是nginx.conf所在目录，不是 Nginx 二进制所在目录 - 常见陷阱：从别的机器拷贝
.so文件过来，看似版本一样，但构建环境不同（例如 glibc 版本差异）也会导致运行时崩溃
验证模块是否真正生效
Nginx 不提供 nginx -V 或 nginx -t 直接列出已加载模块的功能，得靠“间接证据”确认：
- 先运行
nginx -t，通过代表load_module语法和路径无硬错误 - 再执行
nginx -s reload，成功说明模块被识别且未触发 ABI 冲突 - 最后检查模块特有指令是否可用：比如加了
ngx_http_geoip2_module，就在http块里写一行geoip2 /path/to/GeoLite2-City.mmdb;，再nginx -t；如果报unknown directive "geoip2"，说明模块根本没加载上 - 注意：有些模块（如
ngx_http_stub_status_module）是静态内置的，不支持动态加载，别白费劲找.so文件
真正容易被忽略的点是 ABI 兼容性 —— 它不像语法错误那样立刻暴露，而是在某个请求触发模块逻辑时才 crash，日志里只显示 worker process exit，查起来非常隐蔽。
