Nginx日志写满磁盘导致站点不可用的根因是stream模块自循环配置引发日志指数增长，且删除日志文件不释放空间因进程持有句柄；需检查配置、清空内容后reload，并通过logrotate、水位告警和权限收敛建立防护机制。
一次 Nginx 日志写满磁盘、IO 持续拉高，最终导致站点完全不可用——这不是理论推演，而是真实发生的线上事故。问题表象是“打不开网站”，但根因藏在日志配置与系统资源协同管理的缝隙里。
日志疯长：不是写得太多，而是写得太“死”
常见但危险的配置陷阱：Nginx 启用了 TCP 代理（如 stream 模块监听 20131 端口），却把 proxy_pass 指向本机同一地址和端口，形成自循环请求流。每条请求都被记录进 access_log，而日志本身又触发新请求……指数级放大，短短一天生成 530GB 日志文件。
这类问题不会立刻暴露，往往在部署后 24 小时内爆发，且错误日志里几乎不报错——因为 Nginx 自己运行正常，只是在疯狂落盘。
建议你检查：
- nginx.conf 中是否误配了 stream 块，且 proxy_pass 指向自身
- 所有 access_log 指令是否都明确指向了真实业务流量，而非探测/心跳/内部调用
- 是否存在未注释掉的调试日志配置（如 error_log debug）
删日志≠释放空间：Linux 文件句柄的隐藏逻辑
磁盘显示 100% 使用率后，直接 rm -f tcp.access-log 不仅无效，还可能引发系统崩溃。原因在于：Nginx worker 进程仍持有该文件的打开句柄（file descriptor），删除操作只是移除了目录项，实际磁盘空间并未回收。
此时执行 df -h 仍显示满，du -sh /var/log/nginx 却看不到大文件——这是典型“已删除但未释放”现象。
正确做法是：
- 先确认残留句柄：lsof +L1 | grep nginx，找出被删除但仍被占用的日志文件
- 安全清空内容：echo "" > /var/log/nginx/tcp.access-log（保持句柄，释放磁盘）
- 再执行 nginx -s reload，让 worker 进程重新打开日志文件（旧句柄自动关闭）
防患于未然：三道日志防护线
单靠人工巡检无法应对高并发场景下的日志风险，必须建立自动化防护机制：
- 日志轮转（logrotate）强制启用：配置按天切割 + 压缩 + 保留 7 天，避免单文件无限增长
- 磁盘水位告警前置：在使用率达 85% 时触发企业微信/钉钉告警，而非等到 100%
- 关键路径权限收敛：禁用 root 直接写入日志目录；Nginx worker 以专用用户（如 www-data）运行，并限制其对日志目录的写入配额（via systemd 的 LimitNOFILE 和 MemoryMax）
运维不是兜底，而是把“可能出错”的环节提前卡住。一次 IO 打满的崩溃，本质是日志策略、进程模型和系统限制三者没对齐。补上这一课，比多写十个接口更实在。
