nginx反向代理

目录

反向代理配置参数

实现反向代理

实现 反向代理 动静分离

实现反向代理缓存

实现ip透传

实现反向代理负载均衡

---

反向代理：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协议转发至指定服务器处理

反向代理配置参数

proxy_pass; 

用来设置将客户端请求转发给的后端服务器的主机，可以是主机名(将转发至后端服务做为主机头首部)、IP地址：端口的方式
也可以代理到预先设置的主机群组，需要模块ngx_http_upstream_module支持

proxy_hide_header field;
用于nginx作为反向代理的时候，在返回给客户端http响应时，隐藏后端服务器相应头部的信息，可以设置在http,server或location块

默认nginx在响应报文中不传递后端服务器的首部字段Date, Server, X-Pad, X-Accel等参数，如果要传递的话则要使用 proxy_pass_header field声明将后端服务器返回的值传递给客户端
field 首部字段大小不敏感
示例:透传后端服务器的Server和Date首部给客户端,同时不再响应报中显示前端服务器的Server字段
proxy_pass_header Server;
proxy_pass_header Date;

proxy_pass_request_body on | off; 
是否向后端服务器发送HTTP实体部分,可以设置在http,server或location块，默认即为开启

proxy_pass_request_headers on | off; 
#是否将客户端的请求头部转发给后端服务器，可以设置在http,server或location块，默认即为开启

实现反向代理

配置代理服务器

访问192.168.94.7

在真实服务器上 做防火墙规则
iptables -A INPUT  -s 192.168.91.100 -j DROP
客户端再次访问  会出现504网关超时（有可能只是处理时间久，服务器不一定挂了），时间较长1分钟，没有定义代理超时时间

iptables -A INPUT  -s 192.168.91.100 -j REJECT
客户端再次访问  会出现502，一般出现502 代表后端真实服务器挂了

针对url 的访问

实现 反向代理 动静分离

这是192.168.94.8

这是192.168.94.9

实现反向代理缓存

关闭后端服务器后，图片无法访问

缓存功能默认关闭，需要开启

proxy_cache zone_name | off; 默认off
#指明调用的缓存，或关闭缓存机制;Context:http, server, location
#zone_name 表示缓存的名称.需要由proxy_cache_path事先定义

proxy_cache_key string;
#缓存中用于“键”的内容，默认值：proxy_cache_key $scheme$proxy_host$request_uri;

proxy_cache_valid [code ...] time;
#定义对特定响应码的响应内容的缓存时长，定义在http{...}中
 示例:
 proxy_cache_valid 200 302 10m;
 proxy_cache_valid 404 1m;

#示例：在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; #最大磁盘占用空间，磁盘存入文件内容的缓存空间最大值

proxy_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | off ; #默认是off
#在被代理的后端服务器出现哪种情况下，可直接使用过期的缓存响应客户端

#示例
proxy_cache_use_stale error http_502 http_503;

proxy_cache_methods GET | HEAD | POST ...;
#对哪些客户端请求方法对应的响应进行缓存，GET和HEAD方法总是被缓存

实现

先改主配置文件

访问

查看缓存

停掉其中一个服务

还能访问

还可以通过添加一些字段来查看更具体的信息

     add_header X-Via $server_name;   当前nginx主机的ip
     add_header X-Cache $upstream_cache_status;  是否缓存命中  命中hid 未命中 miss
     add_header X-Accel $server_name;  客户端访问的域名

再停掉

刷新页面

如果要清理缓存 直接删掉即可  如我这边是在/data/nginx/proxycache下 直接

rm -rf /data/nginx/proxycache/*  即可

实现ip透传

访问

查看日志

实现多台透传

都用nginx   yum 安装的html 在 usr/share/nginx/html下  建议修改一下页面

实现反向代理负载均衡

在上一个节中Nginx可以将客户端的请求转发至单台后端服务器但是无法转发至特定的一组的服务器，而且不能对后端服务器提供相应的服务器状态监测，Nginx 可以基于ngx_http_upstream_module模块提供服务器分组转发、权重分配、状态监测、调度算法等高级功能

192.168.94.8

192.168.94.9    

192.168.94.7

调度算法： 代理服务器怎么把请求分配给后端服务器
轮询  nginx默认使用的是轮询  nginx有健康检查 如果有服务器挂了，不会再分配给该服务器
加权轮询  weight

     
hash    1.ip  hash 2.url hash 3.cookie hash  

最少连接数
fair  根据响应时间

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而不用重启Nginx

hash 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;
每个请求按访问IP的hash结果分配，同一个IP客户端固定访问一个后端服务器。可以保证来自同一ip的请求被打到固定的机器上

url_hash;

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器。一旦缓存住了资源，再次收到请求，就可以从缓存中读取。

cookie hash;

在Nginx中，实现基于Cookie的会话保持（Session Persistence）通常涉及到使用一个自定义的cookie或利用已存在的session cookie来决定将请求转发到哪个后端服务器。这种技术有时被称为“Cookie Hash”或“Cookie Stickiness”

least_conn;
最少连接调度算法，优先将客户端请求调度到当前连接最少的后端服务器,相当于LVS中的WLC