答案是磁盘空间充足但无法写入文件的根本原因是inode耗尽，需用df -i检查iuse%是否达100%，再定位/var/log/nginx等高inode占用目录并清理小文件。
排查 Nginx 故障时，磁盘空间（disk space）和 inode 耗尽是常见却容易被忽视的原因——Nginx 日志写不进磁盘、无法创建临时文件、甚至 worker 进程静默退出，都可能源于此。`df -h` 和 `df -i` 是最轻量、最直接的初筛工具，不需要安装额外软件，也不依赖 Nginx 自身状态。
用 df -h 快速识别磁盘容量瓶颈
Nginx 依赖磁盘写入 access log、error log、client body 临时文件（如上传大文件）、proxy cache 等。一旦挂载点满（尤其是 /var/log、/var/cache/nginx 或根分区），Nginx 会拒绝写日志、返回 500/502，或丢弃请求而不报错。
- 运行
df -h，重点关注 Use% 列超过 85% 的挂载点 - 特别检查 Nginx 配置中涉及的路径：比如
access_log /var/log/nginx/access.log所在分区，或proxy_cache_path /data/nginx/cache对应的挂载点 - 若
/var或/使用率 100%，即使nginx -t通过、进程存活，也可能已无法接受新连接
用 df -i 发现“空间有余但服务异常”的隐形问题
磁盘块还有剩余，但 inode 耗尽时，Nginx 会报 open() "/var/log/nginx/access.log" failed (24: Too many open files) 或更隐蔽的 Permission denied（实际是无法新建 inode）。这常发生在大量小文件场景：如开启日志分割但未清理、proxy cache 存了海量小对象、或被攻击生成大量空日志文件。
- 执行
df -i，关注 IUse% 列 —— 即使df -h显示 20% 使用率，IUse%达 99% 同样致命 - 常见高 inode 消耗目录：
/var/log/nginx/（尤其按天切分但未轮转）、/var/cache/nginx/（proxy_cache 或 fastcgi_cache）、/tmp/（如果 Nginx 临时文件指向此处） - 确认后可用
find /var/log/nginx -type f | wc -l或ls -i /var/log/nginx | head辅助判断文件数量级
定位后快速缓解的实操建议
发现异常后，不要直接删文件，先确认影响范围：
- 查 Nginx 日志路径：
nginx -V 2>&1 | grep conf→ 查nginx.conf中access_log和error_log设置 - 清理前备份关键日志：
gzip /var/log/nginx/access.log.1，再truncate -s 0 /var/log/nginx/access.log（清空而非删除，避免中断写入） - 释放 inode：优先删空文件（
find /var/log/nginx -size 0 -delete）、过期缓存（rm -rf /var/cache/nginx/proxy/*，需先nginx -s stop或确保 cache 已停用） - 长期预防：配置 logrotate（含
create和rotate）、限制 proxy_cache_max_size、关闭不必要的日志记录（如健康检查接口）
结合 Nginx 状态交叉验证
df 结果只是起点，需与 Nginx 行为关联：
- 若
df -h显示/var98%，且tail -n 10 /var/log/nginx/error.log出现No space left on device，基本可锁定 - 若
df -i显示/varIUse% 100%，而ps aux | grep nginx显示 worker 进程频繁重启，或ss -tnlp | grep :80端口监听不稳定，也高度可疑 - 注意：Docker 环境下，
df显示的是宿主机挂载点，需确认容器 volume 绑定路径是否映射到高负载分区
