直接启用 proxy_cache_convert_head on 并不能让 Nginx 将 HEAD 请求“自动转成 GET 去后端取完整响应”，而是使其复用已缓存的 GET 响应头生成 HEAD 响应；首次 HEAD 会触发 GET 缓存填充，后续同 URL 的 HEAD 直接命中缓存返回响应头，不请求后端。

直接启用 proxy_cache_convert_head on 就能让 Nginx 把客户端发来的 HEAD 请求自动转成 GET 去后端取完整响应，同时缓存响应头和响应体——这样后续的 HEAD 请求就能命中缓存，只返回头信息，不走后端。

必须配套的基础缓存配置

这个指令不能单独生效，得和完整的 proxy_cache 体系一起用：

• 先在 http 块里定义缓存路径，比如：
  proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g;
• 在 location 里启用缓存区域：
  proxy_cache my_cache;
• 明确设置哪些状态码能被缓存，尤其要包含 200 和 304：
  proxy_cache_valid 200 304 10m;
• 加上转换开关：
  proxy_cache_convert_head on;

为什么 HEAD 默认不进缓存

HEAD 请求本身不带响应体，Nginx 默认不会为它创建缓存条目，也不会复用已有的 GET 缓存。结果就是每次 HEAD 都直连后端，既浪费资源，又没法利用缓存做条件验证（比如用 If-None-Match 对比 ETag）。开启这个指令后，Nginx 会悄悄用 GET 拉一次完整响应，把头和体一起存下来，之后再收到同 URL 的 HEAD，就直接从缓存里读头、丢掉体，高效又安静。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

后端兼容性要注意

转换的前提是后端能正确响应 GET 请求：

• 后端必须返回完整响应（含 body），否则转换失败会报 502
• 建议 HEAD 和 GET 返回的响应头保持一致，比如 Content-Length、Last-Modified 等不要动态变化，否则可能头体不匹配
• 如果后端对 HEAD 做了特殊逻辑（如跳过某些计算），需评估是否影响语义一致性

验证是否真正生效

最简单的方法是看响应头里的 X-Cache-Status（需提前加 add_header X-Cache-Status $upstream_cache_status;）：

• 第一次 HEAD 请求：状态是 MISSED（因为要先缓存 GET）
• 第二次相同 URL 的 HEAD：状态变成 HIT，说明已从缓存取头成功
• 也可以配合 access_log 查看 upstream 地址是否不再频繁出现