Ngnix配置的使用
一、Nginx配置文件(nginx.conf)
1、配置文件的层级
配置文件目前分为三大部分，全局块、event块和http块，下面是具体的结构
2、配置文件概览
# 全局快
------------------------------------------------------------------------------
#Nginx用户及组：用户 组。window下不指定
#user nobody;
#工作进程：数目。根据硬件调整，通常等于CPU数量或者2倍于CPU。
worker_processes 1;
#错误日志：存放路径。
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid(进程标识符)：存放路径
#pid logs/nginx.pid;
------------------------------------------------------------------------------
# events块
events {
#使用epoll的I/O 模型。linux建议epoll，FreeBSD建议采用kqueue，window下不指定。
use epoll;
#单个进程最大连接数（最大连接数=连接数*进程数
worker_connections 1024;
}
# http块
http {
------------------------------------------------------------------------------# http全局块
#设定mime类型,类型由mime.type文件定义
include mime.types;
default_type application/octet-stream;
#日志格式设置
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#用了log_format指令设置了日志格式之后，需要用access_log指令指定日志文件的存放路径
#access_log logs/access.log main;
#服务器名字的hash表大小
server_names_hash_bucket_size 128;
#客户端请求头缓冲大小。
#nginx默认会用client_header_buffer_size这个buffer来读取header值，
#如果header过大，它会使用large_client_header_buffers来读取。
#如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request
#如果超过buffer，就会报HTTP 414错误(URI Too Long)
#nginx接受最长的HTTP头部大小必须比其中一个buffer大
#否则就会报400的HTTP错误(Bad Request)
#client_header_buffer_size 32k;
#large_client_header_buffers 4 32k;
#隐藏ngnix版本号
#server_tokens off;
#忽略不合法的请求头
#ignore_invalid_headers on;
#让 nginx 在处理自己内部重定向时不默认使用 server_name设置中的第一个域名
#server_name_in_redirect off;
#客户端请求体的大小
#client_body_buffer_size 8m;
#开启文件传输，一般应用都应设置为on；若是有下载的应用，则可以设置成off来平衡网络I/O和磁盘的I/O来降低系统负载
sendfile on;
#告诉nginx在一个数据包里发送所有头文件，而不一个接一个的发送。
#tcp_nopush on;
#长连接超时时间，单位是秒
keepalive_timeout 65;
#gzip模块设置，使用 gzip 压缩可以降低网站带宽消耗，同时提升访问速度。
#gzip on; #开启gzip
#gzip_min_length 1k; #最小压缩大小
#gzip_buffers 4 16k; #压缩缓冲区
#gzip_http_version 1.0; #压缩版本
#gzip_comp_level 2; #压缩等级
#gzip_types text/plain text/css text/xml text/javascript application/json application/x-javascript application/xml application/xml+rss;#压缩类型
------------------------------------------------------------------------------
#负载均衡
#max_fails为允许请求失败的次数，默认为1
#weight为轮询权重，根据不同的权重分配可以用来平衡服务器的访问率。
# upstream myServer{
# server 127.0.0.1:8080 max_fails=3 weight=2;
# server 127.0.0.1:8081 max_fails=3 weight=4;
#｝
# server块
server {
# server全局块
listen 80;
#IP/域名可以有多个，用空格隔开
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
# location块
#反向代理配置，
# #将所有请求为www.test.com的请求全部转发到upstream中定义的目标服务器中。
# location / {
#
# #此处配置的域名必须与upstream的域名一致，才能转发。
# proxy_pass http://myServer;
# #proxy_pass http://192.168.247.129:8080;
#
# proxy_connect_timeout 20; #nginx跟后端服务器连接超时时间(代理连接超时)
#
# #client_max_body_size 10m; #允许客户端请求的最大单文件字节数
# #client_body_buffer_size 128k; #缓冲区代理缓冲用户端请求的最大字节数
# #proxy_send_timeout 300; #后端服务器数据回传时间(代理发送超时)
# #proxy_read_timeout 300; #连接成功后，后端服务器响应时间(代理接收超时)
# #proxy_buffer_size 4k; #设置代理服务器（nginx）保存用户头信息的缓冲区大小
# #proxy_buffers 4 32k; #proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
# #proxy_busy_buffers_size 64k; #高负荷下缓冲大小（proxy_buffers*2）
# #proxy_temp_file_write_size 64k; #设定缓存文件夹大小，大于这个值，将从upstream服务器传
#
# root html;
#
# #定义首页索引文件的名称
# index index.html index.htm;
# }
#
# #动静分离 静态资源走linux 动态资源走tomcat
# # 注意 /source/image/下面寻找资源
# location /image/ {
# root /source/;
# autoindex on;
# }
#
#
# # 出现50x错误时，使用/50x.html页返回给客户端
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# root html;
# }
#}
#下面是配置生产环境中既支持HTTP又支持HTTPS,保证用户在浏览器中输入HTTP也能正常访问
# SSL证书 配置
ssl_certificate cert/yphtoy.com.pem; #加密证书路径
ssl_certificate_key cert/yphtoy.com.key; #加密私钥路径
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #加密协议
ssl_session_cache shared:SSL:1m; #加密访问缓存设置,可以大大提高访问速度
ssl_session_timeout 10m; #加密访问缓存过期时间
ssl_ciphers HIGH:!aNULL:!MD5; #加密算法
ssl_prefer_server_ciphers on; #是否由服务器决定采用哪种加密算法
# 负载均衡
upstream api_upstream
{
server 127.0.0.1:8080 max_fails=3 weight=1;
server 127.0.0.1:8081 max_fails=3 weight=1;
}
#api 接口(兼容HTTP)
server{
listen 80;
server_name api.test.com;
# 301重定向跳转到HTTPS接口
return 301 https://$server_name$request_uri;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
#api 接口(兼容HTTPS)
server{
listen 443 ssl;
server_name api.test.com;
location / {
root html;
index index.html index.htm;
proxy_pass http://api_upstream;
#语法： proxy_cookie_path oldpath replacepath;
#oldpath就是你要替换的路径 replacepath 就是要替换的值
#作用：同一个web服务器下面多个应用之间能获取到cookie
proxy_cookie_path /api/ /;
#服务端接收的请求头Cooke值不变
proxy_set_header Cookie $http_cookie;
}
}
#管理后台端(兼容HTTP)
server{
listen 80;
server_name manage.test.com;
# 301重定向跳转到HTTPS接口
return 301 https://$server_name/$request_uri;
error_page 500 502 503 504 /50x.html;
location = /50x.html{
root html
}
}
#管理后台端(兼容HTTPS)
server{
listen 443 ssl;
server_name manage.test.com;
location / {
root /home/test/web/dist
index /index.html;
#语法：try_files 【$uri】 【 $uri/】 【参数】
#当用户请求https://manage.test.com/login时，
#一.如果配置了上面的默认index,会依次请求
#1./home/test/web/dist/login 查找有没有login这个文件，没有的话
#2./home/test/web/dist/index.html 有就直接返回
#二.如果没有配置了上面的默认index或者配置了没有找到对应的资源,会依次请求
#1./home/test/web/dist/login 查找有没有login这个文件，没有的话
#2./home/test/web/dist/login/ 查找有没有login这个目录，没有的话
#3.请求https://manage.test.com/index.html nginx内部做了一个子请求
#三.总的来说,index的优先级比try_files高,请求会先去找index配置,这里最后一个参数必须存在
try_files $uri $uri/ /index.html;
#解决跨域问题
#允许跨域请求地址(*表示全部,但是无法满足带cookie请求,因为cookie只能在当前域请求)
add_header Access-Control-Allow-Origin $http_origin;
#允许接收cookie和发送cookie
add_header Access-Control-Allow-Credentials 'true';
#允许请求的方法
add_header Access-Control-Allow-Methods 'GET,POST,DELETE,PUT,OPTIONS';
#允许请求头（Content-Type:请求数据/媒体类型 x-requested-with:判断请求是异步还是同步 自定义header 比如 token）
add_header Access-Control-Allow-Headers $http_access_control_request_headers;
#浏览器缓存请求头信息,1800秒内,只会有1次请求，不会出现"OPTIONS"预请求,节约资源
#add_header Access-Control-Max-Age '1800';
if ($request_method = 'OPTIONS') {
return 204;
}
#服务端HttpServletRequest可以获得用户的真实ip
proxy_set_header X-Real-IP $remote_addr;
#服务端HttpServletRequest可以获得用户的真实ip和经过的每一层代理服务器的ip
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#服务端接收的请求头Host值不变
proxy_set_header Host $http_host;
proxy_set_header X-Nginx-Proxy true;
}
}
# 可以配置多个server块
}
二、配置文件各个模块详解
1、全局块
就是配置文件从头开始到events块之间的内容，主要设置的是影响nginx服务器整体运行的配置指令比如worker_process, 值越大，可以支持的并发处理量也越多，但是还是和服务器的硬件相关
2、events块
events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。
上述例子就表示每个 work process 支持的最大连接数为 1024.
这部分的配置对 Nginx 的性能影响较大，在实际中应该灵活配置
3、http块
包括http全局块，以及多个server块
3.1、http全局块
http 全局块配置的指令包括文件引入、 MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
3.2、server块
这块和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。
每个 http 块可以包括多个 server 块，而每个 server 块就相当于一个虚拟主机
而每个 server 块也分为全局 server 块，以及可以同时包含多个 location 块。
3.2.1、server全局块
最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或 IP 配置。
3.2.2、location块
一个 server 块可以配置多个 location 块。
主要作用是根据请求地址路径的匹配，匹配成功进行特定的处理
这块的主要作用是基于 Nginx 服务器接收到的请求字符串（例如 server_name/uri-string），对虚拟主机名称（也可以是 IP 别名）之外的字符串（例如 前面的 /uri-string）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。
4、正向代理
正向代理代理的是客户端，需要在客户端配置，我们访问的还是真实的服务器地址
5、反向代理
-
反向代理代理的是服务器端，客户端不需要任何配置，客户端只需要将请求发送给反向代理服务器即可，代理服务器将请求分发给真实的服务器，获取数据后将数据转发给你。隐藏了真实服务器，有点像网关。
-
正向代理代理的是
客户端，需要为每一个客户端都做一个代理服务器，客户端访问的路径是目标服务器 -
反向代理代理的是
真实服务器，客户端不需要做任何的配置，访问的路径是代理服务器，由代理服务器将请求转发到真实服务器
6、负载均衡
概述
简单来说就是使用分布式的场景，将原先的一台服务器做成一个集群，然后将请求分发到各个服务器上，但是，如何将请求每次转发到不同的服务器呢，Nginx就可以做到。原来我们都是直接访问服务器，现在我们可以使用Nginx进行反向代理，然后我们访问Nginx，由Nginx将我们的请求分发到不同的服务器上，以实现负载均衡
负载均衡规则
-
轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除 -
weight权重
weight 代表权重默认为 1,权重越高被分配的客户端越多
upstream myserver {
server 192.168.80.102:8081 weight=1 ;
server 192.168.80.102:8082 weight=2 ;
}
server {
listen 80;
location / {
proxy_pass http://myserver;
}
- ip_hash
每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决session问题
#配置负载均衡的服务器和端口
upstream myserver {
server 192.168.80.102:8081;
server 192.168.80.102:8082;
ip_hash;
}
server {
listen 80;
location / {
proxy_pass http://myserver;
}
}
- fair
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
#配置负载均衡的服务器和端口
upstream myserver {
server 192.168.80.102:8081;
server 192.168.80.102:8082;
fair;
}
![[NeurIPS 2018] Hyperbolic neural networks](https://img-blog.csdnimg.cn/8027b3fc89a242449675127ee2f7fe99.png#pic_center)
