nginx 的 add_header 不生效主因是作用域限制、后端覆盖及 options 预检未处理；必须在 proxy_pass 所在 location 块中配置，禁用 access-control-allow-origin: * 与 credentials 共存，并动态匹配 origin 或改用反向代理规避跨域。
直接在 Nginx 配置里加 add_header 不一定生效，尤其当你用的是 proxy_pass 或 PHP-FPM 时，响应头可能被后端覆盖或压根没走到你写的 location 块里。
为什么 add_header 不生效？常见位置和覆盖逻辑
Nginx 的 add_header 只对当前 location 块内产生的响应生效，不继承、不穿透。如果请求被 proxy_pass 转发，而你又没在 proxy 所在的 location 块里写 add_header，那浏览器根本收不到 CORS 头。
- PHP 场景下，
location ~ \.php$和location /api/是两个独立块，不能混用；把 CORS 头写在location /里，对.php请求无效 - 用了
proxy_pass后，Nginx 默认不转发后端返回的Access-Control-Allow-Origin，除非你显式用proxy_pass_request_headers on（但通常不推荐） -
add_header在 if 块里是“有条件添加”，但 if 在 location 中属于“伪指令”，容易引发意外行为（比如 OPTIONS 返回 204 时 header 没加全）
OPTIONS 预检请求必须显式拦截并 return 204
浏览器对 POST/PUT/带自定义 header 的请求，会先发一次 OPTIONS。如果你只靠 add_header，Nginx 默认会把 OPTIONS 当普通请求转发给后端——而后端很可能没实现 OPTIONS，返回 405 或 502，前端就卡死。
- 必须在同一个
location块里加if ($request_method = 'OPTIONS') { ... return 204; } -
return 204之后 Nginx 不再执行后续配置，所以所有 CORS 头必须写在 if 块内部 -
Content-Length: 0和Content-Type: text/plain是防止某些旧版浏览器解析空响应体出错，不是可选项
Access-Control-Allow-Origin 不能和 credentials 共存于 *
只要前端 JS 设置了 fetch(..., { credentials: 'include' }) 或 XMLHttpRequest.withCredentials = true，后端（即 Nginx）就不能设 Access-Control-Allow-Origin: *，否则浏览器直接拒绝响应。
- 必须写成具体域名，例如
add_header 'Access-Control-Allow-Origin' 'https://fe.example.com'; - 如果前端有多个域名（如本地开发
http://localhost:3000+ 测试环境https://test-fe.example.com），不能硬编码，得用变量动态匹配：map $http_origin $cors_origin { ... }，再在 location 中引用$cors_origin -
Access-Control-Allow-Credentials: true必须配对出现，漏掉会导致凭证不发送
反向代理比纯 CORS 更可靠，尤其对本地开发
与其在 Nginx 里反复调 add_header 和 if，不如让前后端“物理同源”：前端请求 /api/xxx，Nginx 收到后转发到真实后端，浏览器全程只跟一个域名通信。
- 配置示例：
location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; }（注意末尾斜杠，影响路径拼接） - 不需要任何
add_header，也不用管 OPTIONS，因为浏览器根本不触发跨域检查 - 唯一要注意的是后端返回的
Set-Cookie域名，需用proxy_cookie_domain重写，否则 Cookie 写不进前端域名
真正难的不是加几行配置，而是搞清请求到底走哪个 location、有没有被 proxy 截断、credentials 开关是否和 Origin 值对得上——这些细节一错，控制台就只报“CORS error”，连具体哪条 header 缺失都不会说。
