长话短说，最近我在按照教程推进做项目的时候，发现无法实现前后端联调。解决的过程如下：
- 使用Postman测试，发现后端能正常接受请求，但是前端的请求后端无法处理，误以为是前端代码编写错误。
- 决定去下载前端项目源码，试图理解逻辑，重新打包，运行过程中发现一堆版本不兼容问题。
- 我开始一个个解决，但是没有尽头，一个个版本冲突层出不穷，我尝试过降低我的 nodejs 的版本，但还是解决不完。得出结论：是此前端项目的问题。
- 疲惫之际，决定采用“重启大法”。我重新从网盘下载了前端打包文件，重新部署在nginx服务器，还是不行。
- 我尝试重新配置 nginx.conf ，我之前是直接在自动生成的 nginx.conf 里修改root值（前端打包文件的目录），这次我直接在提供的 nginx.conf 中修改 root 值。（真的笨，这样做才是最好的，在不清楚教程是怎么写 nginx.conf 的基础上选择相信它只修改了 root 值本身就是愚蠢的）十分疲惫下重启 nginx 服务器，惊讶发现不是404错误了，而是其他错误（因为我之前擅自修改后端 Controller 的响应路径）。欣喜之下改回原来的路径，发现响应成功。
现在静下来了，来对比一下教程提供的nginx.conf（下面称作：“第一段”）与系统默认生成的nginx.conf（下面称作：“第二段”），除了root值不同，不同之处还有第一段相比第二段引入了反向代理、负载均衡与 WebSocket 。下面来逐个分析：
1. 反向代理
第一段引入了两处反向代理。当浏览器发出这样的请求时：http://localhost:80/api/../..，Nginx服务器会通过 location /api/ {} 这样的反向代理到http://localhost:80/admin/../..。类似的，当我们访问http://localhost:80/user/../..这样的接口的时候，后端服务器接收到的请求是http://localhost:80/ws/../..。这样的好处有：1. 安全（后端服务器地址不会暴露）；2.提高访问速度等。
2. 负载均衡
这段配置中，upstream定义了一个服务器组webservers，用于后端服务的负载均衡。在这个配置中，所有传入webservers组的请求可以被转发到组内的任一服务器。server 127.0.0.1:8080 weight=90 定义了一个后端服务器（本地主机上的8080端口）和它的权重（90）。权重高的服务器接收更多的连接。第二行被注释掉了。在实际部署中，通过调整服务器的权重，可以根据服务器的性能和容量来分配请求，实现负载均衡。
除了这段配置采用的 weight 策略，常用的 Nginx 负载策略有：轮询、按照ip分配、按照最少连接数分配、按照url分配、按照响应时间分配等。
3. WebSocket
第一段配置专门处理 WebSocket 连接，用于支持实时双向通信。所以
http://localhost:80/ws/../..的请求被转发到http://webservers/ws/../..。并设置了HTTP版本、超时时间以及HTTP头部。
第二段map块基于第一段http_upgrade的值设置了一个新的变量 connection_upgrade。如果客户端没有请求升级（http_upgrade为空），则connection_upgrade被设置为close，表示不升级连接。这样确保了只有当客户端明确请求升级为WebSocket时，连接才会被升级。
之所以要引入 WebSocket，是因为为了实现客户端与服务器端的实时、双向通信，而不需要像传统的HTTP请求那样，客户端每次都需要发送一个请求以获取最新的数据。这为许多需要高实时性的应用提供了极大的便利。
