Nginx反向代理是最稳妥常用的跨域方案，通过将前端请求代理至同源路径（如/api/）并转发到真实后端，绕过浏览器同源策略；需正确配置proxy_pass斜杠、透传关键请求头、补全CORS响应头，并处理OPTIONS预检。
直接用 Nginx 做反向代理，把前端请求“伪装”成同源请求，是最稳妥、最常用的跨域解决方案。它不依赖前端代码修改，也不需要后端开启 CORS 头（当然后端配了更好），关键是把浏览器的跨域校验从“前端→后端接口”变成“前端→Nginx→后端接口”，绕过浏览器的同源策略限制。
明确代理目标和路径规则
先理清你要代理什么：比如前端运行在 http://localhost:3000，调用的是后端 API https://api.example.com/v1/users。浏览器会因协议、域名、端口不同直接拦截。解决办法是让前端请求发到本地同源地址（如 /api/v1/users），再由 Nginx 把所有以 /api/ 开头的请求，转发到真实后端。
- 前端请求地址从
https://api.example.com/v1/users改为/api/v1/users（相对路径） - Nginx 配置中用
location /api/拦截，注意末尾斜杠——它决定是否自动剥离前缀 - 若用
proxy_pass https://api.example.com/;（结尾带/），则/api/v1/users会被重写为/v1/users转发；若写成proxy_pass https://api.example.com;（无尾部/），则完整路径/api/v1/users会原样转发过去，后端可能 404
基础代理配置（含关键头处理）
以下是最小可用的 Nginx server 块示例，适用于开发或简单上线场景：
server {
listen 3000;
server_name localhost;
<pre class="brush:php;toolbar:false;">location / {
root /path/to/your/frontend/dist;
try_files $uri $uri/ /index.html;
}
location /api/ {
proxy_pass https://api.example.com/;
proxy_set_header Host api.example.com;
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;
# 关键：允许浏览器携带 Cookie 和认证头
proxy_cookie_path / "/; SameSite=None; Secure";
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
add_header 'Access-Control-Allow-Credentials' 'true';
}}
立即学习“前端免费学习笔记（深入）”；
-
proxy_set_header Host确保后端收到正确的 Host，尤其当后端做域名路由时必不可少 -
add_header Access-Control-Allow-Origin '*'是为预检（OPTIONS）和实际请求补全 CORS 响应头；若需携带 Cookie，必须指定具体域名（不能用*），同时后端也要一致 -
proxy_cookie_path解决跨域下 Cookie 无法写入的问题（特别是现代浏览器对SameSite的严格要求）
处理预检请求（OPTIONS）
浏览器对非简单请求（如带 Authorization、Content-Type 为 application/json）会先发一个 OPTIONS 请求。如果后端没处理，Nginx 需主动响应，避免请求卡住：
- 在
location /api/内添加：if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin '*'; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE'; add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization'; add_header Access-Control-Allow-Credentials 'true'; add_header Access-Control-Max-Age 86400; add_header Content-Length 0; add_header Content-Type 'text/plain; charset=utf-8'; return 204; } - 更推荐方式：让后端正确响应 OPTIONS，Nginx 不干预；若后端不可控，再用上述 if 判断兜底
常见问题排查要点
配置完仍报错？优先检查这几项：
- 前端是否真正发到了
/api/xxx？打开浏览器 Network 面板确认请求 URL 和 Referer - Nginx 配置是否重载？执行
sudo nginx -t && sudo systemctl reload nginx或nginx -s reload - 是否混淆了
proxy_pass尾部斜杠？这是 80% 的 404 根源 - 后端返回的响应头里是否有冲突的 CORS 头？比如后端已设
Access-Control-Allow-Origin: https://myapp.com，而 Nginx 又加了*，会导致浏览器拒绝（多个 Origin 值非法） - HTTPS 场景下，确保
proxy_pass使用https://，且 Nginx 已安装 ca 证书或配置proxy_ssl_verify off;（仅测试环境）
不复杂但容易忽略——核心就三点：路径重写别出错、请求头透传要到位、CORS 响应头补全要及时。只要代理链路清晰，绝大多数跨域问题都能在 Nginx 层干净解决。
