CORS跨域与Nginx反向代理跨域优劣对比

yiliang 发布于2019-07-25 14:26 / 2906人阅读

摘要：最近写了一些关于前后端分离项目之后，跨域相关方案的基本原理和常见误区的帖子，主要包括和反向代理。反向代理此时后端相当于不跨域，和正常请求一致，无需额外配置。

最近写了一些关于前后端分离项目之后，跨域相关方案的基本原理和常见误区的帖子，主要包括CORS和Nginx反向代理。这两种方案项目中都有在用，各有优缺，关于具体使用哪种方案，大家的观点也不大一致，本文主要就此展开一下，从前后端及服务器配置、安全性、移植灵活性、扩展性等方面详细对比一下两种方案的优缺，以便于后期在方案选型上对大家有所帮助。

前端配置

CORS方案：跨域时部分浏览器默认不携带cookie，因此为了携带cookie需要设置一下xmlhttprequest的withCrendetails属性，使用vue-resouce时设置如下

Vue.http.options.credentials = true

用axios时，可以在拦截器中设置如下

axios.interceptors.request.use((config) => {
    config.withCredentials = true
    return config
}, (error) => {
    return Promise.reject(error)
})

使用原生XMLHttpRequest对象时如下，

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

如果不需要传递cookie，最好置成false，避免不嗯浏览器默认允许cookie的携带。
Nginx反向代理：此时前端相当于不跨域，和正常请求一致，无需额外配置。

后端配置

CORS方案：后端需要包装ACA系列header，

"Access-Control-Allow-Origin" "*";
"Access-Control-Allow-Credentials" "true"; 
"Access-Control-Allow-Headers" "X-Requested-With";

除此以外无需额外配置。
Nginx反向代理：此时后端相当于不跨域，和正常请求一致，无需额外配置。

服务器配置

CORS方案：无。
Nginx反向代理：该方案跨域工作都集中在nginx服务器上，配置如下

...
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Real-Port $remote_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
location /api {
   proxy_pass https://b.test.com; # 设置代理服务器的协议和地址
   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，针对request和response互相写入cookie
}       
...

原理移步nginx反向代理跨域基本配置与常见误区、nginx配置解析之客户端真实IP的传递

安全性

CORS方案：由于此时浏览器会默认添加origin属性，服务端可以直接查到请求来源，便于控制来源、屏蔽黑名单链接。同时服务端域名和端口会暴露出来。
Nginx反向代理：反向代理方案中没有默认的origin头部可以使用，但是可以通过X-Forward-For头部查看客户端及各级代理ip，也可以实现一定程度的回溯追踪和黑名单屏蔽。由于反向代理中，可以采用内网地址访问接口服务器，这样可以一定程度上保护接口服务器不暴露出来。

移植灵活性、扩展性

CORS方案：只需要在代码或者配置中心进行黑白名单配置即可，方便移植和扩展。
Nginx反向代理：不同环境服务域名可能不一致，因此nginx配置也各不相同，不便于移植。而对于扩展性，当存在新的项目需要访问接口服务器时，需要首先访问nginx中server指定的域名，再由server域名反向代理到接口服务器，比如

server { 
    listen       8443;
    server_name  a.test.com;    
    client_max_body_size            100m;
        
    ssl ...

    location /micro{
        proxy_pass   https://b.test.com;  #反向代理
        proxy_cookie_domain b.test.com a.test.com; #修改cookie
        add_header "Access-Control-Allow-Origin" "htps://c.test.com";
        add_header "Access-Control-Allow-Credentials" "true"; 
        add_header Access-Control-Allow-Headers X-Requested-With;
    }
}

这个时候跨域模型就变了，由单纯的a.test.com反向代理到b.test.com，变成了a.test.com反向代理到b.test.com以及c.test.comCORS到a.test.com再反向代理到b.test.comd的情况。这个有点绕，但仔细想一下就会明白。这无疑增加了后期的维护成本。

综合对比

综合以上，我们大致可以得到如下图标

Item	CORS	Nginx反向代理
代码配置--前端	credentials=true	无
代码配置--后台	setHeader:ACA-Origin、ACA-Method、ACA-Credentials等	无
服务器配置	无	Nginx配置
移植灵活性	高、无需额外配置	低、每套环境配置可能均不相同
安全性	来源可控、直接追溯	X-Forwarded-For追溯多级来源
新项目扩展	黑白名单控制	更新配置，跨域模型会产生变化

对比结论

综上呢，对于公共基础服务，由于涉及到对接的前端项目可能比较多，开发测试部署环境也比较多，整体上来讲我更倾向于推荐大家使用CORS方案。而对于一些对立性强的小项目，使用nginx则可以降低你的开发成本，快速发开快速上线。具体使用当然也要结合工作实际，按需使用吧。
此外对于Nginx反向代理方案使用时，推荐使用内部域名/ip作为接口服务器的入口，尽量不要暴露到外面，以免出现不必要的安全问题。

～本篇完～欢迎大家一起讨论～

GPU云服务器云服务器阿里云跨域与反向服务器代理 nginx服务器跨域 nginx反向代理 php代理代理跨域

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/40097.html

彻底弄懂跨域问题

摘要：用于告知浏览器可以将预先检查请求返回结果缓存的时间，在缓存有效期内，浏览器会使用缓存的预先检查结果判断是否发送跨域请求。跨域，老生常谈的问题简述作为一只前端菜鸟，跨域方面只懂得JSONP和CORS，并未曾深入了解。但随着春招越来越近，就算是菜鸟也要猛振翅膀。近几日仔细研究了跨域问题，写下这篇文章，希望对开发者们有所帮助。在读本文前，希望您对以下知识略有了解。浏览器同源策略 n...

rose 2019-07-25 14:36 评论0 收藏0
彻底弄懂跨域问题

摘要：浏览器同源策略我们为何要研究跨域问题因为浏览器的同源策略规定某域下的客户端在没明确授权的情况下，不能读写另一个域的资源。跨域，老生常谈的问题简述作为一只前端菜鸟，跨域方面只懂得JSONP和CORS，并未曾深入了解。但随着春招越来越近，就算是菜鸟也要猛振翅膀。近几日仔细研究了跨域问题，写下这篇文章，希望对开发者们有所帮助。在读本文前，希望您对以下知识略有了解。浏览器同源策略 n...

CoorChice 2019-08-23 14:41 评论0 收藏0
利用Nginx反向代理解决跨域问题

摘要：反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢标签： Nginx,跨域问题在之前的分享的跨域资源共享的文章中，有提到要注意跨域时，如果要发送Cookie，Access-Control-Allow-Origin就不能设为*，必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到...

EscapedDog 2019-08-23 14:13 评论0 收藏0
利用Nginx反向代理解决跨域问题

摘要：反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢标签： Nginx,跨域问题在之前的分享的跨域资源共享的文章中，有提到要注意跨域时，如果要发送Cookie，Access-Control-Allow-Origin就不能设为*，必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到...

YanceyOfficial 2019-07-25 14:36 评论0 收藏0