就是假设有一个内网
内网有两台机器,这两台机器只有 a 可以上网
b 不能上网,但是 a 和 b 通过网络相连接
这时如果 b 想访问外网,就可以通过 a 来正向代理访问外网
正向代理就是在内网中模拟目标服务器,把内网中其它机器的请求
转发给外网中的真正的目标服务器
所以正向代理是接受内网其它机器的请求的
反向代理则是反过来
也是一个内网,有几台机器,只有其中一台与外网连接
但是反向代理接受的不是内网机器的访问请求
反向代理接受的是外网过来的访问请求
然后把请求转发到内网中的其它机器上去
外网发出请求的用户并不知道反向代理的服务器把请求转发给了谁
要在一台机器上设置正向代理的功能
如图,编辑一个nginx配置文件
上图就是配置文件内容
如果配置一台服务器作为正向代理服务器
那么这个虚拟主机配置文件就必须是默认虚拟主机
因为所有访问这台机器的网络请求应该先访问这个虚拟主机才对
所以这里要设置 default_server
然后还要把原来的 默认虚拟主机 配置文件名称修改掉
如图,把 default.conf 配置文件的名称修改一下
这样就取消了原来的默认虚拟主机配置文件了
因为默认的默认虚拟主机配置文件就是 default.conf
配置文件里面的 resolver 119.29.29.29
意思是配置一个 dns 地址
因为是做正向代理,接受了内网请求的域名后
要把请求发送给真正要访问的服务器
但是内网发送的域名是没有包含 ip 地址的
所以还要把域名发送给 dns 服务器解析 ip 地址
拿到 ip地址后才能转发到要访问的服务器上去
所以这里需要配置一个 dns 地址
接受了内网域名后,就会把域名发送到这个 dns 上去解析
下面的 location 按照图中设置就可以了
这样正向代理服务器接受内网机器请求后
就会把域名发到配置的dns上解析,然后访问真正的服务器
再把真正服务器返回的内容发送给发出请求的内网机器
做一个反向代理的例子
如图建立一个测试的虚拟主机配置文件
监听 8080 端口,域名为 www.test.com
根目录是 /data/wwwroot/test.com
访问虚拟主机显示的首页文件是 index.html
如图,创建虚拟主机的根目录 /data/wwwroot/test.com
然后使用 echo "test.com_8080" > !$/index.html
创建一个内容为 test.com_8080 的首页文件
这个文件在 /data/wwwroot/test.com 目录里面
如图,新建一个反向代理的虚拟主机配置文件
监听 80 端口,域名为 www.test.com
下面的 location / 里面就是反向代理的配置
当访问这个虚拟主机的时候,就会把访问请求发送给 127.0.0.1:8080
如图,使用 curl 访问 127.0.0.1:8080 虚拟主机
成功返回了 test.com_8080 这说明这个虚拟主机能够被访问
如图,再创建一个虚拟主机配置文件
跟之前的 test 虚拟主机差不多
但是这个虚拟主机并没有设置 域名
location 设置返回的内容是 8080 default 字符串
保存退出,重载 nginx
还要把 test虚拟主机的 default server 设置取消掉
那么现在 127.0.0.1:8080 对应两个虚拟主机
一个是 test 虚拟主机,另外一个是 8080 default 虚拟主机
这两个虚拟主机的 ip 端口都是一模一样的
它们的区别是 test 虚拟主机是有域名的
而 8080 default 虚拟主机是没有域名的
现在已经设置了 8080 default 为默认虚拟主机
所以如果只访问 127.0.0.1:8080 的话
访问的一定是 8080 default 虚拟主机
如果想访问 test 虚拟主机,就需要加上 test 虚拟主机的域名
才能成功访问 test 虚拟主机
如图,可以看到访问 curl 127.0.0.1:8080/ 返回的结果是 8080 default
使用 curl -x127.0.0.1:8080 www.test.com
这里带上了域名,返回的就是 test.com_8080
说明想访问 test 虚拟主机,ip端口还需要绑定域名才行
如图,curl 访问 127.0.0.1:80 域名 www.test.com
返回的是 test.com_8080 说明这个反向代理成功了
我们访问的是 80 端口,实际却返回了 8080 端口的虚拟主机的内容
如图,这里把反向代理虚拟主机里面的 proxy_pass 行下面的都注释掉
保存退出,重载 nginx
如图,再使用 curl 访问 127.0.0.1:80 域名 www.test.com
实际返回的却是 8080 default
而我们想访问的却是 test 虚拟主机
如图,proxy_set_header Host $host;
这一行代码就是指定访问的域名
上面设置了 127.0.0.1:8080
反向代理的时候就会指向这个 ip端口
如果不设置 host 那就只会访问 127.0.0.1:8080 的虚拟主机
如果设置了 host ,那么就会指向跟指定的 host 绑定的 127.0.0.1:8080
这里的 $host 是系统变量,实际的值就是当前的虚拟主机的 server_name
也就是 www.test.com ,server_name 是什么,host的值就是什么
这里设置了 host 就相当于 curl -x127.0.0.1:8080 www.test.com
如果这里不设置 host 那么就只会访问 127.0.0.1:8080
这样就可以把 域名 跟 ip端口进行绑定
如图,除了写 ip端口之外,proxy_pass 也可以直接写域名
这里写的是 www.123.com:8080/
但是这样写的话, nginx 并不知道这个域名指向哪里
所以还需要在系统里面绑定对应的 ip
例如在 /etc/hosts 文件里面,写入对应的 域名和 ip 进行绑定
这样nginx 里面的 proxy_pass 的域名系统就会解析出一个 Ip 地址
然后再访问这个 ip端口
下面的 proxy_header Host 作用就是设置一个 域名
这个域名会与上面的 ip端口绑定访问
如果上面的 ip端口 写的不是 ip 而是域名
跟下面指定的域名是不冲突的,因为上面写的域名的作用是用来解析ip的
下面指定的域名才会跟上面解析出来的 ip端口进行绑定访问
这个例子使用的是 $host 这是 nginx全局变量
这个变量实际是对应了一个值的,就是当前虚拟主机 server_name 的值
但是一般来说,还是直接写 ip 端口方便一些
上面就是指定 ip端口
下面指定跟 ip端口绑定的 host 域名
如图,proxy_pass 指令后面可以跟 url
有三种格式,传输协议+域名+uri (访问路径)
传输协议+ip端口+uri
传输协议+socket
这里 unix ,http ,https 都是传输协议的种类
域名+uri 和 ip端口+uri 还有 socket 都是访问的路径
socket 一般是某个程序专用的访问端口
访问某个socket就是访问某个特定的程序,所以不需要使用路径
如图,写 proxy_pass 的时候,不同的写法有不同的结果
比如 location /aming/
如果访问的路径包含 /aming/ 就会触发
这里的proxy_pass 就会执行
但是location 里面的 proxy_pass 不同的写法会导致实际访问的路径有差别
虽然因为访问的路径包含 /aming/ 目录才执行 proxy_pass
但是实际访问的路径不一定包含 /aming/
这个例子是访问虚拟主机内的 /aming/a.html 文件
根据 proxy_pass 的不同写法实际上会访问到不同的路径去
如果 ip端口 后面没有接任何目录符号
就会访问 /aming/a.html,这是我们想要的
如果 ip端口后面接了根目录符号 /
那么就会直接访问根目录里面的 a.html文件,这显然不对
ip端口后面接 /linux/ 那么就会访问 /linux/ 里面的 a.html文件
如果 ip端口后面是 /linux 最后没有跟目录符号 /
就会访问 /linuxa.html
所以如果想正确访问 /aming/a.html
有两种写法,一种是 ip端口后面不要加任何目录符号 /
第二种是完整的写成 ip端口/aming/ 这样写
根据上面示例可以发现,ip端口后面不管是什么目录
实际访问路径就会变成直接把最终要访问的文件名称 a.html
直接添加到 ip端口 后面的目录上去
所以 ip端口后面不写任何目录符号的话,系统才会自己添加 /aming/a.html 这个目录路径
一旦有任何目录符号存在,就会直接把 a.html 放在这个目录符号后面
第二种情况是,ip端口+ /linux
实际结果是访问 /linuxa.html
这可能是因为 linux 后面没有跟上任何目录符号 /
所以系统把 linux 认为是一个没有写完的文件名称
然后就直接把 a.html 这个文件名称跟 linux 粘贴在一起
这样就变成了要访问的文件是 /linuxa.html 的形式
所以不管写什么路径,后面一定要跟上目录符号 /
如图,proxy_set_header 是设置被代理的服务器可以接收到的 header 信息的
比如有三台电脑 a b c
a 是我们用来访问的电脑,我们从 a 发出访问请求
b 是反向代理服务器,b 接收我们发出的访问请求
c 是被反向代理的服务器,也就是我们真正要访问的服务器
b 会把我们的访问请求转发给 c
如果不设置 proxy_set_header 的话,b 转发请求给 c 的时候就不会带上相应的 header 信息
如果设置了这个参数,在转发请求的时候就会带上对应的 header 信息
其中 $remote_addr 和 $proxy_add_x_forwarded_for 这两个变量是 nginx 的内置变量
$remote_addr 变量里面保存的是 b 反向代理服务器本身的 ip 地址
$proxy_add_x_forwarded_for 变量里面保存的是 a 客户端电脑的 ip 地址
如果不设置这个变量的话,c 服务器实际上是不知道访问请求的真实来源地址的
而设置了这个变量, c 服务器就可以知道这个访问请求是哪一个ip地址发过来的
如图,编辑 www.test.com 虚拟主机的配置文件
假设这个虚拟主机是我们要访问的 c 服务器
location 里面设置了两个echo 显示访问请求的来源地址,和真实来源地址
$remote_addr 记录了反向代理服务器的地址
$proxy_add_x_forwarded_for 记录了访问请求的真实来源地址,也就是客户端的地址
这样设置,访问这个虚拟主机的时候,就会显示这两个变量里面保存的值
保存退出,然后重载配置文件
如图,编辑反向代理服务器虚拟主机的配置文件
如图,可以看到 location 里面
proxy_set_header X-Real-IP 和 proxy_set_header X-Forwarded-For 这两行是被注释掉的
先做个测试,保存退出重载配置文件
如图,使用 curl 测试从 192.168.133.140:80 发出访问请求
192.168.133.140 这个 ip 实际就是 客户端 ip
因为访问请求就是从这个 ip 发出来的
但是可以看到,测试之后,实际显示的却是两个 127.0.0.1 的回环地址
并没有 192.168.133.140 这个 ip
在这个测试里面,反向代理服务器 和 真实服务器 都在本机上面
所以真实服务器 c 接收的访问请求来源 ip 就是本机的回环地址
反向代理服务 b 发送请求给 真实服务器 c 走的就是 127.0.0.1 的内部回环地址
因为这两个服务器都在本机上,本机上的程序之间通讯基本都是走 127.0.0.1 回环地址的
所以 c 的 $remote_addr 的值就是 127.0.0.1
因为反向代理服务器 b 没有设置 $proxy_add_x_forwarded_for
所以真实服务器 c 的接收到的 $proxy_add_x_forwarded_for 变量值就是请求发送过来的 ip
也就是 127.0.0.1
$proxy_add_x_forwarded_for 这个变量实际上是记录了从客户端开始
请求总共经过了哪些 ip 地址的一个变量值,多个 ip 地址之间使用逗号分隔
如果发送的访问请求没有设置 $proxy_add_x_forwarded_for 这个变量的话
那么接收方的这个变量的值就只是访问请求发送过来的上一个 ip , 也就是跟 remote_addr 相同
比如访问请求从 a 到 b 到 c
如果 b 设置了 $proxy_add_x_forwarded_for 的话
那么这个变量的格式就是 a_ip, b_ip
也就是记录了 a 的ip 和 b 的ip
如果中间还经过更多的服务器的话,那么它们的 ip 也会被记录下来,使用逗号分隔
当然每一台代理服务器都需要设置 $proxy_add_x_forwarded_for 这个变量才行
不然下一台代理服务器的 $proxy_add_x_forwarded_for 这个变量将不会记录到之前经过的 ip
只能够记录到上一台服务器的 ip
所以在这个测试里面,因为 b 没有设置 $proxy_add_x_forwarded_for
所以 c 服务的 $proxy_add_x_forwarded_for 变量的值等于 $remote_addr 的值
如图,第二次测试,编辑反向代理服务器 b 的配置文件
把 location 里面的 X-Real-IP 和 X-Forwarded-For 两行注释去掉
保存退出重载配置文件
如图,再次测试
可以看到返回的结果,第一行 remote_addr 的值是 127.0.0.1
这是 代理服务器 b 的 ip
第二行 $proxy_add_x_forwarded_for 的值是两个 ip
curl 命令里面,访问请求是从 192.168.133.140 发出的
也就是说,客户端 a 的 ip 就是 192.168.133.140
b 的 ip 就是 127.0.0.1
$proxy_add_x_forwarded_for 记录的是到达 c 的访问请求经过了哪些 ip
访问请求是从 a 到 b 再从 b 到 c 的
所以 $proxy_add_x_forwarded_for 变量 记录了 a 的 ip 和 b 的 ip
因为访问请求在到达 c 之前经过了这两个 ip 地址
所以以后做反向代理的时候,这几行变量都要设置
后面的真实服务器才能够获取到访问请求的真实 ip 地址
如图,redirect 应用的场景不多,主要有三种写法
功能是修改被代理的服务器返回的 location 和 refresh 头域信息
第一种写法,redirect 是返回的头域信息
replacement 是要修改的信息
redirect 会被修改为 replacement
第二种写法是 default 就是默认设置的意思
第三种 off 意思就是关闭 redirect功能
如图,做一个测试,编辑代理服务器的配置文件
要测试成功有几个条件要达成
首先,location 后面只能是根目录 / 不能是加别的
第二个条件是proxy_pass后面的 url 后面不能加 / 符号
正常来说是要 / 结尾的,但是这里不能用 / 结尾
然后访问的目录必须真实存在,如果不存在可以创建一个
然后再目录里面也可以创建一个 index.html 文件,里面编辑一些字符串内容
保存退出重载一下配置文件
如图,编辑被代理服务器的配置文件
写成如图所示的这种简单格式
保存退出重载配置文件
如图,curl 测试访问的时候,如果 aming 后面加了 / 结尾,那么就会访问到 index.html 文件
但是我们要访问的是目录本身,并不是里面的某个文件
所以 crul 的时候,访问的地址结尾不能加上 / 符号
这样就可以访问到 aming 目录了
可以看到,返回的代码是 301 表示永久重定向
下面的 location 后面的字段,是带端口8080 的访问路径
如图,编辑被代理服务器的配置文件
添加 access_log /tmp/456.log
这样就开启了服务器的访问日志,检查访问日志可以更清晰的了解访问过程
保存退出重载
如图,重新 curl 测试一次,这次测试 aming 结尾是带 / 符号的
cat 查看 /tmp/456.log 访问日志
发现日志信息没有 host 和 端口 等信息
这种情况可以修改 nginx.conf 配置文件里面的 format 配置
如图,配置文件里面 log_format main 这三行本来是被注释掉的
现在把注释去掉,让这几行产生作用,这个就是日志返回信息的格式设置
如图,在最后面添加两个nginx变量 $host $server_port 这两个变量
然后保存退出重载一下,这样访问日志显示的信息里面,就会加上这两个变量的信息了
如图,编辑代理服务器配置文件,同样添加 access_log 配置
日志地址就是 /tmp/proxy.log
后面加上 main 因为 nginx.conf 里面配置的格式是用 main 命名的
这里加上main 表示使用 main 命名的格式来显示日志信息
如图,同样被代理服务器里面的 access_log
后面也需要加上 main表示使用 main 的格式显示日志信息
保存退出重载一下
如图,curl 测试一下,这次测试是用 / 符号结尾的
查看 456.log 后端服务器的日志,可以看到,访问的是 8080 端口
查看 proxy.log 代理服务器日志,可以看到,访问的是 80 端口
网络代码都是 200 这样是正常的
如图,这次访问 aming 结尾不带 / 符号
可以看到返回的是 301
查看 proxy.log 返回的也是 301
如图,重新测试一下,再查看两个日志
看到 301 再到 200 的日志信息
总之确定了我们访问 80 端口,跳转到了 8080 端口
但是客户端是访问不到 8080 端口的
如图,解决这个问题可以使用 proxy_redirect
这里是 http://$host:8080/ /;
这样写可以把本来返回的 8080 端口信息给去掉
保存退出重载
如图,重新测试
可以看到,返回的是 301
然后 location 后面的地址里面,也没有 8080 端口的信息存在了
proxy_buffering 是缓冲的意思
缓冲就是在内存里面划一块区域,在里面写数据
写到一定量的时候,才会把缓冲里面的数据写进硬盘中
这样做的话,就可以大大减少硬盘的读写频率
如果不做缓冲,每产生一次数据都要读写一次硬盘,对于硬盘的负担就会很大
假设有三个对象,客户端 a 代理服务器 b 被代理服务器 c
a 发出请求,b 接收请求,转发给 c
c 返回数据给 b ,然后 b 再把数据发给 a
这是一般的运作情况,但是如果 a 发出许多访问请求
或者有很多个客户端发出访问请求
那么对于代理服务器 b 和 被代理服务器 c 来说
每个请求都要按照这个流程处理一次,负担就会很重
proxy_buffering 就是在 代理服务器 b 的内存里面设置一个或多个缓冲区域
当缓冲区域数据量满了的时候,才把数据转发给相应的客户端
这样代理服务器 b 的数据转发次数就大大减少了,负担就下降了
当 proxy_buffering 开启的时候,由 proxy_busy_buffer_size 来决定何时把数据发送给 a
在这个过程中,如果 buffer 区域被写满,有数据溢出
多出来的数据会被写入到 temp_file 也就是一个临时文件中去,这个文件会存储在硬盘上
如果 proxy_buffering 关闭的话,c 反馈的数据就直接由 b 转发给 a
而不会有别的操作发生
如图,不管 proxy_buffering 是 on 还是 off 的状态
proxy_buffer_size 这个选项都是生效的,这个参数是用来设置一个 buffer
这个 buffer 存储了服务器反馈的 header 信息
如果设置不够大,存储不了 header 信息的话,会出现 502 错误码
所以建议设置为 4k
如图, proxy_buffers 是定义每个请求的 缓冲区个数 和 每个缓冲区的具体大小
这里定义了 8 4k 意思就是有 8个缓冲区,每个缓冲区的大小为 4k
那么总缓冲区的大小就是 8*4 = 32 k
假设有一万个请求,那么缓冲区就是 8 * 10000 个缓冲区了
因为这个设置是针对每个请求来的,而不是总共只有 8 个缓冲区
proxy_busy_buffer_size 定义的是达到多少数据量,就把数据传输给客户端
这里定义的是 16k ,那么当 b 的属于这个请求的缓冲区接收到 16k 的数据量的时候
就会把数据转发给 a
这里缓冲区有 8 个,总共 32k 的大小,缓冲区一般来说处于两种状态
一个是接收数据,一个是发送数据,并不能同时接收数据和发送数据
proxy_busy_buffer_size 定义的就是 发送数据的缓冲区的大小
所以 proxy_busy_buffer_size 的大小要比缓冲区的总大小要小才行
接收的数据达到 proxy_busy_buffer_size 设置的数据量的时候
这些缓冲区就进入发送数据的状态,剩下的缓冲区则是接收数据的状态
如果请求反馈的数据总量小于 proxy_busy_buffer_size 设置的值
那么 b 接收完成就会直接转发为 a
如果请求反馈的数据总量大于 proxy_busy_buffer_size 设置的值
那么当缓冲区接收的数据量达到 proxy_busy_buffer_size设置的值的时候
就会把这部分的数据先发送给 a
如图,proxy_temp_path 定义的是临时文件存放目录
举例,a 发出请求,b代理服务器分配给 a 这个请求的 缓冲区 总大小为 32k
但是 c 服务对这个请求反馈的数据量为 100 MB 这么大,远远超过缓冲区的大小
这种情况下, b 接收 c 的数据的过程中就会有很多数据溢出缓冲区
这些溢出的数据会被先保存到 b 的硬盘上的临时文件里面去
proxy_temp_path 定义的就是这个临时文件存放的路径,还有子目录层级
这里定义的路径是 /usr/local/nginx/proxy_temp 这是一个目录名称
临时文件就会存放到这个目录里面去
后面的数字 1 2 表示子目录层级
前面的目录路径是由我们自己定义的,子目录是系统自动创建的
创建多少个子目录层级,可以通过后面的数字设置
比如 只写一个 1 就表示子目录只有一层,子目录的名称为 0-9 的命名方式
根据定义,proxy_temp_path 支持三级子目录,也就是可以写 3 个数字
比如写 1 子目录数量和命名方式 就是 0- 9 共10个
如果写 2 就是 00-99 共100个,如果写 3 就是 000-999 共1000个子目录
子目录名称也是根据这些数字来命名的
如果写 1 3 就表示子目录分两层,第一层是 0-9 10个子目录
第二层是 000-999 1000个子目录,也可以反过来写 3 1
这样第一层就是 1000 个子目录,每个目录下面第二层又有 10 个子目录
proxy_max_temp_file_size 定义的是 临时文件的总大小
比如这里设置为 100M 说明每个临时文件最大为 100M
临时文件的数据如果传输完成,就会自动删除
proxy_temp_file_write_size 定义的是同时写入临时文件数据量的总大小
这里定义一个值比如 8k 或者 16k
如果同时写入的数据量低于这个值,那么就增加同时写入的数据量
如果高于这个值,那么就减少同时写入的数据量
因为同时写入的数据量太高,对于硬盘 IO 负担太大,而太小则没有充分用到硬盘的性能
所以设置一个值,既不会太快,也不会太慢,充分使用到硬盘的性能,又不会负担过重
如图,这是一个使用 proxy_buffering 的例子
首先是设置为 on 的状态,也就是打开 buffer 功能
头文件存储的 buffer区域大小为 4k
然后是其它数据的 buffer 区域为 2 个,每个大小为 4k
然后是 busy_buffers 的数据量为 4k
buffer 接收的数据量达到 4k 时就会发送数据
然后是临时文件存放的路径定义,定义了两层子目录
分别是 1 2 也就是 第一层有 0-9 10个子目录
然后每个子目录下面 第二层有 00-99 100个子目录
然后是每个临时文件的大小为 20M
然后是临时文件同时写入的数据量定义为 8k
如图,要使用 proxy_cache 首先要打开 proxy_buffering 功能
proxy_cache 就是缓存功能
客户端 a 发出请求,如果 a 请求的数据已经保存到 代理服务器 b 的缓存里面的话
那么 b 会把相关数据直接发送给 a 而不会去向 服务器 c 请求数据
如果不开启缓存功能,那么 a 的每一次请求,代理服务器 b 都会向 服务器 c 请求获取一次数据
如果 a 两次请求的数据是一样的,也会向 服务器 c 请求两次数据
开启缓存功能的话,第一次请求的数据已经被保存到 缓存里面了,第二次如果请求同样的数据
b 就会直接从缓存里面获取,而不会去向 c 获取数据,这样就减轻了 服务器 c 的负担
总结,缓冲可以减轻 代理服务器b 的负担,缓存可以减轻 被代理服务器 c 的负担
如图,proxy_cache 功能的开启与关闭
proxy_cache off 意思就是关闭缓存功能
proxy_cache zone 就是开启缓存区,zone 就是缓存区的名称
缓存区名称是可以任意命名的,可以是 zone 也可以是 123 等任意名称
这里写一个缓存区名称就表示了开启一个以这个名称命名的缓存区
从 nginx 0.7.66 版本开始,开启 proxy_cache 之后
还会检测被代理服务器的 http 响应头中的 Cache-Control ,Expire 头域
如果 cache-control 的值为 no-cache 时,那么这个请求的数据是不会被缓存的
如图,curl -I 一个网站请求数据
可以看到,返回的头文件信息,Cache-Control 后面的值里面
存在 no-cache ,表示这个请求返回的数据是不会被缓存的
如图,proxy_cache_bypass 这个参数是设置某种情况下
请求的数据不从 cache 中获取,而是直接从后端服务器中获取
这个参数后面的 string 一般为 nginx 的一些变量
比如 proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;
这样设置就表示,这三个变量的值,任意一个不为 0 或 空 的情况下
响应数据就不会从 cache 中获取,而是直接从后端服务器获取
暂时很少用到,了解一下即可
如图,proxy_no_cache 跟上面的参数用法相似
主要是设置某种情况下,获取的数据不进行缓存
示例 proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;
这样设置就表示,当后面这三个变量任意一项的值不为 0 或者 空 的时候
获取的数据都不进行缓存
如图,这个参数格式跟上面的参数差不多,一般不需要设置,保持默认就可以了
如图,proxy_cache_path 是设置缓存区具体配置的参数
缓存除了内存中的空间外,还可以在硬盘中划出一块空间来做缓存
path 就是指定一个目录路径作为缓存路径,缓存会存放到这里面
levels=1:2 这个表示目录层级,第一个数字设置的是第一层
第二个数字设置的是第二层
1 表示 0-9 a-f 总共16个字符,每个目录由单个字符组成,一共16个目录
2 表示 0-9 a-f 总共16个字符,但是每个目录由两个字符组成,00,01,04,2f 之类的,有两百多种组合
总之这个参数是设置子目录层级,第一个数字表示第一层
第二个数字表示第二层
keys_zone 是设置内存zone 的名称和大小
keys_zone=my_zone:10m 就表示zone的名称叫做 my_zone
然后 zone 的大小是 10MB
inactive 是设置多长时间后,把缓存删除
比如图中设置为 300s 意思就是,如果数据在 300秒内没有被访问过
那么这个数据就会从缓存中删除
max_size 是设置硬盘中的缓存最多可以存储多少数据
比如这里设置为 5g ,上面设置的目录 /data/nginx_cache/
这个硬盘上的目录,最多可以存放 5g 的数据,如果超过这个量
系统就会先把访问量最少的数据删除,再放新的数据进去
proxy_cache_path 这行代码不能写在 配置文件的 server 括号内
要写在 http 括号里面
举例说明,首先编辑 nginx.conf 配置文件
如图,在 server 的外面添加 proxy_cache_path 代码
如图,
因为指定的缓存目录 /data/nginx_cache/ 不存在,所以这里要创建一下
如图,编译一个虚拟主机的配置文件,在location 里面添加 proxy_cache my_zone;
这样这个虚拟主机接收请求的时候,就会使用 my_zone 这个缓存空间了
而 my_zone 缓存空间的具体定义已经在 nginx.conf 配置文件里面作了定义
nginx.conf 里面的配置内容对所有虚拟主机都是有效的
所以在 nginx.conf 里面定义了 my_zone 的话
那么在所有虚拟主机配置文件里面使用 proxy_cache my_zone
这些虚拟主机就都可以使用到 my_zone 这个缓存空间
然后保存退出重载配置文件就可以生效了
平时使用,只需要添加这样两行代码就成功配置好缓存了
如图,还有一个问题就是,nginx 服务本身的权限是 nobody
刚才的目录是使用 root 权限创建的
所以这里要把 缓存目录 的所有者所属组修改成 nobody
这样nginx 服务操作这个目录的时候就不会有权限问题了
如图,查看 /data/nginx_cache/ 目录内容
可以看到 0-9 a-f 的第一级目录
进入 0 目录内查看,可以看到由两位数构成的 第二级目录
总结,缓存空间配置主要就是定义 proxy_cache_path
可以在 nignx.conf 里面定义,这样任何虚拟主机都可以使用到
定义好 proxy_cache_path 后,在需要使用缓存的虚拟主机 server内
配置 proxy_cache zone_name
zone_name 就是 proxy_cache_path 里面定义好的缓存空间名称
这样对应的虚拟主机就可以使用这个缓存空间了
以上就是nginx正向代理与反向代理详解的详细内容,更多关于nginx正向代理与反向代理的资料请关注小牛知识库其它相关文章!
主要内容:1. 代理服务器介绍,2. 将请求传递给代理的服务器,3. 传递请求标头,4. 配置缓冲区,5. 选择传出IP地址本文介绍代理服务器的基本配置。 您将学习如何通过不同协议将NGINX请求传递给代理的服务器,修改发送到代理服务器的客户端请求标头,以及配置来自代理服务器的响应缓冲。 代理服务器的基本配置目录 代理服务器介绍 将请求传递给代理的服务器 传递请求标头 配置缓冲区 选择传出IP地址 1. 代理服务器介绍 代理通常用于在多个服务器之间分配负载,无缝地显示来自不同网站的内容,或者通过
Nginx 是一个高性能的 HTTP 和反向代理服务器,代码完全用 C 实现,基于它的高性能以及诸多优点,我们可以把它设置为 hyperf 的前置服务器,实现负载均衡或 HTTPS 前置服务器等。 配置 Http 代理 # 至少需要一个 Hyperf 节点,多个配置多行 upstream hyperf { # Hyperf HTTP Server 的 IP 及 端口 server
本文向大家介绍nginx反向代理webSocket配置详解,包括了nginx反向代理webSocket配置详解的使用技巧和注意事项,需要的朋友参考一下 最近在做项目的时候用到了webSocket协议,而且是在微信小程序中用到了webSocket,微信小程序中使用wss协议的时候不能设置端口,只能使用默认的443端口。我擦,我的https已经监听了443端口,webSocket再去监听443,肯定不
我有一个与节点.js服务器通信的小角度应用程序。两者都部署在 aws 上,我使用 Nginx 反向代理在端口 4000 上访问节点.js服务器。 nodejs.server 的所有endpoint都工作正常,除了 socket.io 连接。当我在我的机器中运行两个应用程序(前端应用程序和节点.js服务器)时,socket.io 连接工作正常,但是当我尝试在 aws 上部署它时,我在前端应用程序中收
Nginx的配置文件如下: server { listen 80; #此处应该配置你的域名: server_name doc.iminho.me; charset utf-8; #此处配置你的访问日志,请手动创建该目录: access_log /var/log/nginx/webhook.iminho.me/access.log
本小节,我们继续学习 Nginx 在 七层反向代理中的其它几种比较常见的情况,比如 web 服务中的 WebSocket 协议的反向代理和 uwsgi 协议的反向代理。 1. WebSocket的反向代理 WebSocket 是目前比较成熟的技术了, WebSocket 协议为创建客户端和服务器端需要实时双向通讯的 webapp 提供了一个选择。服务器可以向浏览器推送相关消息,这样在前端实现的某个