Nginx的proxy_cache_methods不支持自定义HTTP方法，因其内核硬编码仅识别标准方法（GET、HEAD、POST等），且OPTIONS/TRACE/CONNECT明确不可缓存；非标准方法如SEARCH、PATCH会被静默忽略。
proxy_cache_methods 本身不支持自定义 HTTP 方法，这是由 Nginx 内核硬编码限制决定的。它只接受标准方法（GET、HEAD、POST、PUT、DELETE、OPTIONS、TRACE、CONNECT），且其中 OPTIONS、TRACE、CONNECT 明确不可缓存，其余也需满足语义与协议约束。所谓“自定义方法”（如 SEARCH、PATCH、REPORT、PROPFIND 等）无法通过 proxy_cache_methods 启用缓存，配置后会被静默忽略，不会报错但也不生效。
为什么不能缓存自定义方法
Nginx 的缓存机制严格遵循 RFC 7234 对 HTTP 缓存语义的定义：
- 只有安全（safe）、幂等（idempotent）或明确标记为可缓存的方法才被允许进入缓存流程；
- SEARCH、PATCH 等虽在部分 WebDAV 或私有 API 中使用，但未被 HTTP 标准赋予缓存语义；
- Nginx 源码中对请求方法的校验是白名单式判断，仅识别已知标准方法字符串，遇到 unrecognized method 直接跳过缓存逻辑。
可行的替代路径
若业务场景依赖类似 SEARCH 或 REPORT 的语义且需要边缘加速，应转换思路，不强求“缓存自定义方法”，而是将语义映射到标准方法上：
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
- 统一走 POST + 语义字段：前端发 POST /api/v1/query，body 中含 {"method":"SEARCH","params":{"q":"nginx"}}；后端统一处理，Nginx 可配置 proxy_cache_methods GET POST，并用 proxy_cache_key 包含 $request_body（注意 body 大小和哈希开销）；
- 重写为标准方法再缓存：用 map + rewrite 将特定 path 或 header 映射为标准方法，例如匹配 $arg_method=SEARCH 时，设 $cache_method = "GET"，再用 proxy_method GET 配合 proxy_pass，同时将参数拼入 URI，使整个请求符合 GET 缓存前提；
- 用 X-Accel-Expires 委托后端控制：让后端响应中带上 X-Accel-Expires: 300 或 Cache-Control: public, max-age=300，Nginx 在 proxy_cache 已启用的前提下会自动缓存该响应——只要请求本身是 GET/HEAD/POST（且 proxy_cache_methods 允许），不关心原始 method 名称是否“自定义”。
实际配置要点
若坚持在 location 中尝试扩展，务必确认以下条件全部满足：
- 已定义 proxy_cache_path 并在对应作用域启用 proxy_cache；
- proxy_cache_methods 显式列出目标方法（如 GET POST），但不要写 SEARCH；
- proxy_cache_key 必须能唯一区分语义差异（例如 "$scheme$request_method$host$request_uri$args$request_body"）；
- proxy_cache_valid 明确设置状态码缓存时间，避免 5xx 或 4xx 被意外缓存；
- 后端响应必须带合法缓存头（Cache-Control 或 Expires），否则 Nginx 默认不缓存（除非 proxy_cache_valid 强制覆盖）。
本质上，边缘加速不依赖 method 名称是否“新”，而取决于请求是否可标识、响应是否可信、生命周期是否可控。绕过 method 限制，聚焦语义建模和 key 设计，才是稳定落地的关键。
