理解 CORS 机制与 Nginx 的角色定位
浏览器的同源策略是 Web 安全的基石，它严格限制协议、域名与端口完全一致的源之间才能互相读取数据。当跨域请求发生时，浏览器会默认拦截响应，除非服务器通过 CORS 机制明确授权。CORS 依赖 HTTP 响应头进行权限协商，其中 Access-Control-Allow-Origin 是最核心的字段。Nginx 作为反向代理或统一网关，天然适合在此环节集中注入 CORS 响应头，从而避免后端业务代码重复编写跨域逻辑。需要明确的是，Nginx 只能解决因服务器未返回正确响应头导致的跨域拦截问题，无法绕过浏览器底层的安全策略，也不能替代后端自身的身份鉴权。通过 Nginx 统一管理跨域配置，可显著降低架构耦合度并提升运维效率。
使用 add_header 配置基础跨域响应头
在 Nginx 中实现跨域主要依赖 add_header 指令。典型配置需在 location 块中声明：add_header Access-Control-Allow-Origin 指定允许的前端域名；add_header Access-Control-Allow-Methods 定义允许的 HTTP 动词如 GET、POST、PUT 等；add_header Access-Control-Allow-Headers 声明前端可携带的自定义请求头。必须注意，add_header 默认仅在响应状态码为 2xx 与 3xx 时生效，若需确保 4xx 或 5xx 错误响应也携带跨域头，必须追加 always 参数。此外，Nginx 的 add_header 具有层级覆盖特性，若父级 server 块已定义该指令，子级 location 块中的同名指令将完全覆盖父级配置，因此建议在具体 location 中集中声明，并配合 proxy_pass 正确转发请求，以保证配置精准生效。
处理 OPTIONS 预检请求与跨域凭证
当请求携带非简单请求特征（如自定义 Header、application/json 类型或非标准方法）时，浏览器会自动发起 OPTIONS 预检请求，以确认服务器是否允许该跨域操作。Nginx 需显式拦截该请求并返回 200 或 204 状态码，通常通过 if ($request_method = 'OPTIONS') 块实现，并在其中返回对应的 Allow-Methods 与 Allow-Headers。若业务需携带 Cookie 或 HTTP 认证信息，需设置 Access-Control-Allow-Credentials 为 true。但 CORS 规范严格规定：当凭证为 true 时，Access-Control-Allow-Origin 绝不能使用通配符星号，否则浏览器将直接拒绝响应。此时应通过 Nginx 变量动态匹配请求头中的 Origin，或明确列出可信域名白名单，以兼顾安全性与业务功能性。
验证跨域配置并排查常见问题
配置完成后，务必执行 nginx -t 检查语法，并通过 nginx -s reload 平滑重载。验证阶段可结合终端与浏览器：使用 curl -I -H Origin:https://frontend.example.com http://your-domain/api/test 查看响应头是否包含 CORS 字段；同时在 Chrome DevTools 的 Network 面板中观察实际请求的 Response Headers。常见故障包括：add_header 未生效，多因遗漏 always 参数或配置层级被覆盖；OPTIONS 返回 404 或 405，通常因 Nginx 未显式拦截 OPTIONS 或后端未处理该动词；响应头缺失，可能因后端框架自行设置了 CORS 头导致冲突；Origin 不匹配，需核对请求头 Origin 与 Nginx 配置值是否完全一致含协议与端口。排查时应逐层剥离代理链，优先确认 Nginx 是否按预期注入头部。
