Nginx CORS 策略中如何通过 proxy_cache 缓存 OPTIONS 预检请求以减轻后端网关压力

Nginx 可缓存 OPTIONS 预检请求以减少后端穿透，需显式配置 proxy_cache_methods 包含 OPTIONS、proxy_cache_key 包含 $http_origin、proxy_cache_valid 按状态码设定有效期，并添加 Access-Control-Max-Age 和 Cache-Control 响应头。

直接在 Nginx 负载均衡层缓存 OPTIONS 预检请求，能显著减少后端网关的无效穿透，尤其在高频跨域场景下效果明显。关键不是“能不能缓”，而是“怎么让 Nginx 把 OPTIONS 当作可缓存响应来处理”——默认它不会缓。

显式启用 OPTIONS 方法缓存

Nginx 的 proxy_cache 默认只缓存 GET 和 HEAD 请求，OPTIONS 不在默认列表中。必须手动加入：

1. 在 http 或 location 块中添加：proxy_cache_methods GET HEAD POST OPTIONS;
2. 不建议用 if ($request_method = OPTIONS) { ... } 单独分支处理，容易引入变量作用域和缓存键不一致问题
3. 若后端仅对 OPTIONS 返回 204，可精简为 proxy_cache_methods GET HEAD OPTIONS;，避免无意义缓存 POST

构造带 Origin 的缓存键

预检请求的合法性依赖于 Origin 头，不同源的 OPTIONS 响应不可混用。缓存键必须包含该字段：

1. 推荐写法：proxy_cache_key "$scheme$request_method$host$uri$is_args$args$http_origin";
2. 避免使用 $request_uri（含原始编码），易因 URL 编码差异导致重复缓存
3. 若后端动态校验 Origin 并返回差异化 CORS 头，此键能确保多源场景下响应精准命中

按状态码设定缓存有效期

预检响应不含业务数据，但携带关键 CORS 头（如 Access-Control-Allow-Methods），适合较长时间缓存：

1. proxy_cache_valid 204 86400; —— 大多数预检返回 204 No Content，缓存 1 天
2. proxy_cache_valid 200 302 3600; —— 少数服务返回 200，缓存 1 小时已足够
3. 明确排除 4xx/5xx：proxy_cache_valid 400 401 403 404 500 502 503 504 0s;，防止错误响应污染缓存

补充强缓存响应头与验证机制

仅 Nginx 缓存不够，还需让浏览器和中间 CDN 明确复用：

1. 添加标准缓存头：add_header Access-Control-Max-Age "86400";、add_header Cache-Control "public, max-age=86400";
2. 禁用绕过逻辑：proxy_cache_bypass $dummy; proxy_no_cache $dummy;（设为始终 false 的变量，或直接注释掉）
3. 开启调试头：add_header X-Cache-Status $upstream_cache_status;，用 curl -X OPTIONS -H "Origin: https://a.com" http://your-api.com/path 观察是否返回 HIT