proxy_cache_convert_head 控制 head 请求是否复用 get 缓存：开启（on）时复用缓存头提升效率，但需响应头一致且接受弱一致性；关闭（off）时强制透传后端确保实时性与安全，适用于 minio 鉴权、健康检查等场景。
proxy_cache_convert_head 控制 Nginx 如何处理 HEAD 请求与缓存的交互关系，核心是决定是否允许用已缓存的 GET 响应“生成”HEAD 响应。
它不改变请求方法本身，而是影响缓存命中逻辑和响应构造方式。开启时复用 GET 缓存头、关闭时强制透传后端——这个开关直接影响一致性、安全性和性能三者的权衡。
什么时候该关掉 proxy_cache_convert_head
- 后端对 HEAD 有独立鉴权（如 MinIO 的签名校验或路径白名单），而 GET 缓存可能绕过这些检查
- 需要真实探测资源是否存在或是否过期（比如健康检查、CDN 预热验证）
- 缓存中只有 GET 响应，但业务要求 HEAD 必须反映后端当前状态，不能依赖“缓存存在即有效”的假设
设置方式：
proxy_cache_convert_head off;
此时 HEAD 请求不会查 GET 缓存，而是直接转发给上游，只取响应头、不传响应体，也不写入缓存。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
什么时候可以开启 proxy_cache_convert_head
- 后端对同一 URI 的 GET 和 HEAD 返回完全一致的响应头（包括
Content-Length、Last-Modified、ETag等） - 业务接受弱一致性模型：缓存里有这个资源，就认为它“存在且可用”
- 请求量大、带宽敏感，希望减少重复请求和后端压力
默认就是 on，等价于：
proxy_cache_convert_head on;
Nginx 在命中 GET 缓存后，会剥离响应体，仅返回其响应头，模拟一个合法的 HEAD 响应。
配合其他参数才能真正生效
-
proxy_cache_methods必须包含HEAD（默认已含），否则 HEAD 请求根本不会进入缓存流程 -
proxy_cache_key若未显式包含$request_method，开启proxy_cache_convert_head时，HEAD 实际复用的是 GET 的缓存 key；关闭后建议加上$request_method，避免混淆 -
proxy_cache_valid要覆盖 HEAD 可能返回的状态码（如200、304），否则即使缓存存在也可能不生效
安全与调试提示
- 开启状态下若发现 HEAD 返回 403/404 但 GET 正常，大概率是后端鉴权逻辑不一致
- 可通过
add_header X-Cache-Status $upstream_cache_status;辅助判断 HEAD 是否命中缓存或透传 - 关闭后，HEAD 不会填充缓存，也不会触发
proxy_cache_lock或proxy_cache_background_update
不复杂但容易忽略
