仅靠add_header无法可靠支持CORS预检，因其默认不作用于405等错误响应，且if块内add_header会清空父级同名头；必须用always参数+显式return 204处理OPTIONS请求。
在 Nginx 中使用 add_header 统一配置 CORS 并不能完全解决预检（OPTIONS）请求失败的问题——因为 add_header 默认不作用于 204、301、302、401、404 等非 200 响应，而预检请求返回的正是 204（或有时是 200），但更关键的是：Nginx 不会为 OPTIONS 请求自动执行你定义的 location 块中的常规处理逻辑（比如 proxy_pass），除非显式匹配并处理它。
为什么仅靠 add_header 无法可靠支持 CORS 预检？
Nginx 的 add_header 指令具有两个重要限制：
- 它只向 成功响应（2xx）和重定向（3xx） 添加头，而预检请求常返回 204（属于 2xx），看似可行；但若 location 中未真正处理 OPTIONS 请求（例如没配
return 204或proxy_pass），Nginx 可能直接返回 405 Method Not Allowed —— 此时add_header完全不生效； -
add_header是“追加”行为，且继承规则复杂：子 block 中未重新声明则沿用父级，但一旦子 block 有任意add_header，父级同名 header 就会被清空（不是覆盖，是覆盖性重置）。
正确做法：显式拦截 OPTIONS 并统一注入 CORS 头
必须同时满足三个条件：匹配 OPTIONS 方法、返回合法响应码（如 204）、确保所有相关响应（包括预检和实际请求）都携带完整 CORS 头。推荐结构如下：
location /api/ {
# 允许的源、方法、头（按需调整）
set $cors_origin "";
if ($http_origin ~* "^https?://(localhost:3000|myapp\.example\.com)$") {
set $cors_origin $http_origin;
}
<pre class="brush:php;toolbar:false;"># 对所有请求（含预检）添加基础 CORS 头
add_header 'Access-Control-Allow-Origin' $cors_origin always;
add_header 'Access-Control-Allow-Credentials' 'true' 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;
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range' always;
# 关键：显式处理预检请求
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Max-Age' 17280000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
# 实际代理转发（或其他后端处理）
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;}
注意：always 参数是核心——它让 add_header 生效于所有响应码（包括 204），Nginx 1.7.5+ 才支持。
常见陷阱与绕过方案
-
避免在 if 中写 add_header：if 块内使用
add_header会导致该 location 下所有其他add_header失效（因 if 触发新上下文）。应把通用头提到 if 外，仅在 if 内做 return 和少量补充头； -
不要依赖默认 200 响应处理 OPTIONS：即使后端支持 OPTIONS，Nginx 若未 proxy_pass 到它，就可能因无匹配 handler 返回 405 —— 必须显式
return 204或proxy_pass； -
credentials 与通配符 Origin 冲突：若设置
Access-Control-Allow-Credentials: true，则Access-Control-Allow-Origin不能为*，必须是具体域名（如示例中用变量动态赋值）； -
调试技巧：用 curl 模拟预检：
curl -H "Origin: https://myapp.example.com" -H "Access-Control-Request-Method: POST" -X OPTIONS -I http://your-nginx/api/test，检查响应头和状态码。
更简洁稳健的替代方案（推荐）
如果业务允许，可借助 OpenResty 或 Nginx Plus 的高级模块；但对标准 Nginx，更清晰的做法是将 CORS 逻辑封装为一个可复用的片段（如 cors.conf），并在各 location 中 include，并始终搭配 if ($request_method = 'OPTIONS') { ... return 204; }。这样既统一又可控，避免 header 覆盖混乱。
关键是把“预检”当作一个需要主动响应的 HTTP 方法，而不是等待后端处理的普通请求。
