CORS 跨域报错怎么解决？Origin、Credentials 和预检请求排查指南

前后端联调时，CORS 报错几乎人人都见过。浏览器控制台一大段红字，看起来像前端请求失败，实际通常是后端响应头没有按浏览器规则配置。

这篇讲 CORS 常见报错怎么排查，并配合 CORS Header 生成器 生成可用配置。

CORS 是浏览器规则

CORS 全称是 Cross-Origin Resource Sharing。它限制的是浏览器里的跨源请求。

“跨源”指协议、域名、端口任意一个不同：

• https://a.com 到 https://api.a.com 是跨源。
• http://localhost:3000 到 http://localhost:8080 是跨源。
• http://example.com 到 https://example.com 也是跨源。

如果你用 Postman 能请求成功，但浏览器失败，通常就是 CORS。

最重要的响应头

最常见的是：

Access-Control-Allow-Origin: https://example.com

它告诉浏览器：这个 Origin 可以读取响应。

开发环境为了省事，经常写：

Access-Control-Allow-Origin: *

但如果请求带 cookie 或凭证，就不能用 *。

Credentials 和星号不能混用

如果前端请求带：

fetch(url, { credentials: "include" })

后端需要：

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.com

注意 Allow-Origin 必须是明确 Origin，不能是 *。

这也是很多登录接口跨域失败的原因。

预检请求是什么

当请求方法或 Header 不够简单时，浏览器会先发一个 OPTIONS 请求，也叫 preflight。

例如带自定义 Header：

Authorization: Bearer xxx

后端需要正确响应：

Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type

如果 OPTIONS 没处理，真正的 POST 请求根本不会发出去。

常见排查步骤

1. 看控制台报错里的 Origin。
2. 看 Network 里是否有 OPTIONS 请求。
3. 确认 OPTIONS 响应状态码是 2xx 或 204。
4. 确认 Allow-Origin 是否匹配当前 Origin。
5. 如果带 cookie，确认 Allow-Credentials。
6. 如果带 Authorization，确认 Allow-Headers。

你可以先用 CORS Header 生成器 配好响应头，再复制到 Nginx、Express 或后端框架里。

不要盲目全放开

为了快速解决问题，有人会把所有 Origin、Methods、Headers 都放开。开发环境可以临时这样做，生产环境不建议。

生产环境至少应该：

• 只允许可信域名。
• 只允许需要的方法。
• 只允许需要的 Header。
• 谨慎开启 credentials。
• 对管理后台接口更严格。

CORS 不是完整安全方案，但配置过宽会扩大风险面。

总结

CORS 报错时，先分清是否是浏览器跨源限制，再看 Origin、Credentials、OPTIONS、Methods、Headers。

需要生成配置时，可以使用 CORS Header 生成器，再结合 Network 面板验证浏览器实际收到的响应头。