在前后端分离架构的开发过程中，跨源资源共享（CORS）限制是经常遇到的基础网络安全策略之一。当浏览器拦截到跨域请求时，通常会抛出明确的错误提示，提醒开发者当前资源未配置正确的 Access-Control-Allow-Origin 响应头。

为了快速通过本地调试，部分开发者会直接在后端代码中添加全局允许跨域的注解，例如允许所有来源（origins = "*"）。这种做法虽然直接，但如果在生产环境中依然保留，将会带来严重的安全隐患，使得核心业务 API 暴露在跨站点请求伪造（CSRF）等风险之中。本文将分析同源策略的机制，并探讨如何通过 Nginx 代理配置来安全、规范地处理跨域问题。

OPTIONS 预检请求的机制分析

当我们在前端发送一个普通的 POST 请求时，经常会在浏览器的网络控制台中观察到一个额外的 OPTIONS 请求，这便是 CORS 机制中的预检请求（Preflight Request）。

现代浏览器在处理跨域交互时有着严格的安全规范。当请求包含自定义 Header（例如携带身份验证凭证的 Authorization 头），或使用了 application/json 等非简单请求的内容类型时，浏览器不会直接发送真实数据，而是预先发出一个 OPTIONS 请求，向服务器确认是否允许该跨站交互。

服务器需要在响应中明确返回允许的请求方法、Header 字段等信息。如果后端的响应不符合规范，浏览器将中断真正的 POST 请求并在控制台报错。虽然这种机制能够有效保障通信安全，但在高频的交互场景下，额外的网络往返（RTT）会带来不容忽视的延迟。

引入 Nginx 反向代理实现同源化

与其在应用代码层面维护复杂的 CORS 响应头，通过基础设施层来统一处理跨域往往是更稳妥的架构设计。橙星云技术团队在实际部署中，通常会避免在后端业务代码中硬编码跨域配置，而是将请求路由的管理权限交由最外层的 Nginx 反向代理服务器。

通过合理的 Nginx 代理配置，我们在物理拓扑上将前端静态资源与后端 API 统一到相同的域名与端口之下，从而在浏览器层面实现了“同源”。

典型的 Nginx 配置参考如下：

“`nginx
server {
listen 80;
server_name www.psy.com;

静态资源分发

location / {
root /var/www/psy-frontend;
index index.html;
}

反向代理后端 API

location /api/ {

将前端发往 www.psy.com/api/… 的请求代理至后端服务

proxy_pass http://192.168.1.100:8080/;

传递客户端真实信息

proxysetheader Host $host;
proxysetheader X-Real-IP $remote_addr;
}
}
“`

在这种反向代理架构下，前端工程中所有的接口请求全部可以改写为类似 /api/login 的相对路径。浏览器在解析这些相对路径时，会判定其与当前宿主网页处于相同的源域（Same-Origin）。由于完全符合同源策略，浏览器不再触发 OPTIONS 预检请求，前端的网络开销得以降低。

通过将权限校验和跨域处理上移至 Nginx，后端业务代码不再需要关注复杂的网络边界约束，能够更专注于核心业务逻辑的实现。这种在接入层抹平跨域差异的做法，也为内部 API 提供了一道基础的网络隔离屏障。