Nginx缓存静态文件的核心目标是让.js、.css、.png等资源由Nginx直接读取磁盘返回，彻底避免回源；必须用root/alias替代proxy_pass，配合sendfile实现零拷贝直出，并通过X-Cache-Status响应头验证HIT状态。
静态资源压根不该回源——Nginx 缓存静态文件的核心目标，是让 .js、.css、.png 这类内容完全由 Nginx 自己读取磁盘返回，不发请求给后端。所谓“减少回源压力”，本质是先杜绝误配导致的非必要回源，再用缓存策略加固容错。
静态资源必须绕过 proxy_pass
很多回源压力来自配置错误：把本该本地服务的静态文件，用 proxy_pass 转发给了后端。这类 location 块是典型问题源：
-
location ~* \.(js|css|gif|png)$ { proxy_pass http://backend; }→ 必须删除或重写 - 正确做法是用
root或alias指向静态目录，并启用sendfile - 确保路径不落入任何含
proxy_pass的 location 范围，可单独设location /static/ { root /data/www; } - 用
curl -I https://yoursite.com/style.css查响应头：Server: nginx且无X-Powered-By或X-Upstream才算真正直出
缓存策略只对代理型静态请求有意义
只有当静态资源确实需要走后端（比如带权限校验的图片、动态生成的 JS）时，才需启用 proxy_cache。此时关键配置包括：
-
proxy_cache my_cache;和proxy_cache_valid 200 24h;—— 给成功响应设长有效期 -
proxy_cache_key "$scheme$host$request_uri";—— 剔除$args、$cookie等干扰项，避免缓存碎片 -
proxy_ignore_headers Cache-Control Expires Set-Cookie;—— 防止后端响应头覆盖你的缓存策略 -
add_header X-Cache-Status $upstream_cache_status;—— 通过响应头实时观察命中状态
高并发下防穿透的关键不是 cache_lock，而是别让它触发
proxy_cache_lock on 只在缓存未命中时起作用，而静态资源本不该有“未命中”——它要么存在磁盘上直接返回，要么 404。所以：
- 若你发现大量
MISS，说明文件路径不对、权限不足，或 location 匹配逻辑有漏洞 - 对真需代理的静态场景（如鉴权资源），
proxy_cache_lock可限制并发回源数，但必须搭配proxy_cache_use_stale error timeout updating; - 更稳妥的做法是配合
proxy_cache_background_update on;，让首个请求更新缓存，其余继续用旧内容
验证是否真正生效的三步法
别只看配置写了没，要从响应和日志里找证据：
- 检查响应头中
X-Cache-Status：出现HIT表示缓存已生效；MISS且后端日志有记录，说明仍回源 - 确认缓存目录
/var/cache/nginx下有对应文件生成，且keys_zone内存区有 key 计数增长 - 用
nginx -t校验语法，重启后用tail -f /var/log/nginx/access.log观察请求是否还打到 upstream IP
