# 进入要放安装包的目录
cd /opt/software
# 下载安装包
wget https://nginx.org/download/nginx-1.20.2.tar.gz
# 解压缩
tar -zxvf nginx-1.20.2.tar.gz -C /opt/modules
# 进入解压后的目录
cd /opt/modules/nginx-1.20.2/
为了编译Nginx源码，我们需要标准的GCC编译器（GNU Compiler Collection,自由的类UNIX及Mac OS X操作系统的标准编译器），另外，我们需要通过Automake工具，完成自动创建Makefile的工作，除此以外，Nginx的一些模块还需要依赖其他第三方库，通常有pcre库（支持rewrite模块）、zlib库（支持gzip模块）和openssl库（支持ssl模块）。
可以通过如下指令去查看Linux服务器上是否已经安装pcre、zlib和openssl —— 转自原文链接
# 查看openssl
rpm -qa openssl
# 查看zlib
rpm -qa zlib
# 查看pcre
rpm -qa pcre
# 如果没有安装以上三个库，鉴于以上Nginx运行的需求，我们需要执行以下代码
yum -y install gcc gcc-c++ automake pcre pcre-devel zlib zlib-devel openssl openssl-devel
运行configure脚本程序，关于configure脚本程序参数解析可以看这篇文章：NGINX ./configure详解_冉半夏生的博客-CSDN博客
# 注意需要进入解压的nginx目录，--prefix指安装目录 默认为/usr/local/nginx
# http_stub_status_module 和 http_ssl_module这两个模块提供对HTTPS必要的支持
# stream 实现(TCP/UDP)负载均衡 1.9.0之前的版本不支持stream
./configure --prefix=/opt/modules/nginx --with-http_stub_status_module --with-http_ssl_module --with-stream
# 注意需要进入解压的nginx目录
make
make install
# 启动nginx,修改配置后要记得重启才能生效
/opt/modules/nginx/sbin/nginx -C /opt/modules/nginx-1.20.2/conf/nginx.conf
# 查看nginx是否启动
ps -ef | grep nginx
# 停止nginx
/opt/modules/nginx/sbin/nginx -s stop
# 重启nginx
/opt/modules/nginx/sbin/nginx -s reopen
# 重新载入配置文件
/opt/modules/nginx/sbin/nginx -s reload
转自Nginx Stream(TCP/UDP)负载均衡 (w3schools.cn)
注：stream 和http同级
Nginx 的 TCP/UDP 负载均衡是应用 Stream 代理模块（ngx_stream_proxy_module）和 Stream 上游模块（ngx_stream_upstream_module）实现的。Nginx 的 TCP 负载均衡与 LVS 都是四层负载均衡的应用，所不同的是，LVS 是被置于 Linux 内核中的，而 Nginx 是运行于用户层的，基于 Nginx 的 TCP 负载可以实现更灵活的用户访问管理和控制。
Nginx 的 Stream 上游模块支持与 Nginx HTTP 上游模块一致的 轮询（Round Robin）、**哈希（Hash）及最少连接数（least_conn）**负载均衡策略。Nginx 默认使用轮询负载均衡策略，可以根据服务器配置权重配置样例如下：
根据权重轮询访问服务器
stream {
upstream backend {
server 192.168.1.100:6666 weight=2;
server 192.168.1.101:6666 weight=1;
server 192.168.1.102:6666 weight=1;
}
server {
listen 8888;
proxy_pass backend;
}
}
哈希负载均衡策略可以通过客户端 IP（$remote_addr）实现简单的会话保持，其可将同一 IP 客户端始终转发给同一台后端服务器。
哈希负载均衡策略通过指令参数 consistent 设定是否开启一致性哈希负载均衡策略。Nginx 的一致性哈希负载均衡策略是采用 Ketama 一致性哈希算法，当后端服务器组中的服务器数量变化时，只会影响少部分客户端的请求。
stream {
upstream backend {
hash $remote_addr consistent;
server 192.168.1.100:6666 weight=2;
server 192.168.1.101:6666 weight=1;
server 192.168.1.102:6666 weight=1;
}
server {
listen 8888;
proxy_pass backend;
}
}
最少连接负载均衡策略，可以在后端被代理服务器性能不均时，在考虑上游服务器组中各服务器权重的前提下，将客户端连接分配给活跃连接最少的被代理服务器，从而有效提高处理性能高的被代理服务器的使用率。
stream {
upstream backend {
least_conn;
server 192.168.1.100:6666 weight=2;
server 192.168.1.101:6666 weight=1;
server 192.168.1.102:6666 weight=1;
}
server {
listen 8888;
proxy_pass backend;
}
}
Nginx 的 TCP/UDP 负载均衡在连接分配时也支持被动健康检测模式，如果与后端服务器建立连接失败，并在 fail_timeout 参数的时间内连续超过 max_fails 参数设置的次数，Nginx 就会将该服务器置为不可用状态，并且在 fail_timeout 参数的时间内不再给该服务器分配连接。当 fail_timeout 参数的时间结束时将尝试分配连接检测该服务器是否恢复，如果可以建立连接，则判定为恢复。
stream {
upstream backend {
server 192.168.1.100:6666 max_fails=3 fail_timeout=10s;
server 192.168.1.101:6666 max_fails=3 fail_timeout=10s;
server 192.168.1.102:6666 max_fails=3 fail_timeout=10s;
}
server {
proxy_connect_timeout 5s; # 与被代理服务器建立连接的超时时间为5s
proxy_timeout 10s; # 获取被代理服务器的响应最大超时时间为10s
# 当被代理的服务器返回错误或超时时，将未返回响应的客户端连接请求传递给upstream中的下
# 一个服务器
proxy_next_upstream on;
proxy_next_upstream_tries 3; # 转发尝试请求最多3次
proxy_next_upstream_timeout 10s; # 总尝试超时时间为10s
proxy_socket_keepalive on; # 开启SO_KEEPALIVE选项进行心跳检测
listen 8888;
proxy_pass backend;
}
}
其中的参数及指令说明如下。
TCP 连接在接收到关闭连接通知前将一直保持连接，当 Nginx 与被代理服务器的两个连续成功的读或写操作的最大间隔时间超过 proxy_timeout 指令配置的时间时，连接将会被关闭。在 TCP 长连接的场景中，应适当调整 proxy_timeout 的设置，同时关注系统内核 SO_KEEPALIVE 选项的配置，可以防止过早地断开连接。
反向代理应该是Nginx使用最多的功能了，反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。
反向代理通过proxy_pass指令来实现。
server {
listen 8888;
server_name localhost;
location /aaa {
proxy_pass http://192.168.1.100:6666;
error_page 404 @error;
}
location /bbb {
proxy_pass http://192.168.1.101:6666;
error_page 404 @error;
}
location @error{
proxy_pass http://error;
}
}
这个简单的实现案例就是把访问这台服务器8888端口的请求转发到192.168.1.100这台服务器6666端口
location 是 Nginx 对 HTTP 请求中的 URI 进行匹配处理的指令，location 的语法形式如下：
location [=|~|~*|^~|@] pattern { ... }
其中，[=|~*|^~|@]部分称为 location 修饰语（Modifier），修饰语定义了与 URI 的匹配方式。pattern 为匹配项，可以是字符串或正则表达式。
location 中的字符有没有 / 都没有影响。也就是说 /homepage/ 和 /homepage 是一样的
如果 URI 结构是 https://domain.com/ 的形式，尾部有没有 / 都不会造成重定向。因为浏览器在发起请求的时候，默认加上了 / 。虽然很多浏览器在地址栏里也不会显示 / 。
如果 URI 的结构是 https://domain.com/homepage/ 。尾部如果缺少 / 将导致重定向。因为根据约定，URL 尾部的 / 表示目录，没有 / 表示文件。所以访问 /homepage/ 时，服务器会自动去该目录下找对应的默认文件。如果访问 /homepage 的话，服务器会先去找 homepage 文件，找不到的话会将 homepage 当成目录，重定向到 /homepage/ ，去该目录下找默认文件 来源: https://juejin.cn/post/7044438248495513614
当有多条 location 规则时，nginx 有一套比较复杂的规则，如下
=^~（立刻停止后续的正则搜索）~或~*不加任何规则时，默认是大小写敏感，前缀匹配，相当于加了~ 与 ^~
# 匹配所有以/abc开头的url请求
location /abc {
proxy_pass http://192.168.1.100:6666;
}
精确匹配pattern,pattern后不能带任何字符串
location = /abc {
proxy_pass http://192.168.1.100:6666;
}
/)区分大小写的正则匹配，匹配项的内容必须是正则表达式
location ~ ^/abc$ {
proxy_pass http://192.168.1.100:6666;
}
/)不区分大小写的正则匹配，匹配项的内容必须是正则表达式
location ~* ^/Abc$ {
proxy_pass http://192.168.1.100:6666;
}
/)前缀匹配
location ^~ /abc {
proxy_pass http://192.168.1.100:6666;
}
定义一个只能内部访问的 location 区域，可以被其他内部跳转指令使用，如 try_files 或 error_page。
location /index {
error_page 404 @error;
}
location @error{
proxy_pass http://error;
}
表示以 /index 开头的请求，如果链接的状态为 404。则会匹配到 @index_error 这条规则上