排查Nginx load_module路径权限故障，核心是确认模块文件及其所有父目录对Nginx主进程（root）和worker进程（如www-data）均具备可读、可执行权限，且SELinux/AppArmor未拦截，strace可精确定位失败环节。
排查 Nginx load_module 路径权限故障，核心是确认模块文件是否可被 Nginx 主进程（通常以 root 启动）和工作进程（通常降权为 www-data 或 nginx 用户）同时访问。常见问题不是“找不到文件”，而是“找到了却打不开”。
检查模块文件的绝对路径与存在性
确保 load_module 指令中写的路径是绝对路径（相对路径行为不可靠，且从 Nginx 1.9.11+ 开始已被弃用）。用 ls -l 验证文件是否存在、是否为普通文件（非目录/符号链接循环）：
- 运行
nginx -t，它会报错如module "/path/to/ngx_http_geoip2_module.so" is not found—— 这说明路径错误或文件缺失 - 若报
module ... failed to load: ... Permission denied，则进入下一步权限排查 - 注意：Nginx 不会自动在
$PATH或模块目录中搜索，路径必须精确指定
验证文件所有者与执行权限
Nginx 加载模块本质是 dlopen()，要求模块文件对运行 Nginx 的用户（主进程 uid）**可读 + 可执行**（Linux 下 shared object 文件需有 x 权限才可 mmap 加载）：
- 运行
ls -l /path/to/module.so，确认权限至少为-r-xr-xr-x（即 755）或更宽松；644会导致Permission denied - 检查该文件所在**每一级父目录**是否对 Nginx 用户（如
www-data）有x权限（目录需有x才能进入和访问子项） - 例如：
/opt/nginx/modules/ngx_http_geoip2_module.so，则/opt、/opt/nginx、/opt/nginx/modules都必须对 Nginx 用户有x权限
确认 SELinux 或 AppArmor 是否拦截
在 CentOS/RHEL（启用 SELinux）或 Ubuntu（启用 AppArmor）上，安全模块可能阻止 Nginx 加载非标准路径下的模块：
- 临时禁用 SELinux 测试：
sudo setenforce 0，再运行nginx -t；若成功，说明 SELinux 策略限制 - 查看拒绝日志：
sudo ausearch -m avc -ts recent | grep nginx（SELinux）或sudo dmesg | grep -i avc - 常见修复：用
semanage fcontext添加模块路径上下文（如httpd_modules_t），再restorecon；AppArmor 则需更新 profile，添加/path/to/*.so mr,
用 strace 追踪系统调用定位真实失败点
当常规检查无果时，用 strace 直接观察 Nginx 尝试加载模块时的系统调用：
- 停止 Nginx：
sudo nginx -s stop - 运行：
sudo strace -e trace=openat,open,stat,fstat,dlopen -f nginx -t 2>&1 | grep -E "(module|denied|No such)" - 重点关注输出中类似
openat(AT_FDCWD, "/path/to/module.so", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)的行，它明确告诉你哪一步因何失败 - 注意：
-f参数用于跟踪 fork 出的子进程（如主进程加载模块时的行为）
