可通过 proxy_cache_bypass 配合 X-Refresh-Cache 请求头实现单 URL 动态绕过缓存并更新：触发时跳过读缓存、回源拉取，需确保响应含 Cache-Control: public 且 proxy_cache_key 稳定，配合 proxy_cache_lock 防击穿。
可以通过 proxy_cache_bypass 指令配合自定义请求头（如 X-Refresh-Cache），在不清理整个缓存区的前提下，对单条 URL 实现“动态绕过缓存、强制回源拉取并更新缓存”的效果。核心在于让 Nginx 在特定请求下跳过缓存直接转发，并确保响应仍被缓存系统接纳为新版本。
设置 proxy_cache_bypass 基于 Header 触发绕过
在 location 块中配置，当请求携带指定 Header 且值非空/非 0 时，跳过缓存：
location /api/ {
proxy_pass http://backend;
proxy_cache my_cache;
proxy_cache_valid 200 5m;
<pre class="brush:php;toolbar:false;"># 当 X-Refresh-Cache 存在且不为 "0" 或空字符串时，绕过缓存
proxy_cache_bypass $http_x_refresh_cache;
# 可选：同时禁用缓存响应（仅用于本次刷新，不影响后续缓存逻辑）
proxy_cache_bypass $http_x_refresh_cache;}
注意：proxy_cache_bypass 的值为非空、非 0、非 "off" 字符串时即生效。例如发送 X-Refresh-Cache: 1 或 X-Refresh-Cache: force 均可触发绕过。
确保刷新后响应仍写入缓存（关键）
仅靠 proxy_cache_bypass 不足以“更新缓存”，它只控制“是否读缓存”。要实现“刷新并覆盖旧缓存”，必须保证回源响应满足缓存条件：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 后端响应需带允许缓存的头部，如
Cache-Control: public, max-age=300 - 避免后端返回
Cache-Control: no-store或Set-Cookie（除非显式配置proxy_ignore_headers Set-Cookie;） - 若后端依赖 Cookie 或认证头区分内容，需用
proxy_cache_key显式排除干扰字段，例如：proxy_cache_key "$scheme$request_method$host$request_uri";
配合 proxy_cache_lock 避免缓存击穿（可选但推荐）
当多个并发刷新请求同时到达，可能引发多次回源。启用缓存锁可确保同一 key 只有一个请求回源，其余等待并复用该响应：
proxy_cache_lock on; proxy_cache_lock_timeout 5s;
这对高并发下刷新热点接口尤其有用，既保证缓存更新，又减轻后端压力。
验证与调试技巧
通过响应头快速确认机制是否生效：
- 正常命中缓存：响应含
X-Cache: HIT（需自行添加add_header X-Cache $upstream_cache_status;） - 带
X-Refresh-Cache: 1请求后返回X-Cache: MISS→ 表示成功绕过 - 紧接着再发普通请求，若返回
X-Cache: HIT且内容已更新 → 表明缓存已刷新成功 - 检查 Nginx error log 中是否有
cache lock failed等提示，辅助排查锁或 key 冲突问题
不复杂但容易忽略的是：绕过只是第一步，真正完成“单条刷新”依赖后端响应可缓存、缓存 key 稳定、以及无干扰头（如 Set-Cookie）导致缓存被自动丢弃。把这三点对齐，就能安全、精准地按需刷新任意一条缓存。
