什么是服务器端跨域？服务器端跨域怎么解决？

服务器端跨域，说白了就是由服务端主动放行或转发，让浏览器的同源策略不再拦截跨域请求，解决思路就两条：要么服务器允许跨域，要么服务器帮忙转达。

很多开发者在前后端联调时被浏览器控制台的红叉折磨过,第一反应总是去问前端同事“你帮我加个代理”，但真正负责任的做法，是把跨域问题当作一个架构层面的协作问题来对待，而不是让某一端背锅，这篇文章就从服务器端的视角，把跨域这件事拆开揉碎聊清楚。

服务器端跨域和前端跨域有什么区别

要弄清服务器端跨域,得先知道浏览器为什么拦你，所谓同源策略，是浏览器内置的一道安全边界，它规定页面里发出去的请求，协议、域名、端口只要有一项跟当前页面不一致，就会被判定为跨域，前端控制台报的“CORS error”，本质是浏览器收到响应后，发现服务器没给够放行凭证，于是直接把响应吞掉了。

前端能做的跨域手段非常有限,早年大家用JSONP绕过限制，往页面里塞一个<script>标签，利用它不受同源策略约束的特性，把数据包装成JS回调拿回来，但这招有个硬伤：只支持GET请求，而且存在安全隐患，所以到了今天，JSONP在实际生产环境里已经被边缘化。

服务器端跨域就不一样了,它站在请求链路的源头或者中转站上，直接修改或者转发请求，让浏览器觉得“没跨域”，或者明确告诉浏览器“这个响应允许被读取”，行业共识认为，服务器端跨域才是真正稳定、可维护、能覆盖复杂业务的解决方案，前端处理跨域是打补丁，服务器端处理跨域是治病根。

同源策略到底在拦什么

这里有个认知误区必须纠正：浏览器并不是拦住了请求发出，而是拦住了响应被读取，请求其实已经发到服务器了，服务器也处理完返回了数据，但浏览器一看响应头里没有Access-Control-Allow-Origin，或者这个值跟当前页面域名对不上，就翻脸不认账，在控制台报错并把响应丢弃。

所以服务器端跨域的第一层逻辑,就是往响应里塞正确的响应头，明白了这一点，你去排查问题时的视角就不一样了，你不会再盯着前端代码问“为什么报错”，而是直接抓包看响应头，这效率完全两码事。

为什么纯前端解决不了跨域问题

• 改不了响应头,前端脚本无权操作浏览器收到的HTTP响应头，这是浏览器安全模型划定的红线。
• 改不了请求方向,前端发出去的请求目标地址是写死的，想改域名只能走代理，而代理本身就需要服务器端配合。
• JSONP能力残缺,只能GET，没法自定义错误处理，跨域携带Cookie也很麻烦。

说白了,跨域问题的钥匙一直攥在服务器端手里，前端顶多试试水，真正能锁死或者解开这个结的，只有后端和运维。

服务器端解决跨域的三种主流方案

业界最常见的做法有三种,适用场景各不相同，你按项目实际情况挑，不用全都上。

CORS配置：最直接的放行方案

CORS,全称跨域资源共享，是W3C制定的标准机制，服务器端要做的事非常简单，在HTTP响应头里增加几个字段，

• Access-Control-Allow-Origin：允许哪个源访问，可以指定域名，也可以写（但携带Cookie时不能写通配符）。
• Access-Control-Allow-Methods：允许哪些HTTP方法，比如GET、POST、PUT、DELETE。
• Access-Control-Allow-Headers：允许哪些自定义请求头。
• Access-Control-Max-Age：预检请求的有效期，单位是秒。

具体操作路径：如果你用Spring Boot框架，在Controller类上直接挂一个@CrossOrigin注解就能搞定单接口放行，如果是全局配置，实现WebMvcConfigurer接口，重写addCorsMappings方法，就能统一配置整个项目的跨域规则。

CORS方案最大的优点是零侵入、配置简单，适合前后端分离的站点应用，但它的缺点也明显：每次请求都要带一堆响应头，预检请求会额外消耗服务器资源，并发量大的时候响应时长会肉眼可见地增加。

反向代理：把跨域变成同域

反向代理的原理是榨干同源策略的漏洞边界浏览器只认页面自己的源，那么让前端页面和API接口跑在同一个域名下，自然就不存在跨域了。

具体操作路径：以Nginx为例，在nginx.conf里写一段代理规则：

