Nginx因缓存目录磁盘损坏导致拒绝服务时，应快速定位缓存路径、验证磁盘健康状态、检查缓存写入是否受阻；需确认proxy_cache_path实际生效路径及use_temp_path设置，用df、mount、dmesg和文件操作验证磁盘状态，并通过error.log、ps、lsof观察worker行为，最后停用缓存或迁移路径应急。
当 Nginx 因缓存目录所在磁盘损坏而出现拒绝服务（如 502、503、上游超时、worker 进程异常退出等），核心思路是：**快速定位缓存路径 → 验证磁盘健康状态 → 检查 Nginx 缓存写入行为是否受阻**。不依赖日志关键词盲猜，而是从系统层和 Nginx 运行态双向验证。
确认 Nginx 缓存配置的实际路径
Nginx 缓存路径由 proxy_cache_path（或 fastcgi_cache_path 等）指令定义，但实际生效路径可能与配置有偏差：
- 检查主配置文件（通常
/etc/nginx/nginx.conf）及包含的子配置，找到类似proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=1g inactive=60m use_temp_path=off;的行 - 注意
use_temp_path=off是关键——它表示缓存文件直接写入proxy_cache_path指定目录；若为on（默认），则先写临时目录（通常是proxy_temp_path，未显式配置时为prefix/temp，即/var/cache/nginx/temp），再原子重命名。此时磁盘问题可能首先暴露在temp目录 - 用
nginx -T | grep proxy_cache_path输出全部生效配置，避免遗漏 include 或环境差异
检查缓存目录所在文件系统的状态
磁盘损坏常表现为 I/O 错误、只读挂载、inode 耗尽或硬件级响应超时：
- 运行
df -h /var/cache/nginx（或对应路径），观察使用率是否异常突增至 100% —— 可能是坏块导致空间统计错误或无法释放 inode - 执行
mount | grep "$(df /var/cache/nginx | tail -1 | awk '{print $1}')"，确认该分区是否被内核强制 remount 为ro（只读）。常见于 ext4 发现严重错误后的保护机制 - 用
dmesg -T | grep -i "ext4\|ata\|nvme\|error\|cache"查看内核日志，寻找end_request: I/O error、Buffer I/O error、journal has failed等磁盘底层报错 - 尝试手动创建/删除测试文件：
touch /var/cache/nginx/test.$$ && rm /var/cache/nginx/test.$$。失败且报Read-only file system或Input/output error即可锁定磁盘问题
观察 Nginx worker 进程的实时行为
缓存写入失败时，Nginx 不会直接崩溃，但会降级处理并留下痕迹：
- 检查错误日志高频条目：
tail -f /var/log/nginx/error.log | grep -E "(cache|open|write|No space|Read-only|I/O error)"。重点关注open() "/var/cache/nginx/..." failed (5: Input/output error)或(30: Read-only file system) - 用
ps aux | grep nginx观察 worker 进程是否频繁重启（PPID 变化快）、CPU 占用异常高（卡在 I/O 等待）或状态为D（不可中断睡眠，常因磁盘无响应） - 运行
lsof +D /var/cache/nginx查看哪些进程正占用缓存目录下的文件。若大量DEL状态文件或句柄无法释放，说明清理逻辑被阻塞 - 临时启用更详细日志：
error_log /var/log/nginx/debug.log debug_http;（需编译含 debug 日志支持），可捕获 cache manager 模块的cache manager和cache loader异常调度信息
快速隔离与应急恢复
确认磁盘损坏后，避免进一步写入加剧故障：
- 立即停用缓存：在对应 server 或 location 块中临时注释或设为
proxy_cache off;，然后nginx -s reload。这能立刻缓解上游压力，但会失去缓存收益 - 若必须保留缓存，可将
proxy_cache_path改为另一健康磁盘路径（如/mnt/ssd/nginx_cache），确保新路径已格式化、挂载且 Nginx 用户有读写权限 - 不要依赖
nginx -t测试——它只校验语法，不检测磁盘可用性。真正有效的是nginx -s reload后观察 worker 是否稳定存活 - 底层修复需联系运维：对 ext4 分区运行
e2fsck -f /dev/sdXN（需卸载），SSD 则检查 SMART 信息（smartctl -a /dev/sdX），坏块严重时应更换物理设备
不复杂但容易忽略：很多故障看似是 Nginx 配置或上游问题，实则是缓存目录所在的那块硬盘悄悄哑了。每次排查缓存相关故障，先看磁盘，再看日志，最后看配置。
