源码安装Nginx时空间不足或权限异常源于环境准备偏差，非编译本身失败：需预留≥500MB磁盘空间（尤其/tmp和源码分区），确保源码目录、--prefix路径及依赖库路径对当前用户可读写，全程普通用户操作仅make install加sudo，并验证sbin/nginx执行权、配置文件与日志目录权限闭环。
源码安装 Nginx 时遇到空间不足或权限异常，不是编译失败本身导致的，而是环境准备和操作路径出了偏差。问题往往在 configure 阶段就埋下伏笔，到 make 或 make install 时才集中爆发。
检查并释放足够磁盘空间
configure 和 make 过程会生成大量中间文件（如 objs/ 目录），尤其启用 SSL、HTTP/2 等模块后，临时对象体积明显增大。建议预留至少 500MB 可用空间：
- 用 df -h 查看 /tmp（configure 默认缓存目录）和源码所在分区的剩余空间
- 若 /tmp 满了，可指定临时目录：在 configure 前执行 export TMPDIR=/path/to/larger/dir
- make 完成后及时清理：进入源码目录运行 make clean，删掉 objs/ 和 .o 文件
确保编译用户对所有相关路径有完整权限
权限问题常出现在三类路径上：源码目录、安装目标目录（--prefix）、以及 configure 依赖库路径（如 --with-openssl=）。任意一处不可写或不可读，都会中断流程：
- 源码目录需保证当前用户有 rwx 权限（特别是解压后未改属主时，常见于 sudo wget + 普通用户编译）
- --prefix 指定的安装路径（如 /usr/local/nginx）必须存在且当前用户可写；若不存在，先 sudo mkdir -p /usr/local/nginx && sudo chown $USER:$USER /usr/local/nginx
- 若引用了自建 OpenSSL 或 PCRE（如 --with-openssl=/opt/openssl），确认该路径下 include/ 和 lib/ 对当前用户可读
规避 root 权限误用带来的权限残留
用 sudo 执行 configure 或 make 是危险操作——它会让生成的 Makefile、objs/nginx 等文件属主变为 root，后续普通用户无法修改或安装，还容易引发 make install 后二进制无执行权限（因 cp 替代 install）：
- 全程使用普通用户操作，仅在 make install 阶段加 sudo（前提是 --prefix 目录已授权）
- 若已误用 sudo 编译，不要直接 chmod 修复 objs/nginx，而应 make clean 后切换回普通用户重做
- 更稳妥做法：configure 后检查 Makefile 中 install 目标是否调用 install -m 0755；若只是 cp，则手动用 install 命令覆盖安装
验证关键路径权限链是否闭环
编译成功不等于能运行。安装完成后立即检查权限闭环，避免启动时报 “Permission denied”：
- 确认 /usr/local/nginx/sbin/nginx 有 x 权限（ls -l 看是否有 x）
- 确认 nginx.conf 中 user 指令指定的用户（如 www-data）真实存在，且对该配置文件、logs/、client_body_temp/ 等路径有读写权
- 若用 systemd 管理，运行 systemctl status nginx，错误信息比手动执行更早暴露权限断裂点
