最直接有效的方式是在location或server块中为各状态码组单独配置proxy_cache_valid，如200/206/304缓存10m、301缓存7d、302缓存2m、404缓存30s、5xx缓存10s、any兜底5s；必须同时满足proxy_cache_path定义缓存区、proxy_cache启用缓存、上游响应允许缓存三项前提。
最直接有效的方式，是在 Nginx 的 location 或 server 块中，为每个关键状态码或语义相近的状态码组，单独写一行 proxy_cache_valid 指令。Nginx 会按状态码精确匹配，显式声明的规则优先于 any，后出现的同状态码配置还会覆盖前面的——所以顺序和写法必须清晰。
按业务含义分组设置合理时长
不同状态码代表不同响应性质，缓存时间应匹配其稳定性与敏感性：
-
200 / 301 / 302 / 206 / 304：正常响应、永久/临时重定向、范围请求、协商成功。内容通常稳定，适合中长期缓存，例如：
proxy_cache_valid 200 206 304 10m; -
301：语义为永久重定向，可独立设更长周期，如：
proxy_cache_valid 301 7d;（注意不能和 302 合并在同一行） -
302：临时跳转，必须设短，避免用户错过上游变更，例如：
proxy_cache_valid 302 2m; -
404：资源不存在，缓存过长会导致“假 404”，掩盖新上线路径；建议控制在
30s～1m，例如：proxy_cache_valid 404 30s; -
5xx 类错误（500/502/503/504）：后端临时故障，短时缓存能缓解雪崩，推荐
5s～30s，例如：proxy_cache_valid 500 502 503 504 10s; -
兜底 any：覆盖未显式声明的状态码（如 403、410、429），但不会覆盖已定义的，例如：
proxy_cache_valid any 5s;
确保缓存真正生效的三个硬性前提
proxy_cache_valid 只管“缓存多久”，不管“是否缓存”。以下三项必须同时满足，否则所有规则都无效：
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- 在
http块中定义缓存区：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g; - 在当前
location中启用该缓存区：proxy_cache my_cache; - 上游响应本身允许被缓存：默认不缓存含
Cache-Control: no-cache、private、no-store或Set-Cookie的响应；必要时加：proxy_ignore_headers Cache-Control Set-Cookie;
利用作用域层级实现精细覆盖
Nginx 支持在不同配置块中重复使用 proxy_cache_valid，以**最近的作用域为准**：
- 全局策略（
http块）：proxy_cache_valid 200 5m; any 1m; - 接口路径覆盖（
location /api/）：proxy_cache_valid 200 30s; 500 5s; - 结果：该路径下 200 缓存 30 秒、500 缓存 5 秒；其余状态码仍走
any 1m
验证是否按预期工作
加一行调试头最直观：add_header X-Cache-Status $upstream_cache_status;
- 用
curl -I多次访问同一 URL，观察响应头中X-Cache-Status是HIT、MISS还是EXPIRED - 首次请求应为
MISS，后续相同请求若返回HIT且响应时间明显下降，说明缓存已命中 - 检查 Nginx error log（需开启 debug 级别）中是否有
using cached response或cached response expired记录
