proxy_cache不适合纯静态资源，因其冗余磁盘IO、浪费内存、绕过sendfile；应改用open_file_cache+浏览器强缓存+CDN三级协同。
proxy_cache 在高并发静态资源场景下不是首选方案，它本质是为反向代理动态内容设计的，用在纯静态资源服务上反而增加开销、降低性能。真正高效的做法是：静态资源走 本地磁盘直读 + open_file_cache，缓存逻辑交给浏览器和 CDN；只有必须经由上游（比如带鉴权、A/B测试、灰度路由）的静态资源，才启用 proxy_cache，并需严格调优。
为什么 proxy_cache 不适合纯静态资源
proxy_cache 会把响应体写入磁盘缓存区，再读出返回——对本就存在本地磁盘的静态文件来说，这是冗余的“读磁盘→写缓存→再读缓存→发网络”链路。它带来三重损耗：
- CPU 和 I/O 开销：多一次文件落盘与读取，尤其小文件高频访问时，磁盘随机 IO 成瓶颈
- 内存浪费：keys_zone 占用固定内存，但静态资源元信息更适合用 open_file_cache 管理
- 路径绕远：绕过 sendfile 零拷贝机制，无法利用内核页缓存直送 socket
proxy_cache 启用前提与精简配置
仅当静态资源需经上游处理（如防盗链校验、URL 重写、Header 注入、后端动态拼接）时，才保留 proxy_cache。此时必须做到三点：
- 关闭所有 proxy_buffer 相关指令：静态响应无需缓冲，删掉 proxy_buffering、proxy_buffers、proxy_buffer_size
-
缓存键只含必要字段：避免携带 Cookie、Authorization 等导致缓存碎片化，例如：
proxy_cache_key "$host$uri$is_args$args"; -
按状态码分级缓存时效：200/304 长期缓存，404 短期缓存防穿透
proxy_cache_valid 200 304 12h;
proxy_cache_valid 404 1m;
替代方案：open_file_cache + 浏览器强缓存
对标准静态资源服务（即 location 中用 root/alias 直接映射磁盘路径），应禁用 proxy_pass，改用：
-
open_file_cache：缓存文件句柄、大小、修改时间等元数据，大幅减少 stat()/open() 系统调用
open_file_cache max=10000 inactive=60s valid=60s min_uses=2 errors on; -
expires + immutable：让浏览器彻底跳过验证请求
location ~* \.(js|css|png|jpg|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable, max-age=31536000";
} - sendfile on + tcp_nopush：启用内核零拷贝，合并 TCP 包，降低中断频率
高并发下缓存协同策略
真正的高并发静态加速是三级缓存协同，而非只靠 Nginx 一级：
- 浏览器层：immutable 头确保长期缓存不发条件请求
- Nginx 层：open_file_cache 加速文件元数据访问，非 proxy_cache
- CDN 层：承担 80%+ 地域流量，源站只处理回源请求；CDN 缓存策略设为 “忽略 Query String” + “强制缓存 30d”，源站响应头同步透传 Cache-Control
