初识Nginx——前后端发布、Nginx反向代理
事情是这样的
一个前后台分离的项目，前台使用nginx发布端口为7701，后台使用tomcat发布端口为7702。在前台js中进行 Ajax 对后台请求。这台服务器是内网，于是把7701的端口映射成外网地址假设为（network:8808），那么可以通过外网连接外网地址访问到7701的前台页面。此时外网并不能做后台的网路访问请求，因为7702的端口地址，外网无法访问。
我们该如何解决
更改前台7701的 nginx.config 的配置，利用 nginx 的反向代理，将后台 7702 的地址也放到 7701 的端口下，即访问的 7702 变成 7701/api（api名字可以自己指定）。然后将前端 js 请求后台的base地址改成( network:8808/api )
server {
listen 7701;
server_name 192.168.0.67;
location ^~/service {
proxy_pass http://192.168.0.67:7702/;
}
location / {
root D:\dist\app;
index index.html;
}
}
学习内容
nginx 反向代理，那么反向代理到底是什么
知乎精辟 ：正向代理就是隐藏真实的客户端，反向代理就是隐藏真实的服务端。（其实也不是每个人都能理解这句话的，比如我刚开始看到的时候。）
参考博客 ： https://segmentfault.com/q/1010000003491873
博客摘要 ：
A 找 B 直接沟通，这就等于没有什么代理；
然而中间夹一个传话的 C，C 就是代理了，A 通过 C 把信息传递给 B，然后 C 再把 B 的反馈转达给 A。
在这个过程中，A 知道沟通的直接目标是 B，只不过由于各种原因无法直接和 B 面对面，需要中间人 C，这就是所谓“正向代理”，其实我们很少说正向代理，在英文原文里，这个叫 Forward Proxy，一般就直接叫代理，你翻译成“转交代理”或“传达代理”都比“正向代理”强，然而没必要，因为代理这个词的本意就是如此。
另外一种情况则是：A 并不知道 B 的存在，它只知道找 C 就可以得到想要的回复，对于 A 来说有没有 B 或者有多少个 B、D、E、F……都不重要，只要有 C 就够了。而 C 则根据情况去获取反馈然后响应给 A。
这种就叫反向代理了。理解其中的区别不要从“正反”两个反义方向词上做文章，英文里的 Forward 和 Reverse 并不是一对反义词，Forward 和 Backward 才是，然而 Reverse 和 Backward 并不是一个意思……所以说技术书籍资料还就是得看原文的啊。
Forward Proxy（代理）
我想访问 www.google.com，然而大家都知道它被墙了，我没法直接访问它。于是我连接了一个 VPN 服务并设定其为本地 HTTP 访问的代理（比如说在 Mac 下勾选“通过 VPN 连接发送所有流量），然后我再访问 www.google.com，此时我的请求被该 VPN 服务代理了，它帮我访问了 www.google.com 然后把结果返回给我。
这个例子是代理的一种应用场景，但并非代表代理只能用于这个
最重要的特征是我知道 www.google.com 的存在，而且我访问的网址也的确是 www.google.com，只不过我的访问请求经由了 VPN 代理来转交，同样响应也是如此
在本例中，代理是透明的，用户有可能不知道它的存在（通常是知道的，只不过代理的设置可能不是他自己来做）
Reverse Proxy（反向代理）
我有一个 Nginx 服务部署在 www.mysite.com 的 80 端口，用户访问它就可以看见我做的网站；在我的网站中有一些 Ajax 请求去获取 JSON 数据，然而提供这些数据的 API Service 部署在服务器上的 8000 端口，该端口由于防火墙的阻挠使得用户无法直接访问到。
于是我重新配置了 Nginx，让它把所有经由 :80/api/ 的访问请求都代理给 localhost:8000，然后把响应返回给原始的请求方（即：Origin Host），这就是反向代理。现在我的用户可以正常访问 www.mysite.com 啦。
同上，这是反向代理的一种应用场景，但并非代表它只能这样用
最重要的特征是我的用户压根不知道 localhost:8000 这个服务的存在，并且即使知道也访问不到——开 VPN 也访问不到，这是俩码事！
对于用户来讲，唯一的“对话”方只有 www.mysite.com（80 端口），他们不知道也不必知道后面发生了什么
个人总结：
正向代理在客户端做代理（比如浏览器设置代理服务器），反向代理就是在服务端做代理（比如上方我把 7702 服务端的地址用了 7701/api 地址代理）。
如有错误，敬请指正。
