1 Nginx是什么
1.1 Nginx简介
Nginx 是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点开发的。
Nginx 是开源、高性能、高可靠的 Web 和反向代理服务器,而且支持热部署,几乎可以做到 7 * 24 小时不间断运行,即使运行几个月也不需要重新启动,还能在不间断服务的情况下对软件版本进行热更新。性能是 Nginx 最重要的考量,其占用内存少、并发能力强、能支持高达 5w 个并发连接数,最重要的是, Nginx 是免费的并可以商业化,配置使用也比较简单。
1.2 Nginx用途
1.2.1 静态HTTP服务器
Nginx作为HTTP服务器,可以将服务器上的静态文件(如HTML、图片)通过HTTP协议展现给客户端。
现在很流行动静分离,就可以通过Nginx来实现。
动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来。
动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路。
1.2.2 反向代理服务器
1.2.2.1 什么是反向代理
正向代理
正向代理是为我们服务的,即为客户端服务的,客户端可以根据正向代理访问到它本身无法访问到的服务器资源。正向代理对我们是透明的,对服务端是非透明的,即服务端并不知道自己收到的是来自代理的访问还是来自真实客户端的访问。
反向代理
反向代理是为服务端服务的,反向代理可以帮助服务器接收来自客户端的请求,帮助服务器做请求转发,负载均衡等。反向代理对服务端是透明的,对我们是非透明的,即我们并不知道自己访问的是代理服务器,而服务器知道反向代理在为他服务。反向代理的优势:
- 隐藏真实服务器;
- 负载均衡便于横向扩充后端动态服务;
- 动静分离,提升系统健壮性;
1.2.3 负载均衡
一般情况下,客户端发送多个请求到服务器,服务器处理请求,其中一部分可能要操作一些资源比如数据库、静态资源等,服务器处理完毕后,再将结果返回给客户端。
这种模式对于早期的系统来说,功能要求不复杂,且并发请求相对较少的情况下还能胜任,成本也低。
随着信息数量不断增长,访问量和数据量飞速增长,以及系统业务复杂度持续增加,这种做法已无法满足要求,并发量特别大时,服务器容易崩。
很明显这是由于服务器性能的瓶颈造成的问题,除了堆机器之外,最重要的做法就是负载均衡。
请求爆发式增长的情况下,单个机器性能再强劲也无法满足要求了,这个时候集群的概念产生了,单个服务器解决不了的问题,可以使用多个服务器,然后将请求分发到各个服务器上,将负载分发到不同的服务器,这就是负载均衡,核心是「分摊压力」。
Nginx 实现负载均衡,一般来说指的是将请求转发给服务器集群。
举个具体的例子,晚高峰乘坐地铁的时候,入站口经常会有地铁工作人员大喇叭“请走B口, B口人少车空....”,这个工作人员的作用就是负载均衡。
1.2.4 虚拟主机
有的网站访问量大,需要负载均衡。然而并不是所有网站都如此出色,有的网站,由于访问量太小,需要节省成本,将多个网站部署在同一台服务器上。
例如将A和B两个网站部署在同一台服务器上,两个域名解析到同一个IP地址,但是用户通过两个域名却可以打开两个完全不同的网站,互相不影响,就像访问两个服务器一样,所以叫两个虚拟主机。
1.3 Nginx特点
- 高并发、高性能;
- 模块化架构使得它的扩展性非常好;
- 异步非阻塞的事件驱动模型这点和
Node.js相似; - 相对于其它服务器来说它可以连续几个月甚至更长而不需要重启服务器使得它具有高可靠性;
- 热部署、平滑升级;
- 完全开源,生态繁荣;
2 Nginx怎么用
2.1 安装
自行搜索安装教程
windows下可使用服务注册工具将nginx注册为服务
linux下通过systemctl相关命令进行管理
systemctl 系统命令:
# 开机配置
systemctl enable nginx # 开机自动启动
systemctl disable nginx # 关闭开机自动启动
# 启动Nginx
systemctl start nginx # 启动Nginx成功后,可以直接访问主机IP,此时会展示Nginx默认页面
# 停止Nginx
systemctl stop nginx
# 重启Nginx
systemctl restart nginx
# 重新加载Nginx
systemctl reload nginx
# 查看 Nginx 运行状态
systemctl status nginx
# 查看Nginx进程
ps -ef | grep nginx
# 杀死Nginx进程
kill -9 pid # 根据上面查看到的Nginx进程号,杀死Nginx进程,-9 表示强制结束进程
2.2 常用命令
Nginx 应用程序命令:
nginx -s reload # 向主进程发送信号,重新加载配置文件,热重启
nginx -s reopen # 重启 Nginx
nginx -s stop # 快速关闭
nginx -s quit # 等待工作进程处理完成后关闭
nginx -T # 查看当前 Nginx 最终的配置
nginx -t # 检查配置是否有问题
2.3 Nginx核心配置
2.3.1 配置文件结构
Nginx 的典型配置示例:
# main段配置信息
user nginx; # 运行用户,默认即是nginx,可以不进行设置
worker_processes auto; # Nginx 进程数,一般设置为和 CPU 核数一样
error_log /var/log/nginx/error.log warn; # Nginx 的错误日志存放目录
pid /var/run/nginx.pid; # Nginx 服务启动时的 pid 存放位置
# events段配置信息
events {
use epoll; # 使用epoll的I/O模型(如果你不知道Nginx该使用哪种轮询方法,会自动选择一个最适合你操作系统的)
worker_connections 1024; # 每个进程允许最大并发数
}
# http段配置信息
# 配置使用最频繁的部分,代理、缓存、日志定义等绝大多数功能和第三方模块的配置都在这里设置
http {
# 设置日志模式
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main; # Nginx访问日志存放位置
sendfile on; # 开启高效传输模式
tcp_nopush on; # 减少网络报文段的数量
tcp_nodelay on;
keepalive_timeout 65; # 保持连接的时间,也叫超时时间,单位秒
types_hash_max_size 2048;
include /etc/nginx/mime.types; # 文件扩展名与类型映射表
default_type application/octet-stream; # 默认文件类型
include /etc/nginx/conf.d/*.conf; # 加载子配置项
# server段配置信息
server {
listen 80; # 配置监听的端口
server_name localhost; # 配置的域名
# location段配置信息
location / {
root /usr/share/nginx/html; # 网站根目录
index index.html index.htm; # 默认首页文件
deny 172.168.22.11; # 禁止访问的ip地址,可以为all
allow 172.168.33.44;# 允许访问的ip地址,可以为all
}
error_page 500 502 503 504 /50x.html; # 默认50x对应的访问页面
error_page 400 404 error.html; # 同上
}
}
- 全局配置,对全局生效;
events配置影响Nginx服务器与用户的网络连接;http配置代理,缓存,日志定义等绝大多数功能和第三方模块的配置;server配置虚拟主机的相关参数,一个http块中可以有多个server块;location用于配置匹配的uri;upstream配置后端服务器具体地址,负载均衡配置不可或缺的部分;
用一张图清晰的展示它的层级结构:
2.3.2 配置文件 main 段核心参数
2.3.2.1 user
指定运行 Nginx 的 woker 子进程的属主和属组,其中组可以不指定。
user USERNAME [GROUP]
user nginx lion; # 用户是nginx;组是lion
2.3.2.2 pid
指定运行 Nginx master 主进程的 pid 文件存放路径。
pid /opt/nginx/logs/nginx.pid # master主进程的的pid存放在nginx.pid的文件
2.3.2.3 worker_rlimit_nofile_number
指定 worker 子进程可以打开的最大文件句柄数。
worker_rlimit_nofile 20480; # 可以理解成每个worker子进程的最大连接数量。
2.3.2.4 worker_rlimit_core
指定 worker 子进程异常终止后的 core 文件,用于记录分析问题。
worker_rlimit_core 50M; # 存放大小限制
working_directory /opt/nginx/tmp; # 存放目录
2.3.2.5 worker_processes_number
指定 Nginx 启动的 worker 子进程数量。
worker_processes 4; # 指定具体子进程数量
worker_processes auto; # 与当前cpu物理核心数一致
2.3.2.5 worker_cpu_affinity
将每个 worker 子进程与我们的 cpu 物理核心绑定。
worker_cpu_affinity 0001 0010 0100 1000; # 4个物理核心,4个worker子进程
将每个 worker 子进程与特定 CPU 物理核心绑定,优势在于,避免同一个 worker 子进程在不同的 CPU 核心上切换,缓存失效,降低性能。但其并不能真正的避免进程切换。
2.3.2.6 worker_priority
指定 worker 子进程的 nice 值,以调整运行 Nginx 的优先级,通常设定为负值,以优先调用 Nginx 。
worker_priority -10; # 120-10=110,110就是最终的优先级
Linux 默认进程的优先级值是120,值越小越优先;nice 定范围为 -20 到 +19 。[备注] 应用的默认优先级值是120加上 nice 值等于它最终的值,这个值越小,优先级越高。
2.3.2.6 worker_shutdown_timeout
指定 worker 子进程优雅退出时的超时时间。
worker_shutdown_timeout 5s;
2.3.2.7 timer_resolution
worker 子进程内部使用的计时器精度,调整时间间隔越大,系统调用越少,有利于性能提升;反之,系统调用越多,性能下降。
timer_resolution 100ms;
在 Linux 系统中,用户需要获取计时器时需要向操作系统内核发送请求,有请求就必然会有开销,因此这个间隔越大开销就越小。
2.3.2.8 daemon
指定 Nginx 的运行方式,前台还是后台,前台用于调试,后台用于生产。
daemon off; # 默认是on,后台运行模式
2.3.3 配置文件 events 段核心参数
2.3.3.1 use
Nginx 使用何种事件驱动模型。
use method; # 不推荐配置它,让nginx自己选择
method 可选值为:select、poll、kqueue、epoll、/dev/poll、eventport
2.3.3.2 worker_connections
worker 子进程能够处理的最大并发连接数。
worker_connections 1024 # 每个子进程的最大连接数为1024
2.3.3.3 accept_mutex
是否打开负载均衡互斥锁。
accept_mutex on # 默认是off关闭的,这里推荐打开
当一个新连接到达时,如果激活了accept_mutex,那么多个Worker将以串行方式来处理,其中有一个Worker会被唤醒,其他的Worker继续保持休眠状态;如果没有激活accept_mutex,那么所有的Worker都会被唤醒,不过只有一个Worker能获取新连接,其它的Worker会重新进入休眠状态,这就是惊群问题。
假设你养了一百只小鸡,现在你有一粒粮食,那么有两种喂食方法:
- 你把这粒粮食直接扔到小鸡中间,一百只小鸡一起上来抢,最终只有一只小鸡能得手,其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。
- 你主动抓一只小鸡过来,把这粒粮食塞到它嘴里,其它九十九只小鸡对此浑然不知,该睡觉睡觉。这就相当于激活了accept_mutex。
可以看到此场景下,激活accept_mutex相对更好一些,让我们修改一下问题的场景,我不再只有一粒粮食,而是一盆粮食,怎么办?
此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了,一盆粮食不知何年何月才能喂完,大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间,让它们自己去抢,虽然这可能会造成一定程度的混乱,但是整体的效率无疑大大增强了。
…
Nginx缺省激活了accept_mutex,是一种保守的选择。如果关闭了它,可能会引起一定程度的惊群问题,表现为上下文切换增多(sar -w)或者负载上升,但是如果你的网站访问量比较大,为了系统的吞吐量,建议关闭它。
2.3.4 配置文件 http\server 段核心参数
2.3.4.1 server_name 指令
指定虚拟主机域名。
server_name name1 name2 name3
# 示例:
server_name www.nginx.com;
域名匹配的四种写法:
- 精确匹配:
server_name www.nginx.com; - 左侧通配:
server_name *.nginx.com; - 右侧统配:
server_name www.nginx.*; - 正则匹配:
server_name ~^www.nginx.*$;
匹配优先级:精确匹配 > 左侧通配符匹配 > 右侧通配符匹配 > 正则表达式匹配
server_name 配置实例:
1、配置本地 DNS 解析
# 添加如下内容,其中 121.42.11.34 是服务器IP地址
121.42.11.34 www.nginx-test.com
121.42.11.34 mail.nginx-test.com
121.42.11.34 www.nginx-test.org
121.42.11.34 doc.nginx-test.com
121.42.11.34 www.nginx-test.cn
121.42.11.34 fe.nginx-test.club
[注意] 这里使用的是虚拟域名进行测试,因此需要配置本地 DNS 解析,如果使用阿里云上购买的域名,则需要在阿里云上设置好域名解析。
2、配置 Nginx ,vim /etc/nginx/nginx.conf
# 这里只列举了http端中的sever端配置
# 左匹配
server {
listen 80;
server_name *.nginx-test.com;
root /usr/share/nginx/html/nginx-test/left-match/;
location / {
index index.html;
}
}
# 正则匹配
server {
listen 80;
server_name ~^.*.nginx-test..*$;
root /usr/share/nginx/html/nginx-test/reg-match/;
location / {
index index.html;
}
}
# 右匹配
server {
listen 80;
server_name www.nginx-test.*;
root /usr/share/nginx/html/nginx-test/right-match/;
location / {
index index.html;
}
}
# 完全匹配
server {
listen 80;
server_name www.nginx-test.com;
root /usr/share/nginx/html/nginx-test/all-match/;
location / {
index index.html;
}
}
3、访问分析
- 当访问
www.nginx-test.com时,都可以被匹配上,因此选择优先级最高的“完全匹配”; - 当访问
mail.nginx-test.com时,会进行“左匹配”; - 当访问
www.nginx-test.org时,会进行“右匹配”; - 当访问
doc.nginx-test.com时,会进行“左匹配”; - 当访问
www.nginx-test.cn时,会进行“右匹配”; - 当访问
fe.nginx-test.club时,会进行“正则匹配”;
2.3.4.2 root
指定静态资源目录位置,它可以写在 http 、 server 、 location 等配置中。
root path
例如:
location /image {
root /opt/nginx/static;
}
当用户访问 www.test.com/image/1.png 时,实际在服务器找的路径是 /opt/nginx/static/image/1.png
[注意] root 会将定义路径与 URI 叠加, alias 则只取定义路径。
2.3.4.3 alias
它也是指定静态资源目录位置,它只能写在 location 中。
location /image {
alias /opt/nginx/static/image/;
}
当用户访问 www.test.com/image/1.png 时,实际在服务器找的路径是 /opt/nginx/static/image/1.png
[注意] 使用 alias 末尾一定要添加 / ,并且它只能位于 location 中。
2.3.4.4 location
配置路径。
location [ = | ~ | ~* | ^~ ] uri {
...
}
匹配规则:
=精确匹配;~正则匹配,区分大小写;~*正则匹配,不区分大小写;^~匹配到即停止搜索;
匹配优先级:= > ^~ > ~ > ~* > 不带任何字符。实例:
server {
listen 80;
server_name www.nginx-test.com;
# 只有当访问 www.nginx-test.com/match_all/ 时才会匹配到/usr/share/nginx/html/match_all/index.html
location = /match_all/ {
root /usr/share/nginx/html
index index.html
}
# 当访问 www.nginx-test.com/1.jpg 等路径时会去 /usr/share/nginx/images/1.jpg 找对应的资源
location ~ .(jpeg|jpg|png|svg)$ {
root /usr/share/nginx/images;
}
# 当访问 www.nginx-test.com/bbs/ 时会匹配上 /usr/share/nginx/html/bbs/index.html
location ^~ /bbs/ {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
location 中的反斜线
location /test {
...
}
location /test/ {
...
}
- 不带
/当访问www.nginx-test.com/test时,Nginx先找是否有test目录,如果有则找test目录下的index.html;如果没有test目录,nginx则会找是否有test文件。 - 带
/当访问www.nginx-test.com/test时,Nginx先找是否有test目录,如果有则找test目录下的index.html,如果没有它也不会去找是否存在test文件。
2.3.4.5 return
停止处理请求,直接返回响应码或重定向到其他 URL ;执行 return 指令后, location 中后续指令将不会被执行。
return code [text];
return code URL;
return URL;
例如:
location / {
return 404; # 直接返回状态码
}
location / {
return 404 "pages not found"; # 返回状态码 + 一段文本
}
location / {
return 302 /bbs ; # 返回状态码 + 重定向地址
}
location / {
return https://www.baidu.com ; # 返回重定向地址
}
2.3.4.6 rewrite
根据指定正则表达式匹配规则,重写 URL 。
语法:rewrite 正则表达式 要替换的内容 [flag];
上下文:server、location、if
示例:rewirte /images/(.*.jpg)$ /pic/$1; # $1是前面括号(.*.jpg)的反向引用
flag 可选值的含义:
last重写后的URL发起新请求,再次进入server段,重试location的中的匹配;break直接使用重写后的URL,不再匹配其它location中语句;redirect返回302临时重定向;permanent返回301永久重定向;
server{
listen 80;
server_name fe.lion.club; # 要在本地hosts文件进行配置
root html;
location /search {
rewrite ^/(.*) https://www.baidu.com redirect;
}
location /images {
rewrite /images/(.*) /pics/$1;
}
location /pics {
rewrite /pics/(.*) /photos/$1;
}
location /photos {
}
}
按照这个配置我们来分析:
- 当访问
fe.lion.club/search时,会自动帮我们重定向到https://www.baidu.com。 - 当访问
fe.lion.club/images/1.jpg时,第一步重写URL为fe.lion.club/pics/1.jpg,找到pics的location,继续重写URL为fe.lion.club/photos/1.jpg,找到/photos的location后,去html/photos目录下寻找1.jpg静态资源。
2.3.4.7 if 指令
语法:if (condition) {...}
上下文:server、location
示例:
if($http_user_agent ~ Chrome){
rewrite /(.*)/browser/$1 break;
}
condition 判断条件:
$variable仅为变量时,值为空或以0开头字符串都会被当做false处理;=或!=相等或不等;~正则匹配;! ~非正则匹配;~*正则匹配,不区分大小写;-f或! -f检测文件存在或不存在;-d或! -d检测目录存在或不存在;-e或! -e检测文件、目录、符号链接等存在或不存在;-x或! -x检测文件可以执行或不可执行;
实例:
server {
listen 8080;
server_name localhost;
root html;
location / {
if ( $uri = "/images/" ){
rewrite (.*) /pics/ break;
}
}
}
当访问 localhost:8080/images/ 时,会进入 if 判断里面执行 rewrite 命令。
2.3.4.8 autoindex
用户请求以 / 结尾时,列出目录结构,可以用于快速搭建静态资源下载网站。autoindex.conf 配置信息:
server {
listen 80;
server_name fe.lion-test.club;
location /download/ {
root /opt/source;
autoindex on; # 打开 autoindex,,可选参数有 on | off
autoindex_exact_size on; # 修改为off,以KB、MB、GB显示文件大小,默认为on,以bytes显示出⽂件的确切⼤⼩
autoindex_format html; # 以html的方式进行格式化,可选参数有 html | json | xml
autoindex_localtime off; # 显示的⽂件时间为⽂件的服务器时间。默认为off,显示的⽂件时间为GMT时间
}
}
当访问 fe.lion.com/download/ 时,会把服务器 /opt/source/download/ 路径下的文件展示出来,如下图所示:
\
2.3.5 变量
Nginx 提供给使用者的变量非常多,但是终究是一个完整的请求过程所产生数据, Nginx 将这些数据以变量的形式提供给使用者。下面列举些项目中常用的变量:
实例演示
var.conf :
server{
listen 8081;
server_name demo.demo.com;
root /usr/share/nginx/html;
location / {
return 200 "
remote_addr: $remote_addr
remote_port: $remote_port
server_addr: $server_addr
server_port: $server_port
server_protocol: $server_protocol
binary_remote_addr: $binary_remote_addr
connection: $connection
uri: $uri
request_uri: $request_uri
scheme: $scheme
request_method: $request_method
request_length: $request_length
args: $args
arg_pid: $arg_pid
is_args: $is_args
query_string: $query_string
host: $host
http_user_agent: $http_user_agent
http_referer: $http_referer
http_via: $http_via
request_time: $request_time
https: $https
request_filename: $request_filename
document_root: $document_root
";
}
}
当我们访问 http://demo.demo.com:8081/test?pid=121414&cid=sadasd 时,由于 Nginx 中写了 return 方法,因此 chrome 浏览器会默认为我们下载一个文件,下面展示的就是下载的文件内容:
remote_addr: 27.16.220.84
remote_port: 56838
server_addr: 172.17.0.2
server_port: 8081
server_protocol: HTTP/1.1
binary_remote_addr: 茉
connection: 126
uri: /test/
request_uri: /test/?pid=121414&cid=sadasd
scheme: http
request_method: GET
request_length: 518
args: pid=121414&cid=sadasd
arg_pid: 121414
is_args: ?
query_string: pid=121414&cid=sadasd
host: var.lion-test.club
http_user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36
http_referer:
http_via:
request_time: 0.000
https:
request_filename: /usr/share/nginx/html/test/
document_root: /usr/share/nginx/html
Nginx 的配置还有非常多,以上只是罗列了一些常用的配置,在实际项目中还是要学会查阅文档。
2.4 负载均衡
2.4.1 Nginx负载均衡策略
Nginx 实现负载均衡的策略:
- 轮询策略:默认情况下采用的策略,将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的,但是如果其中某一台服务器压力太大,出现延迟,会影响所有分配在这台服务器下的用户。
- 最小连接数策略:将请求优先分配给压力较小的服务器,它可以平衡每个队列的长度,并避免向压力大的服务器添加更多的请求。
- 最快响应时间策略:优先分配给响应时间最短的服务器。
- 客户端
ip绑定策略:来自同一个ip的请求永远只分配一台服务器,有效解决了动态网页存在的session共享问题。
2.4.2 Nginx负载均衡配置
在配置反向代理和负载均衡等等功能之前,有两个核心模块是我们必须要掌握的,这两个模块应该说是 Nginx 应用配置中的核心,它们分别是:upstream 、proxy_pass 。
2.4.2.1 upstream
用于定义上游服务器(指的就是后台提供的应用服务器)的相关信息。
语法:upstream name {
...
}
上下文:http
示例:
upstream back_end_server{
server 192.168.100.33:8081
}
在 upstream 内可使用的指令:
server定义上游服务器地址;zone定义共享内存,用于跨worker子进程;keepalive对上游服务启用长连接;keepalive_requests一个长连接最多请求HTTP的个数;keepalive_timeout空闲情形下,一个长连接的超时时长;hash哈希负载均衡算法;ip_hash依据IP进行哈希计算的负载均衡算法;least_conn最少连接数负载均衡算法;least_time最短响应时间负载均衡算法;random随机负载均衡算法;
2.4.2.1.1 server
定义上游服务器地址。
语法:server address [parameters]
上下文:upstream
parameters 可选值:
weight=number权重值,默认为1;max_conns=number上游服务器的最大并发连接数;fail_timeout=time服务器不可用的判定时间;max_fails=numer服务器不可用的检查次数;backup备份服务器,仅当其他服务器都不可用时才会启用;down标记服务器长期不可用,离线维护
2.4.2.1.2 keepalive
限制每个 worker 子进程与上游服务器空闲长连接的最大数量。
keepalive connections;
上下文:upstream
示例:keepalive 16;
2.4.2.1.3 keepalive_requests
单个长连接可以处理的最多 HTTP 请求个数。
语法:keepalive_requests number;
默认值:keepalive_requests 100;
上下文:upstream
2.4.2.1.4 keepalive_timeout
空闲长连接的最长保持时间。
语法:keepalive_timeout time;
默认值:keepalive_timeout 60s;
上下文:upstream
2.4.2.1.5 配置实例
upstream back_end{
server 127.0.0.1:8081 weight=3 max_conns=1000 fail_timeout=10s max_fails=2;
keepalive 32;
keepalive_requests 50;
keepalive_timeout 30s;
ip_hash;
}
2.4.2.2 proxy_pass
用于配置代理服务器。
语法:proxy_pass URL;
上下文:location、if、limit_except
示例:
proxy_pass http://127.0.0.1:8081
proxy_pass http://127.0.0.1:8081/proxy
URL 参数原则
-
URL必须以
http或https开头; -
URL中可以携带变量;
-
URL中是否带
URI,会直接影响发往上游请求的URL;
接下来让我们来看看两种常见的 URL 用法:
proxy_pass http://192.168.100.33:8081proxy_pass http://192.168.100.33:8081/
这两种用法的区别就是带 / 和不带 / ,在配置代理时它们的区别可大了:
- 不带
/意味着Nginx不会修改用户URL,而是直接透传给上游的应用服务器; - 带
/意味着Nginx会修改用户URL,修改方法是将location后的URL从用户URL中删除;
不带 / 的用法:
location /bbs/{
proxy_pass http://127.0.0.1:8080;
}
分析:
-
用户请求
URL:/bbs/abc/test.html -
请求到达
Nginx的URL:/bbs/abc/test.html
3 .请求到达上游应用服务器的 URL :/bbs/abc/test.html
带 / 的用法:
location /bbs/{
proxy_pass http://127.0.0.1:8080/;
}
分析:
- 用户请求
URL:/bbs/abc/test.html - 请求到达
Nginx的URL:/bbs/abc/test.html - 请求到达上游应用服务器的
URL:/abc/test.html并没有拼接上/bbs,这点和root与alias之间的区别是保持一致的。
2.4.2.3 负载均衡配置示例
示例:
upstream demo_server {
zone test 10M; # zone可以设置共享内存空间的名字和大小
least_conn;
server 121.42.11.34:8020;
server 121.42.11.34:8030;
server 121.42.11.34:8040;
}
server {
listen 80;
server_name balance.lion.club;
location /balance/ {
proxy_pass http://demo_server;
}
}
最后你会发现,负载均衡的配置其实一点都不复杂。
2.5 HTTPS
配置证书
下载证书的压缩文件,里面有个 Nginx 文件夹,把 xxx.crt 和 xxx.key 文件拷贝到服务器目录,再进行如下配置:
server {
listen 443 ssl http2 default_server; # SSL 访问端口号为 443
server_name demo.cn; # 填写绑定证书的域名(我这里是随便写的)
ssl_certificate /etc/nginx/https/lion.club_bundle.crt; # 证书地址
ssl_certificate_key /etc/nginx/https/lion.club.key; # 私钥地址
ssl_session_timeout 10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 支持ssl协议版本,默认为后三个,主流版本是[TLSv1.2]
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
如此配置后就能正常访问 HTTPS 版的网站了。