nginx 解决跨域、手机测试 2019-05-27
1，手机和电脑在同一个局域网下（电脑可以放个wifi出来给手机连）。
2，安装nginx，网上查。
3，找这个目录下的这个文件，打开。
4，配置文件，listen 配置端口，location下的root 后面跟着index.html所在文件夹路径，
直接复制的路径是这个C:\Users\lalalalala\Desktop\hongbao\templates，注意要把“\”换成“/”，否者会报错（我就是在这里坑了很久）。
5，特别强调，注意开发调试时的console.log（），打印过多会撑爆微信浏览器缓存，就打不开页面了，坑死。
6，nginx 命令
注意，敲命令一定要用cmd，Window powerShell会报错。
cd 到nginx.exe所在文件目录下，
开始 ：start nginx
重启 ：nginx -s reload （改了配置文件就要重启）
停止 ：nginx -s stop
6，打开后，查一下电脑ip，在cmd里面直接输入ipconfig，回车就会出现啦。
ip:端口（如 192.168.1.1），就能看到网页啦
假设我们在开发一个项目，我这边写好了页面，同事写好了服务器，给的测试接口是： ，
那么跨域就是如下解决。
修改nginx.conf， 在server里添加一个location，如下，
/marketing为代表，在ajax请求中
url直接写成 /marketing/****/****/***.json，就行了，
当然，上线到生产环境得改回来。这样就是可以实现跨域测试了。
这种适用于直接写HTML页面时使用，如果用vuecli的话，可以参考这里 vue cli3 简单解决跨域问题 ，也可以参考这里 vuecli3复杂解决跨域、手机真机调试
)
Nginx的反向代理跨域
什么是跨域？
跨域是指a页面想获取b页面资源，如果a、b页面的协议、域名、端口、子域名不同，或是a页面为ip地址， b页面为域名地址，所进行的访问行动都是跨域
浏览器为了安全问题一般都限制了跨域访问，也就是不允许跨域请求资源
同ip（或domain）,同端口，同协议视为同一个域，一个域内的脚本仅仅具有本域内的权限，可以理解为本域脚本只能读写 本域内的资源，而无法访问其它域的资源。这种安全限制称为同源策略
现代浏览器在安全性和可用性之间选择了一个平衡点。 在遵循同源策略的基础上，选择性地为同源策略“开放了后门”。例如img script style等标签，都允许垮域引用资源,然而， 你也只能是引用这些资源而已，并不能读取这些资源的内容
同源策略限制以下几种行为：
1.Cookie、LocalStorage 和 IndexDB 无法读取
2.DOM 和 Js对象无法获得
3.AJAX 请求不能发送
同一域名，不同文件或路径 允许 同一域名，不同端口 不允许 同一域名，不同协议 不允许 域名和域名对应相同ip 不允许 主域相同，子域不同 不允许 不同域名 不允许
1、 通过jsonp跨域
2、 document.domain + iframe跨域
3、 location.hash + iframe
4、 window.name + iframe跨域
5、 postMessage跨域
6、 跨域资源共享（CORS）
7、 nginx代理跨域
8、 nodejs中间件代理跨域
9、 WebSocket协议跨域
正向代理 ：代理位于网站和客户端中间， 客户端无法访问某网站，就将请求发送给代理服务器，代理从网站取回来再发送给客户端，网站并不知道为谁提供服务
反向代理 ：客户端访问某网站的一个页面， 但是网站并没有，就偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户，用户不知道真正提供服务的是谁
对于浏览器来说，访问的就是同源服务器上的一个url。而nginx通过 检测url前缀，把http请求转发到后面真实的物理服务器。并通过rewrite命令把前缀再去掉。这样真实的服务器就可以正确 处理请求，并且并不知道这个请求是来自代理服务器的。
简单说，nginx服务器欺骗了浏览器，让它认为这是同源调用，从而解决了浏览器的跨域问题。又通过重写url，欺骗了真实 的服务器，让它以为这个http请求是直接来自与用户浏览器的。
Location/carrots-admin-ajax/{
proxy_pass;
}
proxy_pass 把请求代理到其他主机
两种写法h 和
如果访问url = ，则被nginx代理后
情况1，将test/作为根路径，请求test/路径下的资源。
情况2，则被nginx代理后，请求路径会变为，直接访问server的根资源。
是一个匹配规则，用于拦截请求，匹配任何以/proxy/html/开头的地址，匹配符合以后，停止往下搜索正则。
对于浏览器来说，访问的就是同源服务器上的一个url。而nginx通过检测url前缀，把http请求转发到后面真实的物理服务器。并通过rewrite命令把前缀再去掉。这样真实的服务器就可以正确处理请求，并且并不知道这个请求是来自代理服务器的。
简单说，nginx服务器欺骗了浏览器，让它认为这是同源调用，从而解决了浏览器的跨域问题。又通过重写url，欺骗了真实的服务器，让它以为这个http请求是直接来自与用户浏览器的。
1.执行server块的rewrite指令(这里的块指的是server关键字后{}包围的区域，其它xx块类似)
2.执行location匹配
3.执行选定的location中的rewrite指令
如果其中某步URI被重写，则重新循环执行1-3，直到找到真实存在的文件
如果循环超过10次，则返回500 Internal Server Error错误
7.参考文献
参考一：
参考二：
8.更多讨论
提问：
Q ：例如img script style等标签，都允许垮域引用资源？
A ：在浏览器中，并且加载的方式其实相当于一次普通的GET请求，唯一不同的是，为了安全起见，浏览器不允许这种方式下对加载到的资源的读写操作，而只能使用标签本身应当具备的能力（比如脚本执行、样式应用等等）。
Q ：例如img script style等标签，都允许垮域引用资源？
A ：在浏览器中，并且加载的方式其实相当于一次普通的GET请求，唯一不同的是，为了安全起见，浏览器不允许这种方式下对加载到的资源的读写操作，而只能使用标签本身应当具备的能力（比如脚本执行、样式应用等等）。
Q：JSONP和nginx跨域有什么不同
JSONP和nginx是完全不同的 是可以跨域的，而且在跨域脚本中可以直接回调当前脚本的函数
原理：是可以跨域的，而且在跨域脚本中可以直接回调当前脚本的函数
script标签是可以加载异域的JavaScript并执行的，通过预先设定好的callback函数来实现和母页面的交互。它有一个大名，叫做JSONP跨域，JSONP是JSON with Padding的略称。它是一个非官方的协议，明明是加载script，为啥和JSON扯上关系呢？原来就是这个callback函数，对它的使用有一个典型的方式，就是通过JSON来传参，即将JSON数据填充进回调函数，这就是JSONP的JSON+Padding的含义。JSONP只支持GET请求。
nginx配置ssl使用https(解决前端跨域问题)
想要使用https访问nginx上部署的项目首先得有ssl证书，ssl证书可以去阿里云或腾讯云之类的平台购买，当然也有免费的。我这里贴出nginx的相关配置来支持https访问，如果不知道怎样配置或者搞不清楚原理的朋友就直接照搬我的这部分server配置就行。
PS：nginx需要安装ssl模块，如果使用docker启动的nginx则已经有了不需要安装。
这里不仅配置了https对于nginx的访问，还配置了代理来访问后端接口，所以前端在做请求时，请求的地址应该写为 +接口地址，这样前端就能使用https来访问到后端的接口了。
顺便贴一个把http重定向为https的配置
使用nginx代理解决跨域问题
先说说跨域这事情吧。早在13年，我刚接触前端开发的时候就遇到了跨域，那时候刚开始流行前后端分离。解决跨域就是直接用get jsonp。还是小白的我，也没有去想跨域的其它解决方式和为什么要采用这种解决方式。
最近，做一个二次开发的项目，也碰到了用网页请求http post，浏览器跨域，不能获取返回数据的问题，所以再次来梳理下这个跨域，为什么最后选择了nginx代理。
首先，什么是跨域呢？首先需要了解的是同源和跨源的概念。对于相同源，其定义为：如果协议、端口（如果指定了一个）和主机对于两个页面是相同的，则两个页面具有相同的源。 只要三者之一任意一点有不同，那么就为不同源。 同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的关键的安全机制。当一个资源从与该资源本身所在的服务器的域或端口不同的域或不同的端口请求一个资源时，资源会发起一个跨域 HTTP 请求。跨域不一定是浏览器限制了发起跨站请求，而也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。 简单的来说，出于安全方面的考虑，页面中的JavaScript无法访问其他服务器上的数据，即“同源策略”。而跨域就是通过某些手段来绕过同源策略限制，实现不同服务器之间通信的效果。
跨域的解决方案也有很多种。
类型一：有些浏览器可以设置 ，降低它的安全性。但是对于一个网站，要求设置浏览器是不切合实际的。
类型二：直接用form方式 ，这种情况下不是ajax请求，而是直接访问目标地址了，不存在跨域问题，但是这个页面已经跳转了。而我们想实现的只是取另外一个地址的数据到本地显示而已。
类型三：服务端语言是能够处理的情况下。
1、CORS 是一个W3C标准，全称是”跨域资源共享”（Cross-origin resource sharing）。它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。跨域资源共享（ CORS ）机制允许 Web 应用服务器进行跨域访问控制，从而使跨域数据传输得以安全进行。其需要服务端和客户端同时支持。
对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。 Access-Control-Allow-Origin 该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。 Access-Control-Allow-Credentials 该字段可选。 Access-Control-Expose-Headers 该字段可选。
可以说这种办法主要在header上下功夫，设置Access-Control-Allow-Origin为所有*允许访问。虽然说它支持所有的请求方式，post，delete，put等等，但是它不能兼容ie6，7等等。
例如下图的nodejs express 例子：
2、服务端的http ajax请求全部改为 get jsonp方式 。该方式能够兼容老式浏览器。
3、iframe window.name 这种传值得方式很巧妙，兼容性也很好。但是在要访问数据的地址那个服务器要有一个空的中间页面拿来用。
4、postMessage ， html5 window.postMessage。 同iframe window.name有点像，也是需要服务端有个空的html拿来接收数据。而且现在的postMessage兼容性也不好。
5、document.domain 修改为顶级域名。
6、 WebSocket ，协议不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。
类型四：不是简单的前后端。假如有个第三方的api，自己有一个网站前端，一个网站后端。
1、自己的网站端和后端源码放在同一个服务端口和目录下，不存在跨域。当直接用网站前端的http访问第三方api，浏览器跨域。此时，改为由网站后端的服务端语言访问，做个中间人，将访问的数据给网页前端。
2、网站前端和后端不是同源的，采用以上的跨域方案，譬如CORS。同样的网站后端做中间人，访问第三方api，再转给网页前端。
3、使用nginx 反向代理解决跨域问题。 网站前端访问nginx服务的地址，nginx设置代理地址为访问第三方api地址，当访问代理地址的时候，浏览器访问的是nginx服务的地址，实际是访问第三方api地址。
注意：此时，如果目录下有个proxy.html,因为设置代理地址是/proxy，碰到这个地址就被转到”“，所以要访问proxy.html是访问不到的。
4、使用nginx代理地址是解决生产环境发布的问题了，那么我在开发的时候使用angular这样需要打包的框架怎么办呢。当然在开发环境下，angular也是由类似代理地址的解决方案的。
（1）创建配置代理文件：假设后端服务的访问地址为，我们可以创建一个proxy.conf.json文件，放在package.json同目录下。
（2）改写package.json文件 ，采用--proxy-config命令（angular自带的命令）。
(3)ajax访问代理地址
此时， 执行 npm start ，即可发现，浏览器访问 的同源地址，实际上是访问.
angular在开发环境下代理地址的方法类似在生产环境下使用的nginx代理。但是测试angular是有一个/api代理地址的巧合。刚好第三方api上面的地址有个api，才能使用这个地址，并且能够简写一个api，才能成功访问，如果更改为其它的，譬如proxy，就测试失败。而且proxy.conf.json文件下的设置也只能是域名和端口。所以，本人测试，这或许是个巧合或者是缺陷。
五、其它
当然，跨域这个算是历史性的问题，以后也会存在这个问题。除了上面各种方法，以及根据各种方法使用的场合，还有许多其它的方法。例如各大流行框架react，vie应该也有像angular一样，能够处理跨域的开发环境方案，接下来，还是要继续学习和积累。
Nginx部署前后端项目时的跨域问题
最近在准备一个小项目来着，使用tomcat部署后端的SpringBoot项目，然后使用Nginx部署前端界面并转发后端请求到相应的tomcat集群时，发生了跨域问题，解决过程欲仙欲死，特在此记录一下。
Nginx跨域配置方法一
严格说来，这种方式并不算是跨域请求，因为这种配置要求后端请求的url必须为 的形式，也就是说前端项目的请求地址必须进行更改为和客户端页面访问时的url地址一样，这样貌似也就没有跨域问题了。如果前端项目不同模块的请求地址不一样，则都需要进行更改。
Nginx跨域配置方法二
注意： api.mk-shop.com 是后端api的请求前缀，也就是客户端异步加载时的请求地址，以我的项目的后端请求地址为例:
SpringBoot后端处理跨域时可以配置过滤器来实现
注意： 使用过程中，新版本的springboot可能会报错不允许在setAllowedOrigins包含 * ，此时需要使用setAllowedOriginPatterns代替。
宝塔面板Nginx反向代理解决跨域问题
主要使用Nginx反向代理实现
api地址为：
前端访问地址为:
现在前端如果访问接口地址就会出现跨域的问题
配置如下
修改配置文件
完成以上设置就可以跨域访问了