单纯用add_header无法解决跨域，因其不作用于options预检响应（默认204无头），且不生效于304/204状态；必须显式拦截options并return 204+完整cors头，同时加always参数、指定具体origin、设置vary: origin防缓存。
直接加 add_header 通常不能彻底解决跨域，尤其在涉及 OPTIONS 预检请求、带凭据（withCredentials: true）或自定义 header 的场景下——因为 add_header 不作用于 204/304 响应，也不自动处理预检请求的返回逻辑。
为什么单纯 add_header Access-Control-Allow-Origin * 不生效
浏览器发起跨域请求时，若含自定义 header（如 Authorization）、非简单方法（如 PUT、DELETE）或设置了 credentials，会先发一个 OPTIONS 预检请求。这个请求必须由 Nginx 显式响应成功，且响应头必须完整匹配后续正式请求的要求。
而 add_header 默认不作用于 OPTIONS 请求的响应（Nginx 默认对 OPTIONS 返回 204，但不带任何 CORS 头），导致预检失败，控制台报错：No 'Access-Control-Allow-Origin' header is present on the requested resource。
-
add_header只在当前 location 块内、且响应状态码 ≥ 200 且 ≠ 304/204 时才生效 - 默认
OPTIONS请求走的是内部处理路径，不会触发你写的add_header - 若后端已返回 CORS 头，Nginx 再加一遍可能引发重复 header 报错（如
Access-Control-Allow-Origin多个值）
正确配置：location + if + return 处理预检请求
必须显式拦截 OPTIONS 请求，并用 return 204 主动响应，同时带上全套 CORS 头。这是最稳定、兼容性最好的做法。
示例配置（放在对应 location 块内）：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
location /api/ {
proxy_pass http://backend:8000;
<pre class="brush:php;toolbar:false;"># 处理预检请求
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin 'https://your-frontend.com';
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE';
add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
add_header Access-Control-Allow-Credentials 'true';
add_header Access-Control-Max-Age 1728000;
add_header Content-Type 'text/plain; charset=utf-8';
add_header Content-Length 0;
return 204;
}
# 正式请求也补全 CORS 头（注意 Origin 值需与预检一致）
add_header Access-Control-Allow-Origin 'https://your-frontend.com' always;
add_header Access-Control-Allow-Credentials 'true' always;
add_header Access-Control-Expose-Headers 'Content-Length, X-Total-Count';}
- 把
Access-Control-Allow-Origin设为具体域名，而非*，否则Access-Control-Allow-Credentials: true会被浏览器拒绝 -
always参数确保 header 写入 204/304 响应（Nginx 1.7.5+ 支持） -
Access-Control-Allow-Headers必须精确列出前端实际发送的自定义 header，不能写*（除非后端也支持） - 避免在
server级别全局加 CORS 头，容易和后端冲突；优先在location级别按需配置
proxy_pass 场景下要不要加 CORS 头
如果你用 Nginx 做反向代理（即 proxy_pass 到后端服务），是否需要 Nginx 加 CORS 头，取决于后端是否已处理：
- 后端已正确返回所有 CORS 头 → Nginx 不必再加，否则可能重复（如两个
Access-Control-Allow-Origin） - 后端完全没处理 CORS → Nginx 必须加，且要覆盖预检 + 正式请求
- 后端只处理了部分（比如没处理
OPTIONS）→ Nginx 补全预检逻辑，正式请求头可由后端或 Nginx 任一方提供，但不能两边都写同名头
验证方式：用 curl 或浏览器开发者工具看真实响应头，确认 OPTIONS 请求返回 204 且含完整 CORS 头，POST 等正式请求返回 200 且 Access-Control-Allow-Origin 值与预检一致。
容易忽略的坑：Vary、缓存与 credentials
当启用 Access-Control-Allow-Credentials: true 时，有三个硬性约束必须同时满足，否则浏览器直接拒绝响应：
-
Access-Control-Allow-Origin不能是*，必须是明确的源（如https://a.com） - 响应必须带
Vary: Origin，否则某些 CDN 或代理可能缓存错误的 CORS 响应 - 前端
fetch或XMLHttpRequest必须显式设置credentials: 'include'，否则浏览器不会发 cookie，后端也收不到
建议在 location 中加一行：add_header Vary 'Origin' always;。它不解决跨域本身，但防止因缓存导致的跨域失效——这个问题在线上环境极难排查，日志里完全看不出异常。
