Nginx 默认复用 GET 缓存处理 HEAD 请求，存在权限绕过与状态失真风险；关闭 proxy_cache_convert_head 可使 HEAD 透传后端确保实时性，开启则提升效率但需满足响应头一致等条件。
关键在于明确 HEAD 请求是否需要复用 GET 缓存，以及是否允许传输响应体。proxy_cache_convert_head 就是控制这个行为的开关。
理解默认行为与实际需求的错位
Nginx 默认会把 HEAD 请求当作 GET 来处理缓存——即查到对应 URI 的 GET 缓存后，直接返回该缓存的响应头（不带 body），而不真正向后端发 HEAD。这看似高效，但存在两个隐患：
- 某些后端（如 MinIO）对 HEAD 有严格鉴权或路径校验逻辑，而 GET 缓存可能绕过这些检查，导致 403 或 404
- 如果缓存中只有 GET 响应，但业务上要求 HEAD 必须真实探测后端状态（比如检查对象是否存在且未过期），复用 GET 缓存就失去意义
关闭转换：让 HEAD 真实走通后端
设为 proxy_cache_convert_head off; 后，HEAD 请求不再尝试匹配 GET 缓存，而是直接透传给上游，并仅返回响应头。此时：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 缓存系统完全不干预 HEAD 流程，避免权限/路径误判
- 适合用于健康检查、资源存在性探测等必须反映实时后端状态的场景
- 不会占用 GET 缓存空间，也不会因缓存污染影响 GET 命中率
开启转换：复用 GET 缓存提升效率
设为 proxy_cache_convert_head on;（或不配置，即默认）时，Nginx 在命中 GET 缓存的前提下，可直接用该缓存生成 HEAD 响应（只取 header，丢弃 body）。适用条件是：
- 后端对 GET 和 HEAD 的响应头一致，且无副作用
- 业务能接受“缓存存在即代表资源存在”的弱一致性模型
- 请求量大、带宽敏感，需减少重复请求和数据传输
配合 proxy_cache_methods 与缓存键设计
单独调这个参数不够，还需确保整体缓存策略协同：
- 若希望 HEAD 也能被独立缓存（而非仅复用 GET），需在 proxy_cache_methods 中显式包含 HEAD，例如：proxy_cache_methods GET HEAD;
- 若开启转换，建议保持 proxy_cache_key 不含 $request_method，否则 GET 和 HEAD 会生成不同 key，无法复用
- 若关闭转换，又想缓存 HEAD 响应本身，需确保后端返回 Cache-Control 或 X-Accel-Expires，且 proxy_cache_valid 覆盖 HEAD 对应的状态码（如 200、304）
