一 理论说明
（一）反向代理简介
反向代理：reverse proxy，指的是代理外网用户的请求到内部的指定的服务器，并将数据返回给用户的一种方式，这是用的比较多的一种方式。
即 代理服务机
Nginx 除了可以在企业提供高性能的web服务之外，另外还可以将 nginx 本身不具备的请求通过某种预定义的协议转发至其它服务器处理，不同的协议就是Nginx服务器与其他服务器进行通信的一种规范，主要在不同的场景使用以下模块实现不同的功能
（二）相关模块
| ngx_http_proxy_module | #将客户端的请求以http协议转发至指定服务器进行处理 |
| ngx_http_upstream_module | #用于定义为proxy_pass,fastcgi_pass,uwsgi_pass等指令引用的后端服务器分组 （负载均衡） |
| ngx_stream_proxy_module | #将客户端的请求以tcp协议转发至指定服务器处理 |
| ngx_http_fastcgi_module | #将客户端对php的请求以fastcgi协议转发至指定服务器助理 （语言不同 接口不同） |
| ngx_http_uwsgi_module | #将客户端对Python的请求以uwsgi协议转发至指定服务器处理 （语言不同 接口不同） |
（三）架构图
1，反向代理
2，同构代理 异构代理
同构协议：客户机 服务机协议一样
异构： 不一样
二 单台代理
（一）具体步骤
实验环境：66是代理服务器 77 是真实服务器
66 配置文件：
表示开启代理 真服务机是77
访问 66 也能看到77 真服务器 的内容
（二）出现504
1，出现504 的情况
在真实服务器上 做防火墙规则
iptables -A INPUT -s 192.168.91.66 -j DROP
客户端再次访问 会出现504网关超时（有可能只是处理时间久，服务器不一定挂了），时间较长1分钟，没有定义代理超时时间
2， 504 解释
drop 丢弃 真实服务机一直丢弃代理服务机
代理服务机会以为 真实服务机没收到 会一直发
大概持续一分钟 超时 然后返回504
（三）出现502
1，出现502 的情况
在真实服务器上 做防火墙规则
iptables -A INPUT -s 192.168.91.66 -j REJECT
客户端再次访问 会出现502，一般出现502 代表后端真实服务器挂了
2,502 解释
网关不可达 reject 拒绝
基本判定 真实服务机挂了
三 针对某个uri 进行反向代理
（一）实验步骤
66代理服务机：
访问66/api 等于访问 真是服务器77/api
77 真实服务机 主页面内容：
客户机访问：
（二）注意加/ 和不加/ 区别
http://192.168.91.77 不加/ 是将location上的url 追加在后面
http://192.168.91.77/ 加上/ 是将location上的url 替换后proxy配置里的连接
即访问 真实服务机的主页面
四， 反向代理 缓存功能
（一）作用
加快速度
万一 真实服务器挂了 救急
（二）语法结构
1， 主配置文件
在http配置定义缓存信息
| proxy_cache_path /var/cache/nginx/proxy_cache | #定义缓存保存路径，proxy_cache会自动创建 |
| levels=1:2:2 | #定义缓存目录结构层次，1:2:2可以生成2^4x2^8x2^8=2^20=1048576个目录 |
| keys_zone=proxycache:20m | #指内存中缓存的大小，主要用于存放key和metadata（如：使用次数）,一般1M可存放8000个左右的key |
| inactive=120s | #缓存有效时间 |
| max_size=10g; | #最大磁盘占用空间，磁盘存入文件内容的缓存空间最大值 |
2， 子配置文件
#调用缓存功能，需要定义在相应的配置段，如server{...};或者location等
| proxy_cache zone_name | off; 默认off | #指明调用的缓存，或关闭缓存机制; #zone_name 表示缓存的名称.需要由proxy_cache_path事先定义 |
| proxy_cache_key $request_uri; | #对指定的数据进行MD5的运算做为缓存的key （理解为记住 路径） |
| proxy_cache_valid 200 302 301 10m; proxy_cache_valid 401 1m; | #指定的状态码返回的数据缓存多长时间 对状态码不同 缓存时间不同 200 302 正常访问 时间长 404 不正常 |
| proxy_cache_valid any 1m; | #除指定的状态码返回的数据以外的缓存多长时间,必须设置,否则不会缓存 不是上面的状态码 同一缓存1分钟 |
|
#默认是off | #在被代理的后端服务器出现哪种情况下，可直接使用过期的缓存响应客户端 #示例 |
| proxy_cache_methods GET | HEAD | POST ...; | #对哪些客户端请求方法对应的响应进行缓存，GET和HEAD方法总是被缓存 对方法 缓存 |
（三）清理缓存
缓存不会自动清理 需要手动清理
方法1: rm -rf 缓存目录
方法2: 第三方扩展模块ngx_cache_purge
注意： 在rm -rf proxycache 后 需要nginx -s reload 再次生成proxycache文件夹
（四）示例
66 代理服务机 配置文件
当客户机 访问代理服务器时可以看到生成缓存文件
当我们 关闭真实服务器时，发现客户机 仍能看到内容
五， IP 透传
（一）一级代理
1， 实验环境
66 是代理服务器 99是真实服务器
目前99 服务器查看访问日志 是看不到真实ip的
只能看到66 代理服务器的ip
2, 步骤
第一步
99 真实服务器 需要将日志中的“referer” 开启 （yum安装的nginx 默认开启 编译安装的，需要手动开启）
如果真实服务器是 httpd 在主配置文件改 如图所示：
第二步
66 代理服务器需要改配置文件： proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部
第三步：
此时我们再去让客户机访问 查看99真实服务机的日志 发现可以看到 客户机ip 为11
（二） 多级代理
1，架构
2， 步骤
步骤与一级代理一致
2.1
客户机不需要做配置
2.2
客户机访问代理1 服务器等于访问 代理服务器2
代理1 在主配置文件加 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部
2.3
代理1服务器 访问 代理服务器2 等于访问真实服务器
代理2 在主配置文件加 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #添加客户端IP和反向代理服务器IP到请求报文头部
2.4
真实服务器 改日志格式
六，http反向代理负载均衡
Nginx 可以基于ngx_http_upstream_module模块提供服务器分组转发、权重分配、状态监测、调度算法等高级功能
官方文档： https://nginx.org/en/docs/http/ngx_http_up
简单理解就是 一台代理服务器后面假如有两台真实服务器，怎么最合理分配任务
（一）模块
模块是默认安装的
（二）语法格式
#自定义一组服务器，配置在http块内
upstream web { server 192.168.91.100 调度算法server 192.168.91.101
}location / {
pass_proxy http://web/
}#示例
upstream backend {server backend1.example.com weight=5; 权重server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;server unix:/tmp/backend3;server backup1.example.com backup;
}server address [parameters];
#配置一个后端web服务器，配置在upstream内，至少要有一个server服务器配置。
#server支持的parameters如下：
weight=number #设置权重，默认为1,实现类似于LVS中的WRR,WLC等
max_conns=number #给当前后端server设置最大活动链接数，默认为0表示没有限制
max_fails=number #后端服务器的下线条件,当客户端访问时,对本次调度选中的后端服务器连续进行检测多少次,如果都失败就标记为不可用,默认为1次,当客户端访问时,才会利用TCP触发对探测后端服务器健康性检查,而非周期性的探测
fail_timeout=time #后端服务器的上线条件,对已经检测到处于不可用的后端服务器,每隔此时间间隔再次进行检测是否恢复可用，如果发现可用,则将后端服务器参与调度,默认为10秒
backup #设置为备份服务器，当所有后端服务器不可用时,才会启用此备用服务器 sorry server 自己不能转自己
down #标记为down状态
resolve #当server定义的是主机名的时候，当A记录发生变化会自动应用新IP而不用重启Nginxhash KEY [consistent];
#基于指定请求报文中首部字段或者URI等key做hash计算，使consistent参数，将使用ketama一致性www.kgc.com/test1 hash test1 103 hash算法，适用于后端是Cache服务器（如varnish）时使用，consistent定义使用一致性hash运算，一
致性hash基于取模运算
hash $request_uri consistent; #基于用户请求的uri做hash
hash $cookie_sessionid #基于cookie中的sessionid这个key进行hash调度,实现会话绑定ip_hash;
#源地址hash调度方法，基于的客户端的remote_addr(源地址IPv4的前24位或整个IPv6地址)做hash计算，以实现会话保持least_conn;
#最少连接调度算法，优先将客户端请求调度到当前连接最少的后端服务器,相当于LVS中的WLC
（三）负载均衡实验示例
1， 实验环境
66为代理服务器 77,99 为两台真实服务器
2，步骤
66 代理服务器的主配置文件：
3，实验结果
此为轮询算法 一人一次 总共7种算法，下面依次介绍
（四）健康性检查
1，健康性检查
nginx 非常聪明，把77停了 只会去99
原因： 在轮询前 会三次握手 握不到 就不发过去
2，实验
关闭99 真实服务器 ，发现代理服务器只会去到77 真实服务器
（五）调度算法
轮询 加权轮询 ip hash url hash cookie hash 最少连接数 fair根据响应时间
总共7 种调度算法
1，轮询
默认算法 一人一次
2， 加权轮询
2.1 语法
不写 默认 weight=1
2.2 实验结果
大概 按3比1
3， ip hash
3.1 实现方式
通过客户端的ip 地址 计算出一个值 算出来 访问 真实服务机1 永远访问1
3.2 意义
实现会话保持
3.3 实验步骤
可以看到 第一次在77 服务器 永远在77服务器
3.4 ip hash 弊端
hash 算法 后还要除 总权重
如果你动了权重 可能会导致不正确
4，uri hash
根据访问路径
5，cookie hash
5.1 cookie 原理
5.2 更新的技术
令牌 技术
5.3 实验步骤
6，最少连接数
least_conn;
7，fair 根据响应时间
（六）一些其他设置
这些都是加在 真实服务机后面 例如这样：
| weight=number | #设置权重，默认为1,实现类似于LVS中的WRR,WLC等 |
| max_conns=number | #给当前后端server设置最大活动链接数，默认为0表示没有限制 最大连接数 |
| max_fails=number | #后端服务器的下线条件,当客户端访问时,对本次调度选中的后端服务器连续进行检测多少次,如果都失败就标记为不可用,默认为1次,当客户端访问时,才会利用TCP触发对探测后端服务器健康性检查,而非周期性的探测 max_fails=3 检测3次 3次检测都不回 才觉得死了 |
| fail_timeout=time | #后端服务器的上线条件,对已经检测到处于不可用的后端服务器,每隔此时间间隔再次进行检测是否恢复可用，如果发现可用,则将后端服务器参与调度,默认为10秒 fail_timeout=30s 活了先等30秒在上 |
| backup | #设置为备份服务器，当所有后端服务器不可用时,才会启用此备用服务器 sorry server 自己不能转自己 备份的真实服务机 当其他服务器都挂了 才会启用自己 |
| down | #标记为down状态 死了 |
| resolve | #当server定义的是主机名的时候，当A记录发生变化会自动应用新IP而不用重启Nginx 记录域名 域名对应的ip 变化 |
| hash KEY [consistent]; | #基于指定请求报文中首部字段或者URI等key做hash计算，使consistent参数，将使用ketama一致性 |
七 自定义响应报文头部信息
在 sever 模块添加以下
add_header X-Via $server_addr; 当前nginx主机的IP
add_header X-Cache $upstream_cache_status; 是否缓存命中
add_header X-Accel $server_name; 客户访问的FQDN
add_header name value [always]; 自定义响应报文头部信息
