nginx中cors应优先配置在location块：作用范围精准、符合最小权限原则、可安全处理options预检、支持origin动态白名单，且便于反向代理场景下的路径级差异化策略。
在 Nginx 中配置 CORS，放在 server 块还是 location 块，核心区别在于作用范围和安全性控制。server 块生效于整个虚拟主机的所有请求路径；location 块则只对匹配的路径生效，更精准、更安全。
作用范围不同
server 块内的 add_header 指令会对该 server 下所有响应（包括 /、/static/、/api/ 等）统一添加 CORS 头。这适合前端完全托管在该域名下、且所有资源都需跨域访问的简单场景。
location 块只影响匹配路径下的响应。比如 location /api/ { … } 仅给以 /api/ 开头的接口加头，静态资源（如 /images/logo.png）不受影响，避免无意暴露敏感响应头。
- 全局配置（server 块）：适合开发环境快速验证，或整站为单页应用+后端 API 同域部署的极简架构
- 路径级配置（location 块）：生产环境推荐做法，符合最小权限原则，也便于后续按业务模块拆分策略
OPTIONS 预检请求处理方式不同
浏览器对非简单请求（如带 Authorization 头的 POST）会先发 OPTIONS 请求。如果把 CORS 头和 if ($request_method = 'OPTIONS') 放在 server 块里，它可能被其他不期望的路径（如 /login、/upload）意外触发，造成逻辑混乱或安全疏漏。
而放在 location 块中，可确保预检逻辑与实际业务路径严格绑定。例如：
- location /api/ { … if ($request_method = 'OPTIONS') { return 204; } }
- location /admin/ { … 不加 OPTIONS 处理，拒绝管理后台的跨域调用 }
Origin 白名单灵活性差异
server 块难以实现“多前端源”动态适配。若需支持 http://a.com 和 https://b.net 两个前端，硬编码多个 add_header 会冲突（Nginx 不允许多个同名 header 覆盖）。
location 块更容易配合 map 模块做动态判断：
- 先用 map $http_origin $cors_origin 定义白名单映射
- 再在 location /api/ 中引用 $cors_origin 作为 Access-Control-Allow-Origin 的值
- 这样既支持多源，又避免 * 导致无法携带 Cookie 的问题
是否需要 proxy_pass 也影响选择
如果该 server 是纯静态服务（如 Vue 打包文件），跨域配置应放在前端所在 server 块或对应 location；
如果该 server 实际是反向代理（proxy_pass 到后端 API），CORS 头必须由 Nginx 在响应返回给浏览器前注入——此时无论放 server 还是 location，都属于“代理层统一封装”，但 location 更利于按接口路径差异化配置（如 /api/v1 允许凭证，/health 不允许）。
