目录
前言
一、NGINX是什么？
二、NGINX作为web服务器和反向代理服务器的使用
1.反向代理介绍
2.代码展示
3.修改nginx的配置文件
三、NGINX配置文件中的一些小修改
1.日志的开启
2、worker进程的启动用户
3.pid进程文件的位置问题
关键词：反向代理
Nginx（发音为“engine-x”）是一款高性能的HTTP和反向代理服务器，同时也是一个邮件代理服务器。它是一个开源软件，以其高稳定性、丰富的功能集、简单的配置和低资源消耗而闻名。Nginx 由 Igor Sysoev 开发，最初发布于2004年，并逐渐成为世界上最流行的Web服务器之一。
主要特性包括：
• 作为Web服务器：支持静态文件的服务，索引文件和自动索引；支持无缓存的反向代理加速；提供简单的负载均衡和容错。
• 作为反向代理服务器：管理请求，将它们转发到其他服务器处理，并将响应返回给原始请求者。
• 负载均衡：能够在多个后端服务器之间分配请求，提高网站的扩展性和可用性。
• 高并发连接：使用异步事件驱动的方法，使得Nginx能够支持高并发连接，只用很少的资源就可以维持大量的并发连接。
• 配置灵活：配置方式简单，易于配置，具备丰富的模块支持，如gzip压缩、缓存、SSL和HTTP/2支持等。
• 安全性：提供SSL/TLS协议的支持来建立加密连接，以及通过基本的认证和IP地址过滤提供访问控制。
Nginx被广泛用于提供静态内容，结合缓存解决方案加速动态内容，以及作为负载均衡器来提高大规模应用的可用性和效率。其设计效率高，能处理大量的并发连接，而且占用的内存和CPU资源较少，这使得它非常适合现代的高性能Web应用。
nginx使用最多的场景便是作为反向代理的代理服务器，但这个反向代理很多人却不理解，如果使用比较官方的解释便是一种服务器配置方式，其中代理服务器位于客户端和后端服务器之间，接收来自客户端的请求并将其转发到一个或多个后端服务器。
那么如果要通俗一点，我们可以先画一张图来方便理解
不同于直接将后端应用服务器直接暴露给客户端访问，而是在后端应用服务器之上包装了一层，客户端访问的是nginx的代理服务器，然后nginx的代理服务器收到来自四面八方的客户端请求后，再转发给后端应用服务器做处理，那么就有很多人发问了，我直接将后端应用服务器暴露给客户端访问不好吗，为什么还要多此一举的来设置个反向代理服务器呢？
这里我直接以实际应用中的场景来阐述反代的作用，这样也更易于理解。
现在假设一个场景，客户的网络环境分为内网和外网环境，在客户的dmz隔离区域内的服务器既能访问外网，也能同时访问内网的服务器，而在内网的服务器只能访问内网与外网不互通，这时候如果我想在内网部署一台应用服务，要求这台应用服务器提供的应用服务在让内网的用户访问到的前提下，也必须让外网的用户访问到，那么我该怎么部署呢？
首先我们要明确的一点是，客户的大部分员工的电脑都处在内网环境下，而我们的应用服务器也部署在内网环境下，客户当然可以直接使用应用服务器的ip+端口的方式访问服务，那外网用户呢？
我们可以直接使用公网ip+端口映射的方法把内网应用服务器的端口映射到公网，这样也可以达到我们想要的效果。但是不要忽略安全问题，如果直接映射的是应用服务器的端口，那么无疑就是将整个应用服务暴漏在了公网中，如果碰到网络攻击，那么这个应用服务无疑是非常危险的，而如果部署了反代服务器，这时候nginx代理服务器就仿佛一个保护壳套在了应用服务器上，保护后端服务器不直接暴露于外部网络，从而防止攻击。
到这里，大家想必对反代已经有了一定的认识，当然反代的作用不只是起到一个保护作用，他还有更多的作用，比如：
1. 负载均衡：
• 反向代理可以在多个服务器之间分配客户端请求，从而优化资源使用，提高网站的响应速度和可用性。
2. 缓存静态和动态内容：
• 可以缓存经常请求的内容，减少对后端服务器的请求次数，提高响应速度。
3. 提供SSL终端：
• 在代理服务器上进行SSL加密和解密，从而减轻后端服务器的负担，简化证书管理。
4. 压缩和优化内容：
• 可以在将内容发送到客户端之前进行压缩，以减少传输数据量。
既然讲了这么多反代的优势，那么我们如何配置反代呢，这里我以一段代码模仿后端的应用服务
前端页面代码展示
上面代码主要实现一个路径为/haha的接口，并将请求的路径返回到请求头中，返回this is a nginx demo的字符串给前端页面，前端页面在请求到后端接口后，会更新浏览器的地址栏为后端返回的拼接的请求地址
访问效果图为
nginx的部署环境为centos7
配置反向代理我们只需要修改nginx的配置文件nginx.conf
请自行在自己的服务器上找到nginx.conf文件并打开
nginx的配置文件根据nginx的版本可能会稍有不同，但不影响整体的配置
我们可以看到http的代码块中，有个server块（nginx配置文件中的每一个server块都可以理解成一个服务），监听的端口为80端口，我们可以直接在这个80的server中配置，也可以选择自己单独写一个server块，这里我们直接在这个server块中配置
将其中的server name 修改为当前服务器的ip（如果这台服务器做了dns域名映射，也可以设置成这台服务器的域名），这个参数主要定义哪些HTTP请求会被这个服务器块处理，基于请求的”Host”头部中的域名或者ip。这里我们直接配置这台服务器的ip即可
下面要新增一个location块，location / {}
这个location块捕获对根URL（”/”）的所有请求。
其中的proxy_pass http://192.168.90.53:8080;
是将请求转发到后端服务器的指定地址和端口。
现在访问我们配置的http://192.168.50.249/ 这个地址就能直接访问到我们后端的服务了，已经实现了最基本的代理功能，但是大家有没有发现什么不同，没错就是我们请求头中的请求地址消失了，那这当然不是我们想看看到的。
原因呢也很简单，我们在nginx的配置中只配置了代理，但是没有配置请求头的转发，这里我们需要再修改下nginx的配置文件，增加请求头的代理转发
proxy_set_header Host $host;
这行配置修改转发请求的 Host 请求头，将其设置为接收到的请求的 Host 头部的值。这确保后端服务器接收到正确的主机头信息。
proxy_set_header X-Real-IP $remote_addr;
这设置 X-Real-IP 头部为原始请求的客户端 IP 地址，用于在接收请求的服务器上记录原始请求者的 IP 地址。
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
这行添加或更新 X-Forwarded-For 头部，包含原始请求的客户端 IP 地址及之前任何代理的地址。它用于追踪请求链路中所有的代理设备。
proxy_set_header X-Forwarded-Proto $scheme;
这设置 X-Forwarded-Proto 头部，用于标示原始请求使用的协议（如 http 或 https）。
然后保存配置文件，并重载nginx
如果是重载nginx，可以直接使用nginx -s reload ,这个命令可以进行热重载，再不关闭已有nginx的链接情况下，重载nginx的配置文件，达到更新配置的目的，但是nginx有时因为各种原因导致master或者worker进程出现问题而导致配置文件的更新没有生效
所以生产环境下如果能直接停止nginx服务，就直接使用nginx -s stop命令直接停止nginx的所有进程
如上图：
在停止服务前，先使用nginx -t 命令查看修改的配置文件是否有问题，如果出现问题可以及时修改，而不影响现在运行的nginx服务(不然你直接停服务，服务停了，重启服务时报错配置文件有问题一时间服务起不来就得不偿失了)
配置文件校验没有问题 就可以直接nginx -s stop停止服务
这里可以用ps -ef|grep nginx 命令看下nginx的服务进程是否全都停止了，如果没有停止请手动使用kill 命令杀死（这里被坑过，nginx -s stop命令有时候没有把nginx进程全都杀死，并且后续启动服务也不报错，配置文件更新怎么也不生效，所有才养成查看进程是否被全部杀死的习惯）
确保所有的nginx的进程都被杀死后，就可以nginx命令启动nginx了
PS:由于浏览器存在的跨域问题，此时我们也需要将前端代码中的后端请求地址修改为nginx的ip地址
这样我们再访问这个地址，就能看到携带的请求头信息了
可以在配置文件中看到两处开启日志的地方，有些配置文件这里是注释掉的，如果是注释掉的建议开启，因为nginx可能会因为缓存或者权限问题出现各种不易排查的小问题，开启日志有助于排查并解决问题
配置文件的最上方这里是nginx worker进程的启动用户，默认是关闭或者是nobody，这里建议修改成nginx用户或者root用户，避免在日志文件中出现权限不足导致目录无法写入的问题（这类问题可能会导致应用服务出现各种匪夷所思的bug，需要注意一下）
这一行pid文件的位置配置信息请不要注释或者删除，如果nginx在关闭的过程中找不到正确的pid文件的位置，将会报错无法正常停止
解决问题的办法也很简单
首先通过ps -ef|grep nginx 命令找打正在运行的nginx的master进程的进程号，然后将pid号直接重定向到nginx的pid文件中
nginx即可正常停止
总结