server {
    listen 80;
    server_name www.example.com;
    location /api/ {
        proxy_pass http://192.168.1.10:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

前端页面从www.example.com加载，请求接口时也只往www.example.com/api发，Nginx收到后把请求转发到内网的真实服务上，浏览器全程感知不到后端的存在，跨域问题直接消失。

这个方案的优先适用场景是传统多页应用、前后端部署在同一个Web服务器后面的项目，跟CORS相比，它不需要后端改任何代码，上线时不用动业务逻辑，省心不少。

网关统一处理：微服务场景的标配

微服务架构里,前端会请求十几个不同域名的服务，一个个配CORS容易漏配，而且要改配置就得重启服务，业内专家指出，在网关层统一处理跨域是大型系统的默认姿势。

以Spring Cloud Gateway为例，网关里配置一个CORS全局过滤器，把允许的源、方法、请求头统一管理起来，所有微服务接口都走网关转发，浏览器只跟网关打交道，跨域规则只在网关这一层维护，这跟CORS配置在业务层的区别是，配置和业务彻底解耦，上线流程更安全。

服务器端跨域配置Nginx还是CORS怎么选

这个话题在技术社区争论了很久,你问我选哪个，我会说看场景，而且这两个不冲突。

按项目架构选

• 单体应用+前端页面一起部署：直接上Nginx反向代理，让前后端在同一个域名下，最省事。
• 前后端彻底分离+接口服务对外暴露：用CORS，把接口开放给自己可控的域名。
• 微服务+多团队协作：不用犹豫，网关统一处理，规则收敛在一处。

按成本和时间选

如果想尽快上线,Nginx方案更快，运维改一段配置重启完事，如果团队后端能力比较强，CORS能给你更大的灵活性，尤其是将来接口可能要开放给第三方开发者的时候，这两个方案都是零软件成本，差的只是人力工时，国内云厂商的基础负载均衡服务大概每月几十到几百不等，Nginx自建的话这部分也能省下来，但需要有人懂运维，海外服务器跟国内服务器的差异不会体现跨域处理上，但响应延迟和备案问题会切实影响你选哪种方案，比如国内服务器没备案时，配置Nginx代理到其它域名也要更谨慎。

多数情况下,我见过的生产项目都是两种方案叠加使用：Nginx负责兜底转发，CORS负责精细化权限控制，并不存在非此即彼的抉择。

服务器端跨域处理实操步骤

理论说一堆,不如动手踩一遍，这里给出一套可验证的排查流程。

排查CORS配置的常见问题

第一步,打开浏览器开发者工具的Network面板，找到那个报错的请求，在Response Headers里找有没有Access-Control-Allow-Origin头，如果压根没有，那后端配置没生效。

第二步,确认Access-Control-Allow-Origin的值，如果你页面跑在https://a.example.com，响应头里写的是https://b.example.com，照样拦。

第三步,看请求方法，如果是PUT、DELETE这种复杂请求，浏览器会先发一个请求方法为OPTIONS的预检请求，你得确认后端对OPTIONS请求也正确返回了响应头，否则正式请求永远发不出去。

Nginx代理配置的坑

最典型的一个坑是proxy_pass后面的路径问题。proxy_pass http://192.168.1.10:8080;不带斜杠和带上斜杠，转出去的路径完全不同，这个细节能写一篇专题，你先记住这个检查点。

另一个坑是WebSocket长连接，配置普通HTTP转发没问题，但WebSocket需要额外加Upgrade和Connection头，否则实时通信直接断连。

location /ws/ {
    proxy_pass http://192.168.1.10:8080/ws/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

服务器端跨域问题怎么解决才算根治

如果上面排查都没问题但依然有异常,那大概率是Cookie的SameSite属性在捣乱，Chrome浏览器近几年把未显式设置SameSite的Cookie默认视为Lax，限制第三方上下文携带，跨域请求里Cookie经常悄悄丢失，这种场景下，你可以把Cookie的SameSite设为None并配合Secure属性，或者在网关层做会话令牌透传，彻底绕开浏览器Cookie策略。

根治的标准是三个都能回答“是”：

• 不带Cookie的普通请求能通？
• 带Cookie的业务请求能通？
• 暴露的自定义响应头前端能读到？

三条全部满足,跨域才算真正闭环。

Q&A：服务器端跨域相关常见问题

服务器端跨域配置后前端还需要做什么改动吗？

需要改动的地方很少,但别完全不管，如果开发环境用了Webpack Dev Server的proxy代理，上线后要记得改成读后端配置文件里的直连地址或者经网关转发的地址，前端代码本身基本没有逻辑要动，顶多调整一下withCredentials标志位，让请求自动带上Cookie凭证，前提是后端CORS配置里已经允许了凭证携带。

Nginx跨域配置和CORS会冲突吗？

不会冲突,但会存在覆盖关系，如果Nginx先转发，后端又返回了CORS头，那么浏览器看到的是后端返回的最终响应头，Nginx层面也可以在转发时add_header追加响应头，但要注意如果用了proxy_pass，add_header只有在location块内定义才会生效，行业共识是网关或者代理层管来源白名单，业务层管接口级权限，两者各司其职，互不干扰。

服务器端跨域处理一般需要多少预算？

纯粹从软件方案来说,Nginx和开源网关比如Kong、APISIX都是零授权费用，花的是部署运维的时间，如果在云上买API网关服务，不同地域的云厂商计费规则有差异，国内节点跟海外节点的价格也不同，多数云厂商按调用量或套餐收费，入门级套餐每年几百元左右，如果团队里缺专业运维，请外包或者咨询顾问来配置，按目前市场行情一次基础跨域改造大概在几千元区间，跨域处理本身不算贵，贵的是那些因为配置不当导致的安全漏洞和线上故障。