Nginx反向代理是生产环境解决CORS跨域的必选项，核心是让前端请求“看起来同源”，再由Nginx统一注入合规响应头，无需修改前后端代码，也不依赖开发代理，真正适配上线场景。
用 Nginx 解决生产环境跨域，核心是让前端请求“看起来同源”，再由 Nginx 统一注入合规的 CORS 响应头——不改前后端代码，也不依赖开发服务器代理，真正适配上线场景。
为什么生产环境必须用 Nginx 反向代理
开发时加 devServer.proxy 或后端硬写 Access-Control-Allow-Origin: * 很快，但上线就失效或不安全：
- devServer 代理只在本地 npm run serve 有效，构建部署后请求直连后端，跨域照旧；
- 后端写死 Access-Control-Allow-Origin: * 无法携带 Cookie（credentials: true 会报错），而登录态接口必须传凭证；
- 多个前端域名（如 www.example.com、admin.example.com、app.example.com）共用一套 API，后端静态配置难以灵活支持；
- 对接第三方服务（如 Nexus、SaaS 接口、遗留 Java 系统）时，你根本没法改对方响应头。
Nginx 在中间做一层透明转发，把 /api/xxx 请求转给内部后端，再补上精确控制的 CORS 头，前端完全无感，且所有逻辑集中在网关层，便于统一治理和审计。
生产级 Nginx 配置要点
以下配置适用于正式环境，强调安全性与兼容性，已剔除测试用的 * 通配符：
立即学习“Java免费学习笔记（深入）”；
- server_name 必须匹配前端域名：比如前端访问 https://www.example.com，Nginx 的 server_name 就得设为 www.example.com（或带通配符的 *.example.com），确保浏览器认为请求是同源的；
- Access-Control-Allow-Origin 设为具体域名：不能用 *，要写成 https://www.example.com 或动态反射（需配合 map 指令校验白名单）；
- 带 Cookie 的接口必须加两项：add_header Access-Control-Allow-Credentials "true"; 并确保 proxy_pass 后端地址协议一致（如 http://127.0.0.1:8000），同时前端 fetch 要配 credentials: 'include'；
- 预检请求（OPTIONS）必须显式处理：否则浏览器发完 OPTIONS 就卡住。加 if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "https://www.example.com"; add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"; add_header Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With"; add_header Access-Control-Allow-Credentials "true"; add_header Access-Control-Max-Age "86400"; return 204; }；
- proxy_set_header Host $host 和 proxy_set_header X-Real-IP $remote_addr 别漏掉，保证后端能正确识别来源。
一个可直接上线的配置示例
假设前端域名为 https://app.example.com，后端服务运行在 http://10.0.1.5:8000，所有 API 路径以 /api 开头：
server {
listen 443 ssl;
server_name app.example.com;
<pre class='brush:php;toolbar:false;'>ssl_certificate /etc/nginx/ssl/app.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/app.example.com.key;
location /api {
proxy_pass http://10.0.1.5:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 允许指定前端域名
add_header Access-Control-Allow-Origin "https://app.example.com";
add_header Access-Control-Allow-Credentials "true";
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
add_header Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With";
# 预检请求单独处理
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin "https://app.example.com";
add_header Access-Control-Allow-Credentials "true";
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
add_header Access-Control-Allow-Headers "Authorization, Content-Type, X-Requested-With";
add_header Access-Control-Max-Age "86400";
return 204;
}
}
location / {
root /var/www/frontend;
try_files $uri $uri/ /index.html;
}}
注意：reload nginx 前务必用 nginx -t 检查语法；若用 HTTPS，证书路径需真实存在；/api 路径要和前端 axios.defaults.baseURL 保持一致。
常见踩坑提醒
配置完仍报跨域？大概率是这几个细节没对上：
- 前端请求 URL 写的是 http://nginx-ip:port/api，但 Nginx 的 server_name 是 app.example.com —— 浏览器发现 origin 不匹配，直接拦截；
- 后端返回了 Access-Control-Allow-Origin 头（比如 Spring Boot 自动加的），和 Nginx 加的冲突，导致响应头出现两个同名字段，浏览器拒绝；
- 没处理 OPTIONS 请求，或处理时漏了 Access-Control-Allow-Credentials，导致预检失败；
- proxy_pass 地址末尾有没有 / 影响路径重写：proxy_pass http://backend/ 会剥离 /api 前缀；proxy_pass http://backend 不会，需确认后端是否期望接收 /api 路径。
