摘要：背景早些时候我们做了一个项目，用的是前后端分离，前端后端提供功能接口，然后两个部署在不同的域名下后端接口开放了跨域，方便前端本地开发调试。前端项目域名为后端的接口域名为，上线后也没问题，一切都美滋滋的。
背景
早些时候我们做了一个项目，用的是前后端分离，前端vue,后端提供功能接口，然后两个部署在不同的域名下,后端接口开放了跨域，方便前端本地开发调试。前端项目域名为www.a.com,后端的接口域名为 www.b.com，上线后也没问题，一切都美滋滋的。直到有一天，用户反馈过来有一个页面一些数据出现的太慢了。。
然后我们各种优化，前端缓存、数据库索引等等，快了那么一点，最后想能不能再快点，因为一开始用了开放跨域，且接口的请求方法为post,所以是复杂请求，会先发送一个options请求探探路，每个接口都会发这个，消耗的时间都有几百毫秒，这样时间就捉急了，那么如何解决这个问题呢~
为什么会跨域、复杂请求、nginx的使用不在本文范围~
想到的解决方案 不跨域的方向方案1：放到同一个项目中，同一个域名（pass，（前后端各自管理，不好合并了，需要考虑接口地址已经使用，不能改了的情况）
方案2：nginx反响代理api接口，对于前端项目来说看起来不跨域（采用）
方案3：jsonp和其他（限制比较多）
options请求的速度更快点的方向方案：原来的跨域响应头是应用中加的，能不能放在更前面一点的步骤，比如请求到nginx就返回(快了一丢丢。pass)
解决方案（方案2模拟） 场景前端项目域名为www.a.com,文件夹为html/a,
接口项目为www.b.com，文件夹为html/b
现在有一个接口，www.b.com/login.json，大意为登录接口，现在用json数据进行模拟
www.a.com会发送一个登录请求获取数据
目录结构图如下
html ├── 50x.html ├── a │ └── index.html ├── b │ ├── apis │ │ └── login.json │ └── login.json └── index.html
b/login.json的内容为`{
"location": "我是b站点/login"
}`
b/apis/login.json的内容为`{
"location":"我是b站点/apis/login"
}`
b/apis/login.json存在的意义是验错，没有的的话访问是404，但是需要知道访问到哪啦
修改前端项目www.a.com中的请求接口为www.a.com/apis/login，真正的接口地址为www.b.com/login，如果请求www.a.com/apis/login能获取json数据，则不会进行跨域（前端项目和接口在同一域名下），也不会发options请求
修改前端项目www.a.com的nginx配置所有/apis/打头的接口，全部去请求www.b.com
nginx配置如下图
server {
listen 80;
server_name www.a.com;
access_log logs/test.access.log;
# 匹配以/apis/开头的请求
location ^~ /apis/ {
proxy_pass http://www.b.com;
}
location / {
root html/a;
index index.html index.htm;
}
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
proxy_pass 常用在反向代理，比如nginx代理node服务，java服务
重启nginx 效果curl www.a.com/apis/login.json结果为
{
"location":"我是b站点/apis/login"
}
结果是不对的（观察下上文给出的文件夹下，还有个apis/login.json），心理的预期www.a.com/apis/login.json是要访问到www.b.com/login.json，应该是b文件夹下的login.json，内容为
`{
"location": "我是b站点/login"
}`
修改a站点的nginx配置文件并重启nginxserver {
listen 80;
server_name www.a.com;
access_log logs/test.access.log;
# 匹配以/apis/开头的请求
location ^~ /apis/ {
proxy_pass http://www.b.com/; #注意域名后有一个/
}
location / {
root html/a;
index index.html index.htm;
}
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
没错就是proxy_pass后面的地址加一个/
加/的情况，访问www.a.com/apis/login.json会得到www.b.com/login.json（符合预期的）,使用b文件夹作为/目录来访问
不加/的情况,访问www.b.com/apis/login.json会得到www.b.com/apis/login.json（不符合预期）,使用b文件下的apis作为根目录进行访问
最终的效果为
{
"location": "我是b站点/login"
}
参考资料
用nginx的反向代理机制解决前端跨域问题
Nginx反向代理解决跨域问题
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/39767.html
摘要：反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢 标签： Nginx,跨域 问题 在之前的分享的跨域资源共享的文章中，有提到要注意跨域时，如果要发送Cookie，Access-Control-Allow-Origin就不能设为*，必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到...
摘要：反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢 标签： Nginx,跨域 问题 在之前的分享的跨域资源共享的文章中，有提到要注意跨域时，如果要发送Cookie，Access-Control-Allow-Origin就不能设为*，必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到...
摘要：反向代理服务器对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢 问题 在之前的分享的跨域资源共享的文章中，有提到要注意跨域时，如果要发送Cookie，Access-Control-Allow-Origin就不能设为*，必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到此类问题。 showImg(h...
摘要：三反向代理解决的原理将安装在本地，然后将项目部署于下，这样访问本地项目时用本地项目即可访问。这样浏览器之间的请求完全满足浏览器域名协议端口相同的同源策略，可在不改变后台接口的情况下避免跨域问题。 一、问题背景说明： 编写移动前端页面时需要访问后台系统接口。前端项目在本地（个人办公电脑）开发，后台接口存放后生产的后台服务器，本地的ajax请求无法直接访问后台接口，也就是遇到了跨域问题...
阅读 1150·2021-11-23 10:10
阅读 1400·2021-09-30 09:47
阅读 854·2021-09-27 14:02
阅读 2940·2019-08-30 15:45
阅读 2987·2019-08-30 14:11
阅读 3546·2019-08-29 14:05
阅读 1764·2019-08-29 13:51
阅读 2118·2019-08-29 11:33
