Nginx CORS Authorization头配置教程：解决跨域请求认证Token丢失的完整实战

为什么Authorization头在跨域时会丢失

当前端发起跨域请求并在请求头中携带Authorization（比如JWT Token）时，浏览器会因为同源策略的限制而拦截这个请求，除非服务端明确声明允许该请求头。

很多人在配置Nginx CORS时只加了Access-Control-Allow-Origin，却忘记放行Authorization头，导致前端请求一直报错：Request header field Authorization is not allowed by Access-Control-Allow-Headers。

Nginx配置CORS允许Authorization头的完整步骤

第一步：配置Access-Control-Allow-Headers

在Nginx的location块中，使用add_header指令显式声明允许Authorization头：

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
    add_header 'Vary' 'Origin' always;
}

关键点：Access-Control-Allow-Headers必须包含Authorization，否则浏览器会直接拦截请求。

第二步：处理OPTIONS预检请求

当请求携带Authorization头时，浏览器会先发一个OPTIONS预检请求。Nginx需要正确响应这个请求，否则正式请求根本发不出去：

if ( = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
    add_header 'Access-Control-Max-Age' 86400;
    add_header 'Content-Type' 'text/plain; charset=utf-8';
    add_header 'Content-Length' 0;
    return 204;
}

Access-Control-Max-Age 86400让浏览器缓存预检结果一天，避免每次请求都发OPTIONS，有效减少服务器压力。

第三步：携带Credentials时的注意事项

如果前端请求还携带了Cookie（即设置了withCredentials: true），则有两个额外限制：

• Access-Control-Allow-Origin不能使用通配符*，必须写明确的域名
• 必须加上Access-Control-Allow-Credentials: true

add_header 'Access-Control-Allow-Credentials' 'true' always;

这部分配置与Nginx CORS与Cookie携带配置教程中介绍的方案一致，两者经常需要同时配置。

常见错误与排查方法

• 错误1：用了通配符*但又携带了Authorization头 → 浏览器直接报错，必须指定具体域名
• 错误2：add_header写在if块里被覆盖 → 参考Nginx add_header always参数详解，加上always参数或把配置提到外层块
• 错误3：Nginx后面还有反向代理，导致CORS头被覆盖 → 参考Nginx反向代理CORS配置完整教程，在代理层也做好CORS配置

完整配置示例（可直接复制使用）

以下是一个可直接用于生产环境的完整配置，支持多域名动态匹配：

map   {
    default "";
    "~^https://your-frontend\.com$" "";
    "~^https://admin\.your-frontend\.com$" "";
}

server {
    location /api/ {
        if ( = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin'  always;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
            add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Requested-With' always;
            add_header 'Access-Control-Allow-Credentials' 'true' always;
            add_header 'Access-Control-Max-Age' 86400;
            add_header 'Vary' 'Origin' always;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }

        add_header 'Access-Control-Allow-Origin'  always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, X-Requested-With' always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Vary' 'Origin' always;

        proxy_pass http://backend;
    }
}

使用map指令做多域名匹配的方案，在Nginx CORS多域名动态匹配：if与map两种方案深度对比中有更详细的对比分析。

安全建议与最佳实践

• 不要随意使用Access-Control-Allow-Origin: *，只放行你信任的域名
• 生产环境建议配合WAF使用，防止CORS配置被恶意利用
• 定期用Nginx配置安全检查清单中的项目巡检，确保CORS配置没有引入新的安全风险
• 如果使用了JWT Token，建议设置合理的Token过期时间，并在Nginx层做Token格式校验

配置完成后，用浏览器开发者工具的Network面板检查请求头，确认Authorization头正常发出且响应中包含正确的Access-Control-Allow-Headers。