若服务端设Access-Control-Allow-Origin: *仍报跨域错误，主因是携带凭证时禁用通配符、预检请求失败、响应头重复、源为null/file://或CDN覆盖头。
如果您在服务端设置了 Access-Control-Allow-Origin: *，但浏览器仍报跨域错误，则问题并非出在该响应头缺失，而是存在其他 CORS 规范强制约束的条件未满足。以下是解决此问题的步骤：
一、检查是否携带凭证（Credentials）
当 JavaScript 发起请求时设置了 withCredentials = true（例如发送 Cookie 或 Authorization 头），浏览器将拒绝接受 Access-Control-Allow-Origin: *，而要求服务端返回与请求源完全一致的具体源地址。
1、确认前端发起请求时是否包含 credentials: 'include' 或调用 xhr.withCredentials = true。
2、若确实需要携带凭证，请将服务端响应头改为精确匹配，例如：Access-Control-Allow-Origin: https://app.example.com。
3、同时确保服务端响应中包含：Access-Control-Allow-Credentials: true。
二、验证预检请求（OPTIONS）是否通过
对于非简单请求（如使用 PUT、DELETE 方法，或携带自定义 Header 如 X-Token、Content-Type: application/json），浏览器会在正式请求前自动发送一个 OPTIONS 预检请求；若该请求未被正确响应，整个请求链将被中断。
1、使用浏览器开发者工具的 Network 面板，筛选出类型为 OPTIONS 的请求，观察其响应状态码是否为 200 或 204。
2、检查该 OPTIONS 响应中是否包含：Access-Control-Allow-Methods（值需包含实际使用的 HTTP 方法）。
3、检查该 OPTIONS 响应中是否包含：Access-Control-Allow-Headers（值需覆盖所有自定义请求头，如 X-Token、Authorization）。
三、排查响应头重复或冲突
服务器可能因中间件、反向代理（如 Nginx、CDN）或框架默认行为，多次设置 Access-Control-Allow-Origin，导致响应中出现多个同名头；部分浏览器会直接拒绝此类非法响应。
1、在浏览器 Network 面板中查看响应原始 Headers，搜索是否存在多个 Access-Control-Allow-Origin 字段。
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
2、检查 Nginx 配置中是否重复添加了 add_header 指令，例如在 server 块和 location 块中均设置了相同头。
3、检查 Spring Boot 等框架是否同时启用了全局 CORS 配置与 @CrossOrigin 注解，造成叠加输出。
四、确认请求源为 null 或 file:// 协议
当页面通过 file:// 协议打开，或由本地 HTML 文件直接双击运行时，浏览器将把 origin 解析为 null；而规范禁止 Access-Control-Allow-Origin: * 匹配 null 源。
1、在浏览器控制台执行 console.log(window.location.origin)，确认当前页面 origin 是否为 null 或 file://。
2、若确为本地文件协议，请改用本地开发服务器（如 http-server、live-server、Vite dev server）启动页面。
3、避免在生产环境外使用 --disable-web-security 启动浏览器，该方式已不被现代 Chrome 版本支持且存在严重安全风险。
五、审查 CDN 或边缘节点是否覆盖响应头
若请求经过 CDN（如阿里云 DCDN、Cloudflare）、API 网关或边缘安全加速服务，这些中间层可能未透传或主动重写了服务端返回的 CORS 响应头。
1、直接绕过 CDN 访问源站 IP 或域名，验证是否仍报错；若源站正常，则问题出在中间层配置。
2、登录 CDN 控制台，检查“跨域资源共享（CORS）”功能是否启用，并确认其配置的 Access-Control-Allow-Origin 值是否覆盖或冲突于源站设置。
3、检查 CDN 是否启用了“缓存 OPTIONS 请求”，若缓存了失败的预检响应，会导致后续所有跨域请求持续失败。
