磁盘空间或Inode耗尽会导致Nginx access_log静默停止写入，需用df -h和df -i分别检查块空间与Inode使用率，紧急时truncate清空当前日志并发送USR1信号恢复写入，再补全logrotate配置及磁盘监控。
磁盘空间满会导致 Nginx access_log 完全停止写入，而这种静默失效往往成为 502 Bad Gateway 的真实诱因——不是上游挂了，而是节点底层已“窒息”。排查关键不在于日志里有没有报错，而在于确认日志是否还在被写、为什么停了。
先验证 access_log 是否真在写、写到哪了
别默认看 /var/log/nginx/access.log。打开 nginx.conf，找到 access_log 指令，确认实际路径（比如 /data/logs/nginx/access.log）。常见问题包括：
- 路径不存在：/data/logs/nginx 目录未创建，Nginx 启动时无法初始化日志模块，后续所有请求都不会落日志
- 权限不对：Nginx worker 进程用户（如 www-data 或 nginx）对父目录缺少 x（执行/进入）权限，导致无法进入多级路径
- 用 ps aux | grep nginx 查 worker 进程属主，再用 ls -ld /data/logs/nginx 确认该用户有写和进入权限
立刻检查磁盘块和 Inode 是否耗尽
两者都会让 access_log 写入失败，但表现不同：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- df -h：重点看 access_log 所在分区的 Use% 是否为 100%、Avail 是否为 0
- df -i：若 IUse% 达到 100%，说明无法新建文件——logrotate 生成大量 .log.1、.log.2.gz 后未清理是典型场景
- 查已删除但句柄仍占空间的日志：lsof +L1 | grep nginx，若有 deleted 字样，说明日志文件被 rm 但进程还在写，空间未释放
绕过日志本身，抓系统层写入失败信号
当 access_log 文件空且无新增内容时，error.log 也可能静默——这时要直接看系统反馈：
- 用 nginx -c /etc/nginx/nginx.conf -e stderr 启动测试，捕获早期错误（如路径不可写、open 失败）
- 跟踪 worker 进程写操作：strace -p $(pgrep -f "nginx: worker") -e trace=write,openat -s 256 2>&1 | grep log，看到 write(...) = -1 ENOSPC 就是磁盘满的铁证
- 检查 SELinux/AppArmor 干预：ausearch -m avc -ts recent | grep nginx（CentOS/RHEL）或 aa-status | grep nginx（Ubuntu）
恢复写入并防止复发
释放空间只是第一步，必须让 Nginx 重新获得写能力：
- 清空当前日志内容（保留句柄）：truncate -s 0 /var/log/nginx/access.log
- 删掉过期轮转日志：rm -f /var/log/nginx/access.log-2025*.gz
- 发 USR1 信号重建日志：kill -USR1 $(cat /var/run/nginx.pid)
- 立即验证：tail -f /var/log/nginx/access.log 看是否有新请求实时写入
- 补 logrotate 配置：确保 /etc/logrotate.d/nginx 含 daily、rotate 30、compress、postrotate kill -USR1，并手动跑一次 logrotate -f /etc/logrotate.d/nginx
