Nginx处理复杂跨域请求时OPTIONS预检的性能优化实战-Nginx-PHP中文网

Nginx应直接响应OPTIONS预检请求返回204，不转发至后端，并用add_header always精准设置Access-Control-Allow-Origin、Methods、Headers等CORS头，区分简单与预检请求按需配置，结合map动态校验Origin确保安全。

nginx处理复杂跨域请求时options预检的性能优化实战

当Nginx面对含自定义头、认证信息或非简单方法（如PUT、DELETE）的跨域请求时，浏览器会先发一个OPTIONS预检请求。若每次预检都透传到后端，不仅增加延迟，还可能压垮应用服务。关键优化思路是：让Nginx直接响应OPTIONS，不转发；同时精准控制CORS响应头，避免冗余或错误配置。

直接拦截并返回204的OPTIONS请求

Nginx应主动终结预检请求，而不是代理给上游。这能节省一次网络往返和后端处理开销。只需在location块中匹配OPTIONS方法并立即返回：

使用if ($request_method = 'OPTIONS')判断（注意：仅限server或location上下文，且不能嵌套）
返回204 No Content——语义准确、无响应体、HTTP/1.1兼容性好
必须显式设置add_header补充CORS必需头，如Access-Control-Allow-Origin、Methods、Headers等

避免add_header被覆盖或重复

在Nginx中，add_header指令在子请求（如内部重定向）或多个location嵌套时可能失效或叠加。常见陷阱包括：

在server块里add_header，但location里又用proxy_pass——此时server级header默认不继承
同一location内多次add_header同名头，只有最后一个生效
未设置always参数，导致仅在2xx/3xx响应中添加（而204属于2xx，所以通常够用，但需确认）

建议统一在处理OPTIONS的location中集中声明，并为关键CORS头加always确保送达：

add_header 'Access-Control-Allow-Origin' '*' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' always;

区分简单请求与预检请求，按需放行

不是所有跨域请求都需要预检。只有满足以下任一条件才触发OPTIONS：

请求方法不是GET、HEAD、POST
请求头包含自定义字段（如X-Auth-Token）或非标准安全头（如Content-Type值不是application/x-www-form-urlencoded、multipart/form-data、text/plain）

因此，可对静态资源或纯GET接口单独配置宽松CORS策略，跳过OPTIONS拦截逻辑；而对API路径（如/api/）启用完整预检处理。这样既保证安全性，又避免过度拦截。

配合后端做好Origin校验与动态响应

生产环境不建议盲目返回Access-Control-Allow-Origin: *（尤其带Credentials时）。更稳妥的做法是：

Nginx从$http_origin提取来源，用map模块做白名单匹配
将合法Origin变量传给后端（通过proxy_set_header），由业务层决定是否信任并回写对应Origin头
若必须由Nginx动态响应，可用map + add_header组合，例如：
map $http_origin $cors_origin {
  "https://a.example.com" "https://a.example.com";
  "https://b.example.com" "https://b.example.com";
  default ""; }
add_header 'Access-Control-Allow-Origin' $cors_origin always;

这样既避免硬编码，又防止任意源伪造。