Nginx 不支持缓存自定义 HTTP 方法（如 SEARCH、PATCH），仅允许 GET、HEAD、POST、PUT、DELETE；OPTIONS/TRACE/CONNECT 被硬编码禁用，未定义方法静默跳过缓存。可行方案包括：统一用 POST + 语义化 body 并定制 cache_key；用 map 将参数映射为标准 GET 路径；或由后端通过 Cache-Control/X-Accel-Expires 控制缓存，前提是已配置 proxy_cache_path、proxy_cache 和 proxy_cache_valid。
无法通过 proxy_cache_methods 开启对自定义 HTTP 方法（如 SEARCH、PATCH、REPORT 等）的缓存支持。
原因很明确：Nginx 不识别也不允许缓存非标准方法
Nginx 的缓存逻辑基于 RFC 7234，只接受白名单内的标准 HTTP 方法：GET、HEAD、POST、PUT、DELETE。其中：
-
OPTIONS、TRACE、CONNECT被硬编码为不可缓存，写进proxy_cache_methods也静默忽略； - 任何未在 HTTP/1.1 或 HTTP/2 标准中定义的方法（例如
SEARCH），Nginx 源码会直接跳过缓存流程，不报错、不警告、也不生效； - 即使你配置
proxy_cache_methods GET HEAD SEARCH，SEARCH部分完全无效，实际仍只处理GET和HEAD。
真正可行的替代方案
若业务中存在类似自定义语义（比如搜索、批量查询、资源发现）且需要边缘加速，应绕过“方法名”限制，转而利用标准方法承载语义：
-
统一走 POST + 语义化 body：前端发
POST /api/v1/query，body 含{"type":"search","q":"nginx"}；后端解析执行；Nginx 配置proxy_cache_methods GET POST，并用proxy_cache_key "$scheme$request_method$host$request_uri$request_body"区分不同请求（注意控制$request_body大小，建议 ≤1KB）； -
URI 参数映射为标准方法：用
map指令将特定参数转成可缓存路径，例如匹配$arg_x_method=SEARCH时，重写为GET /_search?q=$arg_q，再由 Nginx 原生缓存该 GET 请求； -
交由后端控制缓存生命周期：让后端响应带上
X-Accel-Expires: 300或Cache-Control: public, max-age=300，只要请求本身是GET/HEAD/POST（且proxy_cache_methods允许），Nginx 就会缓存——不关心原始 method 名称是否“自定义”。
必须同步满足的基础条件
无论采用哪种替代路径，以下三项缺一不可：
- 在
http块中已定义proxy_cache_path，指定缓存路径与keys_zone； - 在对应
location中启用proxy_cache（值需与keys_zone名称一致）； - 设置合理的
proxy_cache_valid，或确保后端响应含明确缓存头（如Cache-Control）。
强行在 proxy_cache_methods 中加入非标准方法，只会带来配置幻觉——看起来写了，实际没用。
