一、No 'Access-Control-Allow-Origin'：最常见的"拦路虎"

错误现场：浏览器控制台红字警告：No '
Access-Control-Allow-Origin' header is present on the requested resource。前端请求像被保安拦下的外卖员，连门都进不了。
本质原因：服务器端未配置CORS响应头，浏览器的"同源策略"判定此次跨域请求不安全。同源指协议、域名、端口三者完全一致，哪怕只差一个端口号，也会触发CORS校验。
解决方案：

• 后端配置：在响应头添加 Access-Control-Allow-Origin: https://your-frontend.com（指定允许的源），或用 * 允许所有源（生产环境不推荐）。
• 临时调试：使用浏览器插件如"Allow CORS: Access-Control-Allow-Origin"临时绕过（仅开发环境使用，生产环境无效）。

二、Origin不匹配：服务器的"认生"行为

错误现场：明明配置了
Access-Control-Allow-Origin: *，却依然报错 The '
Access-Control-Allow-Origin' header has a value 'http://localhost:3000' that is not equal to the supplied origin。
本质原因：当请求带凭据（如Cookie、Authorization头）时，服务器不能使用 * 通配符，必须明确指定与请求Origin完全一致的域名。这就像门禁系统只认登记过的身份证，临时身份证（*）不好使。
解决方案：

• 动态匹配：后端根据请求头的 Origin 动态设置响应头，例如Node.js代码： res.setHeader('Access-Control-Allow-Origin', req.headers.origin); res.setHeader('Access-Control-Allow-Credentials', 'true');
• 白名单过滤：维护允许的域名列表，校验Origin是否在列表内，避免直接返回请求Origin导致安全风险。

三、Preflight请求失败：OPTIONS方法的"委屈"

错误现场：复杂请求（如PUT、DELETE或带自定义头）被拦截，控制台显示 Preflight response is not successful。此时Network面板会多出一个状态码为404/403的OPTIONS请求。
本质原因：浏览器对"复杂请求"会先发预检请求（OPTIONS方法），探测服务器是否允许实际请求。若服务器未处理OPTIONS请求，或返回的头信息不满足要求，真实请求就会被扼杀在摇篮里。
解决方案：

• 允许OPTIONS方法：后端需显式处理OPTIONS请求，返回204状态码（无内容）。
• 完整配置头信息： Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type, Authorization Access-Control-Max-Age: 86400 # 预检结果缓存24小时

四、凭据问题：带Cookie的请求为何被拒？

错误现场：前端设置了 withCredentials: true，后端也配置了
Access-Control-Allow-Credentials: true，却依然报错 The value of the '
Access-Control-Allow-Credentials' header in the response is '' which must be 'true'。
本质原因：服务器未正确返回
Access-Control-Allow-Credentials: true，或与
Access-Control-Allow-Origin: * 同时使用（这两个配置是死对头，不能共存）。
解决方案：

• 前后端配合：前端XMLHttpRequest/fetch设置 withCredentials: true，后端确保 Access-Control-Allow-Credentials: true，且 Access-Control-Allow-Origin 为具体域名。
• 排查代理层：若使用Nginx/APISIX等网关，需确保代理层未剥离Credentials相关头信息。

五、自定义头不被允许：服务器的"小心眼"

错误现场：请求带自定义头（如 X-User-Token）时，报错 Request header field X-User-Token is not allowed by
Access-Control-Allow-Headers。
本质原因：服务器的
Access-Control-Allow-Headers 未包含该自定义头，浏览器认为这是"非法夹带"。
解决方案：

• 显式声明：在 Access-Control-Allow-Headers 中添加自定义头，例如：
  Access-Control-Allow-Headers: Content-Type, X-User-Token
• 避免过度自定义：非必要时优先使用标准头（如Authorization），减少跨域配置复杂度。

终极解决方案：Nginx反向代理一招制敌

与其在每个后端服务中重复配置CORS，不如用Nginx反向代理"一劳永逸"。通过将前端请求转发到后端，让浏览器认为是同源请求，从根本上绕过CORS限制。

核心配置示例：

server {
    listen 80;
    server_name frontend.com;

    # 前端静态资源
    location / {
        root /usr/share/nginx/html;
    }

    # 反向代理后端API
    location /api/ {
        proxy_pass https://backend.com/api/;
        # 关键CORS配置
        add_header Access-Control-Allow-Origin $http_origin;
        add_header Access-Control-Allow-Credentials 'true';
        add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
        add_header Access-Control-Allow-Headers 'Content-Type, Authorization, X-User-Token';
        
        # 处理预检请求
        if ($request_method = 'OPTIONS') {
            return 204;
        }
    }
}

优势：

1. 集中管理：所有CORS配置在Nginx层统一维护，避免后端服务重复劳动。
2. 性能优化：Nginx处理OPTIONS请求速度远快于应用服务器。
3. 兼容性强：支持各种后端语言（Java/Go/Python），无需修改业务代码。

避坑小贴士

1. 开发环境：使用webpack-dev-server的proxy配置，本地开发时模拟Nginx反向代理。
2. 生产环境：避免 Access-Control-Allow-Origin: *，严格校验Origin白名单。
3. 调试技巧：Network面板查看OPTIONS请求的响应头，对比 Access-Control-Allow-* 系列配置是否完整。

CORS错误虽顽固，但只要掌握这5种场景和Nginx方案，就能让跨域请求像"老司机"一样畅通无阻。下次遇到红字警告，不妨先检查响应头——答案往往就藏在那几行配置里。