Nginx 反向代理解决跨域

跨域是浏览器的同源策略在拦，代理让请求从「浏览器发往另一个域」变成「服务器发往另一个域」，浏览器那一关根本没走到。

为什么代理能解决跨域

同源策略只在浏览器里执行：页面在 https://web.example.com，请求 https://api.example.com 就是跨域，响应头没有 Access-Control-Allow-Origin 就被拦。而 Nginx 转发这条请求时，发起方是服务器进程，不存在同源概念。

于是让前端只请求同域路径 /api/xxx，Nginx 在服务端转给真实后端，浏览器看到的始终是同一个域。

比 CORS 头更彻底的地方：不需要后端配合加响应头，也不需要处理预检（OPTIONS），老接口、第三方接口都能代理。

配置

server {
    # ... 其他配置 ...

    # 前端静态资源 / history 路由兜底
    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass https://api.upay7777.com/api/;
    }
    location /adm/ {
        proxy_pass https://api.upay7777.com/adm/;
    }
}

proxy_pass 结尾那个斜杠，是全篇最容易错的地方

proxy_pass 后面有没有 URI 部分，决定了路径怎么拼：

写法	请求 /api/user 实际转发到
proxy_pass https://host;	https://host/api/user — 原样带过去
proxy_pass https://host/;	https://host/user — 把 location 匹配到的 /api/ 替换成 /
proxy_pass https://host/api/;	https://host/api/user — 替换成 /api/，结果与第一种相同但含义不同

口诀：proxy_pass 一旦带了路径，location 匹配到的前缀就被它替换。所以 location /api/ 配 proxy_pass https://host/ 会把 /api 吃掉，后端收到 /user 而不是 /api/user，表现就是 404。

第二种写法（转发到根）在 location /api/ 下更常见，因为它能把前端前缀整段剥掉：

location /api/ {
    proxy_pass https://api.upay7777.com/;   # /api/user -> /user
}

补上这几个头，否则后端会拿到错的来源

默认情况下 Nginx 转发时 Host 头会变成上游域名，后端拿不到客户端真实 IP，也无法判断来源。一组通用配置：

location /api/ {
    proxy_pass https://api.upay7777.com/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;
}

X-Forwarded-For 会累加，后端取第一个非信任 IP 才是客户端真实地址。Host 传 而不是写死上游域名，是为了让后端生成的重定向、Cookie domain 仍指向用户访问的域名。