Nginx中OPTIONS请求预检失效导致跨域失败的排查教程-Nginx-PHP中文网

options预检失败主因是nginx未显式处理该方法且未返回合规cors响应头；须在location中配置add_header加always参数，并用if拦截options返回204，同时确保origin校验与响应头精确匹配。

nginx中options请求预检失效导致跨域失败的排查教程

OPTIONS预检请求失败，通常不是Nginx没转发，而是它被“悄悄拦下”或“没正确响应”，导致浏览器终止后续真实请求。核心问题在于：Nginx默认不处理OPTIONS方法，也不自动返回CORS所需头信息，必须显式配置。

浏览器发起跨域请求前，会先发一个无body、仅含Origin和Access-Control-Request-*头的OPTIONS请求。如果这个请求根本没进Nginx，就不是配置问题，而是前端发错地址、DNS解析错误、或中间有CDN/防火墙拦截。

排查方法：

在Nginx access_log中加 log_format 记录 $request_method $request_uri $status，然后复现操作，看日志里有没有 OPTIONS 行
用 curl 模拟预检：curl -X OPTIONS -H "Origin: https://example.com" -H "Access-Control-Request-Method: POST" -I http://your-api.com/path
若返回 405 Method Not Allowed 或直接超时，说明请求卡在Nginx层；若返回 200 但缺CORS头，说明到了Nginx但响应不合规

Nginx默认不处理OPTIONS（尤其当location中只配了proxy_pass且没匹配到对应method时），需主动捕获并返回204或200。不能依赖后端处理——预检必须在Nginx层面快速响应，否则延迟或失败。

推荐写法（放在对应 location 块内）：

add_header Access-Control-Allow-Origin "$http_origin" always;（always确保OPTIONS也生效）
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;
add_header Access-Control-Expose-Headers "Content-Length,Content-Range" always;
if ($request_method = 'OPTIONS') { return 204; }（最轻量，无body；也可用200+空body）

add_header 在 if 块或非server/location顶层作用域中默认不继承，容易漏掉。常见坑：

把 add_header 写在 if ($request_method = 'OPTIONS') { } 外面，但没加 always，则OPTIONS响应里不会带这些头
多个location嵌套时，子location未重复声明 add_header，导致预检响应缺失关键头
$http_origin 要配合 valid_referers 或白名单校验（如 map $http_origin $cors_origin），避免通配符 * 与 credentials 冲突