直接用Nginx反向代理（推荐）或添加CORS响应头，可不改前后端代码彻底解决跨域问题；前者通过代理使请求同源，后者需正确处理OPTIONS预检并避免Credentials与*冲突。
直接用 Nginx 配置反向代理 + 添加 CORS 响应头，就能在不改前后端代码的前提下彻底解决跨域问题。核心不是“放行跨域”，而是让前端请求看起来像同源——要么把后端接口代理到前端域名下（推荐），要么明确告诉浏览器哪些源可以跨域访问（需谨慎）。
方案一：反向代理（开发/生产都适用，最推荐）
让前端访问 /api/xxx，Nginx 自动转发到真实后端地址（如 http://127.0.0.1:8080/xxx），浏览器全程只看到一个域名，根本不会触发跨域检查。
- 编辑
/etc/nginx/conf.d/default.conf或主配置中的server块 - 添加如下 location 规则（注意末尾斜杠和 rewrite）：
location /api/ {
proxy_pass http://127.0.0.1:8080/; # 注意结尾的 /，它会自动剥离 /api 前缀
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}前端发请求到 https://yourdomain.com/api/users，Nginx 会转发为 http://127.0.0.1:8080/users。路径干净，无需后端适配，也避免了 CORS 头的兼容性风险。
方案二：显式添加 CORS 响应头（适合调试或简单场景）
当无法做代理（比如后端已暴露公网、或需保留原始域名调用）时，可在 Nginx 中统一注入跨域头。但必须处理 OPTIONS 预检请求，否则 POST/带认证的请求仍会失败。
- 在对应
location块中加入以下配置：
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' 'Content-Type, Authorization, X-Requested-With' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
<p>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;
}注意：Access-Control-Allow-Origin 不要写 * 同时又设 Access-Control-Allow-Credentials true，这会导致浏览器拒绝响应。若需带 Cookie 或认证头，必须指定确切域名。
关键细节与避坑提醒
-
always 参数很重要：Nginx 默认只给 2xx/3xx 响应加 header，加上
always才能让 204（OPTIONS 返回）也携带 CORS 头 -
proxy_pass 尾部斜杠决定路径重写逻辑：
proxy_pass http://backend/;会去掉匹配前缀；proxy_pass http://backend;（无斜杠）则原样拼接，容易出错 -
重启前务必测试配置：运行
sudo nginx -t，提示success再执行sudo systemctl reload nginx -
前端请求地址要匹配 Nginx 路由规则：比如你配了
location /api/，前端就该调/api/login，而不是http://api.xxx.com/login
不需要改一行后端代码，也不依赖开发服务器代理，一套配置即可覆盖开发、测试、生产环境。只要 Nginx 在请求链路上，它就是最稳定、最可控的跨域出口。
