磁盘空间不足不会让 Nginx 立即崩溃，但会导致 master 进程存活而 worker 无法写日志、建临时文件或缓存，表现为服务无响应、502/504、上传失败或超时；需用 df -h、lsof +L1、ps aux 等主动验证磁盘与进程状态，并通过清空日志、USR1 重载、logrotate 和分离缓存目录防复发。
磁盘空间不足不会让 Nginx 立即崩溃，但会让它“卡住”——master 进程还在，worker 却无法写日志、无法建临时文件、无法缓存，最终表现为服务无响应、502/504、上传失败或请求超时。排查关键不是等报错，而是主动验证磁盘与进程状态。
快速确认磁盘是否已满
别只看 error.log 有没有报错，先查底层空间：
- 运行 df -h，重点检查 /var/log、/var/cache/nginx、/tmp 所在分区是否 ≥95%；
- 用 ls -lSh /var/log/nginx/ 查 access.log 和 error.log 大小，单个超 1GB 就高度可疑；
- 执行 df -i 看 inode 是否耗尽（尤其小文件多的场景），满也会导致“磁盘满”行为；
- 若发现某分区显示 100% 但实际文件加起来远没那么多，可能是坏块或只读挂载，需进一步验证。
检查 Nginx 是否因磁盘问题卡住
日志写不进、临时文件建不了，worker 进程会静默失效：
- 运行 ps aux | grep nginx：如果只有 master 进程，没有 worker，或 worker 状态为 Z（僵尸） 或 CPU 长期为 0，基本锁定；
- 执行 lsof +L1 | grep nginx：若有输出且含 deleted 字样（如 /var/log/nginx/error.log (deleted)），说明日志被删过但进程还占着句柄，磁盘虽空却无法释放；
- 用 tail -f /var/log/nginx/error.log：如果日志完全不动，新请求也不触发写入，大概率是写入路径不可用。
从错误日志里找间接线索
error.log 本身可能不直接写“磁盘满了”，但会出现典型降级痕迹：
- 高频出现 open() "/var/log/nginx/access.log" failed (28: No space left on device) —— 明确指向磁盘满；
- 大量 mkdir() "/var/cache/nginx/proxy/..." failed (28: No space left on device) —— 缓存目录写入失败；
- 反复报 connect() failed (111: Connection refused) while connecting to upstream，但后端实际正常 → 很可能是 worker 因磁盘问题退出，只剩 master 在监听却无人处理；
- 出现 recv() failed (104: Connection reset by peer) 或 upstream timed out，且伴随 worker 异常退出，也需结合磁盘状态交叉判断。
应急恢复与防复发要点
定位后要快速恢复，并堵住漏洞：
- 清空间别直接 rm 日志，用 echo "" > /var/log/nginx/access.log 清空内容，保留文件句柄；
- 若已误删且 lsof 显示 deleted，先 kill -USR1 $(cat /var/run/nginx.pid) 让 Nginx 重新打开日志文件；
- 配置中关闭非必要日志：access_log off; 在非核心 location，error_log ... warn; 降低日志级别；
- 必须启用 logrotate：配 daily、rotate 7、compress、notifempty，避免人工遗漏；
- 给缓存和临时目录单独挂载小容量磁盘，或限制 max_size 和 inactive，防止缓存无限膨胀。
