基础配置信息

# ===========  全局配置  ===========
worker_processes 1;  # 设置工作进程数为1#error_log  logs/error.log;             # 指定了错误日志的位置
#error_log  logs/error.log  notice;     # 设置了错误日志的级别为 notice，表示只记录通知级别的错误
#error_log  logs/error.log  info;       # 设置了错误日志的级别为 info，表示只记录信息级别的错误#pid        logs/nginx.pid;             # 指定了进程 ID 文件的位置# =========== events块 =================
events {worker_connections 1024;  # 设置每个工作进程的最大连接数
}# ===========  http块 ==================
http {include mime.types;  # 包含MIME类型配置文件default_type application/octet-stream;  # 默认文件类型为二进制流sendfile on;  # 启用文件传输优化keepalive_timeout 65;  # 客户端与服务器之间的连接保持时间client_max_body_size 20M; # 设置最大请求体大小为20MB# 定义一个 Nginx 访问日志的格式，称为 main【详情见下方解析，不需要可省略】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  logs/access.log  main;# 启用 Nginx 的 Gzip 压缩功能。将服务器响应的内容进行压缩，以减少传输的数据量。# 这有助于提高网站的加载速度，特别是对于大型文件或文本内容来说效果更明显。# gzip  on;# ======== server块（虚拟主机） 【可配置多个】=============server {# 见下面应用场景，根据具体场景具体配置}}# =========== 日志格式解析 ==============
# 定义一个 Nginx 访问日志的格式，称为 main：
# $remote_addr: 客户端的IP地址。
# $remote_user: 客户端的用户名（如果有）。
# $time_local: 请求的本地时间。
# $request: 客户端请求的内容。
# $status: 服务器响应的状态码。
# $body_bytes_sent: 发送给客户端的字节数。
# $http_referer: 客户端请求的来源页面。
# $http_user_agent: 客户端的用户代理（通常是浏览器信息）。
# $http_x_forwarded_for: 客户端的原始IP地址（如果使用了代理服务器）。
# 这个格式将这些信息按照一定的顺序记录到访问日志中，方便后续分析和监控服务器的访问情况。

应用场景一：配置web服务器

server {listen 80;  # 监听端口80server_name localhost;  # 指定服务器的域名charset utf-8; # 设置字符集为UTF-8# 指定了上面配置的访问日志位置【不需要可省略】# access_log  logs/host.access.log  main;	# 配置静态文件服务和前端应用location / {# 指定前端应用的根目录，路径用 / 符号。root 【路径】;# 尝试匹配文件，如果找不到则重定向到index.htmltry_files $uri $uri/ /index.html;# 指定默认的索引文件index index.html index.htm;}# 配置错误页面error_page 500 502 503 504 /50x.html;location = /50x.html {root html;}}

应用场景二：反向代理服务器

server {listen 80;  server_name localhost;  charset utf-8; # access_log  logs/host.access.log  main;	# 配置用于处理请求路径以 /prod-api/ 开头的请求。这通常用于配置反向代理location /prod-api/ {# 设置反向代理请求的头部信息。它将客户端请求中的 Host 头部传递给后端服务器proxy_set_header Host $http_host;# 设置 X-Real-IP 头部，将客户端的真实 IP 地址传递给后端服务器。proxy_set_header X-Real-IP $remote_addr;# 设置自定义的 REMOTE-HOST 头部，同样将客户端的 IP 地址传递给后端服务器。proxy_set_header REMOTE-HOST $remote_addr;# 设置 X-Forwarded-For 头部，将客户端的 IP 地址添加到已有的 X-Forwarded-For 头部中，以便后端服务器知道请求的来源。proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# 指定了反向代理的目标地址，将请求转发到 http://localhost/，即本地的后端服务器proxy_pass http://localhost/;}}

!!! 反向代理也可以基于请求路径转发到不同服务器 !!!

server {listen 80;server_name example.com;# 转发到北京地区服务器location /beijing/ {proxy_pass http://localhost:81/;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}# 转发到广州地区服务器location /guangzhou/ {proxy_pass http://localhost:82/;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}# 其他路径的请求，可根据需要配置}

!!!反向代理路径结尾加不加 / 符号的区别！！！

#  ------ 结尾带斜杠的情况 ------------
location /beijing/ {proxy_pass http://localhost:81/;
}这个配置中，location /beijing/ 表示匹配以 /beijing/ 开头的请求路径。
当收到类似 /beijing/foo 的请求时，会将请求转发到 http://localhost:81/foo，
即会将原始请求中的 /beijing/ 部分去掉，并将剩余部分 /foo 附加到 proxy_pass 指定的地址后面。
【location/beijing/foo  ==> http://localhost:81/foo】#  ------ 结尾不带斜杠的情况 ------------
location /beijing/ {proxy_pass http://localhost:81;
}
在这个配置中，当收到类似 /beijing/foo 的请求时， 
会将请求转发到 http://localhost:81，不会将原始请求中的 /beijing/ 部分去掉。
因此，代理服务器收到的路径仍然是 /beijing/foo
【location/beijing/foo  ==> http://localhost:81/beijing/foo】

应用场景三：URL重定向

# ============== 域名重定向 ========================server {listen 80;server_name example.com;# 使用 rewrite 实现重定向到新地址，permanent 表示 301 永久重定向，不加则为302 临时重定向# rewrite 重定向配置更加灵活，但它需要在每个请求上执行正则表达式匹配和重写操作，相对而言稍微耗费一些性能location / {rewrite ^/(.*)$ http://new.example.com/$1 permanent;}# 使用return 重定向，不涉及正则表达式的匹配和重写规则，更高效return 302 http://new.example.com$request_uri;}# ============== 路径重定向 =================
server {listen 80;server_name example.com;location / {rewrite ^/old-path/(.*)$ /new-path/$1;}}

如果只是简单的重定向操作，并且不需要进行复杂的路径重写或捕获，推荐使用 return 301 的方式来实现重定向。这样能够更直接、更高效地达到重定向的目的，避免不必要的正则表达式匹配和重写操作。
.
.
.
301 重定向：
····性质：301 表示所请求的资源已被永久移动到新的 URL。这意味着浏览器下次访问相同的原始 URL 时应该直接使用新的 URL。
····特点：
Ⅰ、浏览器会缓存重定向的新 URL，下次访问相同的旧 URL 时会直接跳转到新 URL，不再发起请求旧 URL。
Ⅱ、搜索引擎会将原始 URL 的搜索排名转移到新的 URL 上。
.
.
.
302 重定向：
····性质：302 表示所请求的资源暂时被移动到新的 URL，但将来可能会恢复到原始 URL。
····特点：
Ⅰ、浏览器会暂时缓存重定向的新 URL，下次访问相同的旧 URL 时会再次请求旧 URL，不直接跳转到新 URL。
Ⅱ、搜索引擎不会更新原始 URL 的搜索排名，认为这种重定向是临时的。
.
选择：
301 应该用于永久性重定向，如果你确定资源将永久地移到新的 URL，并且不再使用旧 URL。
302 应该用于临时性重定向，如果资源只是暂时移动到新的 URL，将来可能会恢复到原始 URL。

应用场景四：防盗链

》防止其他网站引用我们的图片资源，避免资源消耗。

server {listen 80;server_name example.com;# 使用正则表达式匹配请求的 URL，限制只对图片文件（jpg、jpeg、png、gif）生效。location ~* \.(jpg|jpeg|png|gif)$ {# 设置防盗链规则valid_referers none blocked example.com *.example.com;if ($invalid_referer) {# 防盗链规则不匹配的处理，例如返回 403 Forbiddenreturn 403;}# 允许符合防盗链规则的请求访问图片资源# 这里可以配置图片资源的存放路径root /path/to/your/image/directory;}# 其他配置项可以根据需求添加
}# ----------------------------------------------------
valid_referers：设置允许访问资源的 Referer（来源）规则。none：禁止所有 Referer。blocked：允许空 Referer。example.com：允许指定的域名 example.com 的 Referer。*.example.com：允许所有子域名的 Referer。if ($invalid_referer)：检查请求的 Referer 是否不符合防盗链规则。
如果 $invalid_referer 为 true，表示请求的 Referer 不在允许的列表中。
在这种情况下，可以返回 403 Forbidden 状态码，拒绝访问资源。root /path/to/your/image/directory;：配置图片资源的存放路径，可以根据实际情况替换为你的图片存放目录。

应用场景五：根据设备类型重定向/代理/访问 不同域名/资源

# 一：根据if判断设备类型，进行 rewrite 重定向。不满足if则正常执行接下去的配置信息（pc端配置）
# ========================== =========================# 定义 resolver，指定 DNS 解析服务器(使用 Google 的公共 DNS)
# 根据情况而定是否需要，有些本地无法解析dns，导致访问失败，则需要用到此命令。
resolver 8.8.8.8;server {listen 8098;server_name example.com;# 判断是否为手机端访问if ($http_user_agent ~* (android|iphone|ipod|mobile|blackberry|webos|incognito|webmate|bada|nokia|symbian|Windows\ Phone|opera\ mini|opera\ mobi|skyfire|up\.browser|ucweb|j2me)) {# 如果是手机端访问，则重定向到 PC 端页面rewrite ^(.*)$ http://app.example.com$request_uri;}# 配置 PC 端页面的根目录和其他配置项root /path/to/pc/website;index index.html index.htm;# 其他 PC 端配置项
}# 二：根据设备类型反向代理不同域名【反向代理会隐藏真实的 url 信息】
# ========================== =========================# 定义设备类型映射表
map $http_user_agent $proxy_backend {default http://pc.example.com;  # 默认设备类型为桌面端（pc端）~*mobile http://app.example.com;  # 匹配包含 mobile 的 User-Agent 为手机端~*tablet http://ipad.example.com;  # 匹配包含 tablet 的 User-Agent 为平板端
}# 定义 resolver，指定 DNS 解析服务器(使用 Google 的公共 DNS)
# 根据情况而定是否需要，有些本地无法解析dns，导致访问失败，则需要用到此命令。
resolver 8.8.8.8;server {listen 80;server_name example.com;location / {# 使用 proxy_pass 将请求代理到根据设备类型选择的后端服务器proxy_pass $proxy_backend;}
}# 三： 根据不同设备类型进行灵活配置
# ========================== =========================# 定义设备类型映射表
map $http_user_agent $device_type {default desktop;  # 默认设备类型为桌面端（pc端）~*mobile mobile;  # 匹配包含 mobile 的 User-Agent 为手机端~*tablet tablet;  # 匹配包含 tablet 的 User-Agent 为平板端
}# 配置服务器块
server {listen 80;server_name example.com;# 根据设备类型进行配置if ($device_type = mobile) {}if ($device_type = tablet) {}# 默认情况下为pc端#进行pc端配置
}

应用场景六：！负载均衡服务器！

1、轮询策略（Round Robin）

》轮询是最常见的负载均衡策略。请求按照顺序依次分配给后端服务器，每个请求都按照列表中服务器的顺序进行分发。当请求达到服务器列表的末尾时，重新开始从第一个服务器分发。轮询适用于后端服务器性能相近、无需特别考虑请求的处理时间等情况。
》也可以理解为是一个特殊的加权策略，不过服务器组中的各个服务器的权重都是1。

upstream my_backend {server backend1.example.com;server backend2.example.com;
}# 后面的均衡策略没有 server ，则说明和这里是一样的，不过多重复。
server {listen 80;server_name myloadbalancer.example.com;location / {proxy_pass http://my_backend;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}
}

2、加权轮询 （Weighted Round Robin）

》加权轮询在轮询的基础上引入权重因素，即给每个服务器分配一个权重值，用于调节每台服务器处理请求的比例。权重高的服务器将获得更多的请求。这种策略适用于服务器性能不均衡的情况，通过调整权重可以实现更灵活的负载均衡。
》weight和访问比率成正比

upstream my_backend {server backend1.example.com weight=3;server backend2.example.com weight=2;server backend3.example.com weight=1;
}

3、最少连接（Least Connections）

》最少连接策略将请求分配给当前连接数最少的服务器，以保持服务器的负载均衡。这种策略可以避免出现某些服务器连接数过载的情况，从而提高系统的整体性能。

upstream my_backend {least_conn;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

4、基于 IP 的哈希（IP Hash）

》IP 哈希策略根据请求的源 IP 地址计算哈希值，然后将请求分发到特定的服务器。相同 IP 地址的请求始终被分发到相同的服务器，这有助于保持会话的一致性，适用于需要会话粘性的应用场景。

upstream my_backend {ip_hash;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

5、基于 URL 的哈希（URL Hash）

》URL 哈希策略根据请求的 URL 计算哈希值，然后将请求分发到特定的服务器。相同 URL 的请求始终被分发到相同的服务器，这对于缓存和特定资源的分发具有一定的优势。

upstream my_backend {hash $request_uri;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

6、最短响应时间（Least Time）

》最短响应时间策略将请求分配给具有最短平均响应时间的服务器。通过实时监测服务器的响应时间，负载均衡器可以动态调整请求的分发，以确保向用户提供更快的响应和更好的体验。

upstream my_backend {least_time header_response time;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

7、公平策略（Fair）

》公平策略会根据服务器的响应时间和负载情况动态调整请求的分发，以确保每个服务器获得相等的负载。这种策略可以避免某些服务器被过载或负载不均衡的情况。

upstream my_backend {fair;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}

负载均衡服务器的健康检查

》当后端服务器因为故障或不可用时，负载均衡器可以自动剔除这些服务器，以确保流量不会被发送到无法正常处理请求的服务器上。以下是几种常见的策略以及对应的配置样例：

1、健康检查（Health Checks）策略

》通过定期向后端服务器发送健康检查请求（如 HTTP 请求或 TCP 连接），负载均衡器根据响应结果判断服务器的健康状态。不可用的服务器会自动从负载均衡器的服务器列表中剔除，直到恢复正常后再重新加入。

upstream my_backend {server backend1.example.com;server backend2.example.com;server backend3.example.com;# 健康检查配置check interval=3000 rise=2 fall=3 timeout=1000;
}server {listen 80;server_name myloadbalancer.example.com;location / {proxy_pass http://my_backend;}
}#----------------------------
check：这是一个负载均衡模块的指令，用于配置健康检查参数。
interval=3000：指定健康检查的间隔时间，单位为毫秒（ms）。在此配置中，健康检查每隔 3 秒进行一次。
rise=2：指定服务器被标记为健康的连续成功检查次数。如果服务器连续成功检查的次数达到设定的值，则被标记为健康状态。
fall=3：指定服务器被标记为不健康的连续失败检查次数。如果服务器连续失败检查的次数达到设定的值，则被标记为不健康状态。
timeout=1000：指定健康检查的超时时间，单位为毫秒（ms）。如果健康检查在设定的超时时间内没有收到响应，则认为检查失败。

2、主动健康监控（Active Health Monitoring）策略

》负载均衡器定期向后端服务器发送主动的健康检查请求，而不是等待客户端请求时检测。如果检测到后端服务器不可用，负载均衡器将立即停止将流量发送到该服务器。

upstream my_backend {server backend1.example.com check;server backend2.example.com check;server backend3.example.com check;
}server {listen 80;server_name myloadbalancer.example.com;location / {proxy_pass http://my_backend;}# 健康检查配置location /health_check {access_log off;proxy_pass http://my_backend;proxy_pass_check http://my_backend/health_check;}
}#-----------------------location /health_check：定义一个新的 location 块，用于处理健康检查的请求。
access_log off;：关闭对健康检查请求的访问日志记录，避免将健康检查请求记录到 Nginx 的访问日志中。
proxy_pass http://my_backend;：将健康检查请求代理转发到定义的后端服务器组 my_backend。
proxy_pass_check http://my_backend/health_check;：配置用于健康检查的额外请求。负载均衡器会向后端服务器发送这个额外的检查请求，以确定服务器的健康状态。

3、 被动健康监控（Passive Health Monitoring）策略

》负载均衡器根据实际的流量情况和响应时间来判断服务器的健康状态。如果后端服务器的响应时间超过预设阈值或者出现错误率过高的情况，负载均衡器会将该服务器标记为不可用。

upstream my_backend {fair;server backend1.example.com;server backend2.example.com;server backend3.example.com;
}server {listen 80;server_name myloadbalancer.example.com;location / {proxy_pass http://my_backend;}
}

4、连接排空（Connection Draining）策略

》当负载均衡器检测到后端服务器不可用时，会停止向该服务器发送新的连接和请求，但允许已经建立的连接继续处理直到完成。这样可以确保不影响正在进行中的流量，并逐渐将流量从不可用的服务器转移到其他健康的服务器。

upstream my_backend {server backend1.example.com;server backend2.example.com backup;
}server {listen 80;server_name myloadbalancer.example.com;location / {proxy_pass http://my_backend;proxy_next_upstream error timeout http_502;proxy_connect_timeout 2s;proxy_set_header Connection "";}
}# -----------------------------proxy_next_upstream error timeout http_502;：
定义在出现指定错误时切换到下一个后端服务器的条件。在此配置中，当后端服务器返回错误、超时或 HTTP 502 错误时，将切换到下一个后端服务器处理请求。proxy_connect_timeout 2s;：
设置连接后端服务器的超时时间为 2 秒。如果在指定的时间内无法建立连接，则视为连接超时。proxy_set_header Connection "";：
设置请求头中的 Connection 字段为空字符串，防止 Nginx 将连接保持设置为默认值，避免不必要的连接保持。

nginx 科普信息

1、常用命令

//开启服务：
start nginx//停止服务：nginx停止命令stop与quit参数的区别在于stop是快速停止nginx，可能并不保存相关信息，
//quit是完整有序的停止nginx  ，并保存相关信息。nginx启动与停止命令的效果都可以通过Windows任务管理器中的进程选项卡观察。
nginx -s quit
nginx -s stop//重启服务：
nginx -s reload//检查配置文件是否有语法错误
nginx -t

2、location匹配优先级顺序

精确匹配 > (以 ^~开头)最长前缀匹配 > 正则匹配 > 普通前缀匹配（越长越大）
location = 路径 > location ^~ >location ~ / ~* > location /test > location /

★★★创做不易，对你有帮助的话，麻烦给个三连★★★