Nginx需按location粒度为各微服务模块配置独立CORS策略：指定可信Origin、启用Credentials、设置Methods/Headers白名单，并在Nginx层拦截处理OPTIONS预检请求，避免透传至后端。
在微服务或前后端分离架构中，不同业务模块（如用户中心、订单系统、支付网关）常部署在不同域名或子域下，Nginx 作为统一入口，需为各模块配置精细化的跨域（CORS）策略——不能一刀切地允许所有来源，也不能全局禁用。核心原则是：按 location 或 server 粒度，为每个业务路径设置独立的 Access-Control-Allow-Origin、凭证支持、方法与头字段白名单。
按 location 区分模块，独立配置 CORS 头
将不同业务模块映射到 Nginx 的不同路径（如 /api/user/、/api/order/、/api/pay/），并在对应 location 块中单独定义跨域规则：
- 使用
add_header显式设置响应头，注意加always参数，确保对非 2xx 响应（如 401、500）也生效 - 避免在 server 级别统一 add_header，否则会被子 location 覆盖或重复添加
- 对需要携带 Cookie 的请求（如登录态校验），必须同时设置
Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能为*，须指定确切域名
示例：
location /api/user/ {
proxy_pass https://user-svc:8080/;
add_header 'Access-Control-Allow-Origin' 'https://admin.example.com' 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;
<pre class="brush:php;toolbar:false;">if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}}
location /api/order/ { proxy_pass https://www.php.cn/link/bf99455b9c632c2cca040bd026057559; add_header 'Access-Control-Allow-Origin' 'https://www.php.cn/link/87984ef92f4eb26a3400598e2fe21c19' always; add_header 'Access-Control-Allow-Credentials' 'true' always; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always; add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization,X-Trace-ID' always;
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Max-Age' 86400;
add_header 'Content-Length' 0;
return 204;
}}
针对预检请求（OPTIONS）做轻量透传或拦截处理
浏览器对非简单请求会先发 OPTIONS 预检。Nginx 不应将 OPTIONS 请求转发给后端服务（增加无谓开销），而应在 Nginx 层直接响应：
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 用
if ($request_method = 'OPTIONS')拦截，返回 204 状态码 - 预检响应中必须包含与实际请求匹配的
Access-Control-Allow-Methods和Access-Control-Allow-Headers - 若模块要求严格校验 Origin（如仅允许多个可信域名），可在 if 块内用 map 或变量做条件判断，动态设置 Origin 值
多源支持：用 map 指令实现 Origin 白名单匹配
当某模块需支持多个前端域名（如测试环境 https://dev.example.com、生产环境 https://app.example.com），不建议硬编码多个 add_header。推荐用 map 构建可信 Origin 映射：
map $http_origin $cors_origin {
default "";
"~^https?://(dev\.example\.com|app\.example\.com|staging\.example\.com)$" "$http_origin";
}
<p>server {
listen 80;
location /api/pay/ {
proxy_pass <a href="https://www.php.cn/link/5b310acc61b824bed34736ac28969bef">https://www.php.cn/link/5b310acc61b824bed34736ac28969bef</a>;
add_header 'Access-Control-Allow-Origin' $cors_origin always;
add_header 'Access-Control-Allow-Credentials' 'true' always;</p><h1>其他 CORS 头...</h1><pre class="brush:php;toolbar:false;">}}
这样既保证安全性，又具备可维护性；非法 Origin 将匹配到空字符串，Nginx 不发送 Access-Control-Allow-Origin，浏览器自动拒绝跨域请求。
调试与验证要点
上线前务必验证 CORS 行为是否符合预期：
- 用 curl 模拟真实跨域请求：
curl -H "Origin: https://www.php.cn/link/87984ef92f4eb26a3400598e2fe21c19" -I https://api.example.com/api/order/list，检查响应头 - 在浏览器开发者工具 Network 标签中查看预检请求（OPTIONS）和主请求的响应头是否一致
- 确认带凭证请求（含 Cookie 或 Authorization）未被浏览器静默屏蔽——需检查
Access-Control-Allow-Credentials和Access-Control-Allow-Origin是否协同正确 - 注意 Nginx 版本差异：1.7.5+ 支持
add_header ... always，旧版本需配合more_set_headers模块
不复杂但容易忽略：跨域控制本质是 HTTP 头协商机制，Nginx 只负责注入响应头，真正决定是否放行的是浏览器。因此，规则必须精准对应前端发起请求时的 Origin、Credentials、Method 和 Headers，任何一项不匹配都会导致失败。
