如何利用add_header处理AJAX请求的OPTIONS预检-Nginx-PHP中文网

最有效做法是在匹配接口的location块中用if($request_method='options'){return 204;}拦截预检请求，并配合add_header...always补全cors头，确保options不进后端、不触发代理、不依赖上游响应。

如何利用add_header处理ajax请求的options预检

直接在匹配接口的 location 块里用 if ($request_method = 'OPTIONS') { return 204; } 拦住预检请求，并配合 add_header ... always 补全 CORS 头，是最有效、最稳妥的做法。关键不是“加头”，而是让 OPTIONS 请求不进后端、不触发代理、不依赖上游响应。

必须在具体 location 块中配置，不能写在 server 级

CORS 响应头不会继承。server 块或父 location 里的 add_header 对子 location 中的 proxy_pass 或静态资源完全无效。

接口路径如 location /api/，所有 CORS 配置（包括 if 判断和 add_header）都得放在这里面
静态资源路径如 location ~ \.(js|css|png)$ 也要单独配，否则前端加载 JS 时可能因缺少头被拦截
宝塔等可视化面板的“添加响应头”功能默认只作用于 location /，API 路径需手动编辑 Nginx 配置文件

OPTIONS 请求必须由 Nginx 自己快速响应

浏览器对非简单请求（如带 Authorization、Content-Type: application/json、或使用 PUT/DELETE）会先发 OPTIONS 预检。这个请求根本不会到达你的 PHP/Node/Java 后端。

AJAX技术—无刷新获取数据相关课件

下载

用 if ($request_method = 'OPTIONS') { return 204; } 显式捕获并短路响应
返回 204（推荐）或 200，不能返回 405、3xx、5xx 等状态码
不要在 if 块里写 proxy_pass 或其他逻辑，避免性能损耗和配置混乱

add_header 必须带 always 参数，且头要配全

add_header 默认只在 2xx 和 3xx 响应中生效。虽然 204 属于 2xx，但加 always 是防错关键，尤其后续可能扩展其他状态码分支。

add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com' 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,Content-Type,Authorization' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;（启用凭证时必需）
add_header 'Access-Control-Max-Age' '86400' always;（缓存预检结果，减少重复请求）

区分简单请求与预检请求，按需优化

不是所有跨域请求都会触发 OPTIONS。GET/POST + 标准头（如 Content-Type: application/x-www-form-urlencoded）属于简单请求，无需预检。

对纯静态资源或前端页面，可用宽松策略：只写 add_header ... always，不用 if 判断
对 /api/ 这类真实接口路径，必须显式处理 OPTIONS，确保头完整、响应及时
若需动态控制 Origin（如多前端域名），可用 set $cors_origin ""; + if ($http_origin ~ ...) 提取并赋值