nginx缓存层可提升响应速度、降低后端压力、节省带宽，适用于静态资源及带版本号的api响应，禁用于含用户身份、强一致性要求或no-store头的场景；需配置proxy_cache_path、proxy_cache、proxy_cache_valid三要素，并优化cache_key、bypass逻辑与状态头；运维上依赖purge模块、定时清理及hit率监控。
在流量入口处部署 Nginx 缓存层，是提升响应速度、降低后端压力、节省带宽成本的高效手段。它不依赖应用逻辑改动，也不增加服务复杂度，只要配置得当，就能让静态资源毫秒返回，动态内容按需复用。
明确缓存目标与适用边界
缓存不是万能解药，关键先厘清“什么该缓、什么不该缓”。适合缓存的内容包括：
- CSS、JS、图片、字体等静态文件（变动少、复用高）
- 状态码为 200/304 的 API 响应（如配置信息、商品基础数据）
- 带版本号或哈希值的资源路径（如
/app.a1b2c3.js），天然支持长期缓存
以下情况需谨慎或禁用缓存：
- 含用户身份、会话、实时时间戳的接口（如
/api/user/profile?ts=1749114780） - 支付、下单、库存扣减等强一致性要求的操作
- 响应头中已含
Cache-Control: no-store或Pragma: no-cache
核心配置三要素：路径、区域、策略
Nginx 缓存生效依赖三个基础指令协同工作，缺一不可：
-
proxy_cache_path：定义物理缓存位置和管理规则
例如：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:20m max_size=2g inactive=30m use_temp_path=off;
其中keys_zone是内存索引区名称，必须与后续引用一致；use_temp_path=off可避免写入临时文件带来的性能抖动 -
proxy_cache：在 location 或 server 块中启用指定缓存区
例如：proxy_cache my_cache; -
proxy_cache_valid：按响应状态码设定缓存有效期
例如：proxy_cache_valid 200 304 12h; proxy_cache_valid 404 1m;
建议对 5xx 错误也设短缓存（如proxy_cache_valid 500 502 503 504 30s;），防止雪崩式重试打垮后端
提升命中率的关键细节
缓存配置写完不等于就能命中，常见失效原因多源于默认行为未显式覆盖：
-
缓存键要稳定：默认
$scheme$proxy_host$request_uri会把请求头、参数顺序、大小写差异都纳入 key。若后端忽略大小写或允许乱序参数，建议自定义：proxy_cache_key "$host$request_uri"; -
跳过不缓存的请求：用
proxy_cache_bypass和proxy_no_cache控制绕过逻辑
例如：proxy_no_cache $arg_nocache $cookie_dev_mode;，当 URL 带?nocache=1或用户登录态为开发模式时，直接穿透 -
暴露缓存状态便于排查：添加响应头
add_header X-Cache-Status $upstream_cache_status;
返回值为HIT、MISS、BYPASS、EXPIRED等，可快速定位是否真在缓存
运维友好性：清理与监控
生产环境需要可控的缓存生命周期管理：
-
主动清理单个资源：Nginx 本身不提供 REST 接口，但可通过
proxy_cache_purge模块（需编译时启用）配合正则匹配清除，例如：location ~ /purge(/.*) { allow 127.0.0.1; deny all; proxy_cache_purge my_cache "$host$1"; } -
批量清理旧缓存：使用系统命令定期清理过期文件，如
find /var/cache/nginx -type f -mmin +30 -delete（配合inactive时间） -
监控缓存效率：通过日志字段
$upstream_cache_status统计 HIT 率，结合 Prometheus + nginx-vts-exporter 可实现可视化看板
