答案是磁盘空间充足但无法写入文件的根本原因是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 存了海量小对象、或被攻击生成大量空日志文件。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1),免gas,支持macOS/Linux/Windows。触发词:/r
- 执行
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 绑定路径是否映射到高负载分区

















