对404响应设置短时缓存(如10秒)可有效缓解恶意扫描和错误请求对后端的压力,需在proxy_pass所在location中单独配置proxy_cache_valid 404 10s,并配合inactive=30s防止缓存堆积。

对 404 响应设置独立缓存,核心目的是减少因恶意扫描、爬虫或错误链接反复请求不存在资源而给后端带来的无效压力。Nginx 的 proxy_cache_valid 支持按状态码精细化控制缓存时长,404 正适合用极短时间(如几秒到1分钟)缓存,既防刷又不长期污染缓存。
明确 404 缓存的定位和时长选择
404 表示资源确实不存在,缓存它不是为了“加速访问”,而是避免同一 URL 在短时间内被高频重试。因此缓存时间必须足够短:
- 一般设为 5–30 秒:兼顾防刷效果与及时性,例如
proxy_cache_valid 404 10s; - 不建议超过 60 秒:否则用户修改路由或上线新资源后,仍会持续返回旧的 404 缓存,影响调试和体验
- 避免使用
any全局覆盖:如proxy_cache_valid any 1m;会把 200/302 等正常响应也压到 1 分钟,违背缓存策略初衷
在 location 中单独配置 404 缓存规则
需确保该 location 走代理(即含 proxy_pass),且 proxy_cache_valid 指令放在生效范围内(server 或 location 块中):
location /static/ {
proxy_pass http://backend;
proxy_cache my_cache;
<pre class="brush:php;toolbar:false;"># 仅对 404 设置 10 秒缓存
proxy_cache_valid 404 10s;
# 其他状态码按需设置(不冲突)
proxy_cache_valid 200 302 1h;
proxy_cache_valid 301 1d;
# 可选:让 404 响应也带缓存标识,便于排查
add_header X-Cache-Status $upstream_cache_status;}
注意:多个 proxy_cache_valid 指令可共存,Nginx 会按状态码精确匹配,互不影响。
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景:1)部署用量统计代理;2)统计多人Token用量和调用次数;3)管理大模型API调用配额。
配合 inactive 参数防止缓存堆积
即使设置了短时 404 缓存,大量不同 404 URL(如随机路径扫描)仍可能快速占满缓存空间。需靠 proxy_cache_path 的 inactive 参数兜底:
-
inactive=30s:任何缓存项若 30 秒内未被再次访问,无论是否过期,都会被自动清理 - 搭配 404 的 10s 缓存,能确保扫描类请求产生的缓存“来得快、去得更快”
- 示例完整路径定义:
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:50m inactive=30s max_size=2g;
验证与观察缓存行为
加一条响应头,方便确认是否命中 404 缓存:
add_header X-404-Cached $upstream_cache_status;
然后用 curl 测试:
curl -I http://your-domain.com/static/xxx.js首次返回 X-404-Cached: MISS,第二次在 10 秒内返回 HIT,超时后再次变为 MISS,说明配置已生效。

















