碼上歡樂
相關內容    簡體    繁體

Nginx全面配置

本文轉載自   查看原文   2022-02-10 08:16   979    Nginx

Nginx概述

image.png

Nginx 是開源、高性能、高可靠的 Web 和反向代理服務器，而且支持熱部署，幾乎可以做到 7 * 24 小時不間斷運行，即使運行幾個月也不需要重新啟動，還能在不間斷服務的情況下對軟件版本進行熱更新。性能是 Nginx 最重要的考量，其占用內存少、並發能力強、能支持高達 5w 個並發連接數，最重要的是， Nginx 是免費的並可以商業化，配置使用也比較簡單。

官網對各個模塊參數配置的解釋說明網址： Nginx中文文檔

Nginx特點

  • 高並發、高性能；
  • 模塊化架構使得它的擴展性非常好；
  • 異步非阻塞的事件驅動模型這點和 Node.js 相似；
  • 相對於其它服務器來說它可以連續幾個月甚至更長而不需要重啟服務器使得它具有高可靠性；
  • 熱部署、平滑升級；
  • 完全開源，生態繁榮；

Nginx作用

Nginx 的最重要的幾個使用場景：

  1. 靜態資源服務，通過本地文件系統提供服務；
  2. 反向代理服務，延伸出包括緩存、負載均衡等；
  3. API 服務， OpenResty ；

對於前端來說 Node.js 並不陌生， Nginx 和 Node.js 的很多理念類似， HTTP 服務器、事件驅動、異步非阻塞等，且 Nginx 的大部分功能使用 Node.js 也可以實現，但 Nginx 和 Node.js 並不沖突，都有自己擅長的領域。 Nginx 擅長於底層服務器端資源的處理（靜態資源處理轉發、反向代理，負載均衡等）， Node.js 更擅長上層具體業務邏輯的處理，兩者可以完美組合。

用一張圖表示：

未命名文件.png

Nginx常用命令

nginx -s reload  # 向主進程發送信號，重新加載配置文件，熱重啟
nginx -s reopen	 # 重啟 Nginx
nginx -s stop    # 快速關閉
nginx -s quit    # 等待工作進程處理完成后關閉
nginx -T         # 查看當前 Nginx 最終的配置
nginx -t         # 檢查配置是否有問題

Nginx核心配置

nginx.conf配置文件結構

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;   # 同上
    }
}
  • main 全局配置，對全局生效；
  • events 配置影響 Nginx 服務器與用戶的網絡連接；
  • http 配置代理，緩存，日志定義等絕大多數功能和第三方模塊的配置；
  • server 配置虛擬主機的相關參數，一個 http 塊中可以有多個 server 塊；
  • location 用於配置匹配的 uri ；
  • upstream 配置后端服務器具體地址，負載均衡配置不可或缺的部分；

用一張圖清晰的展示它的層級結構：

未命名文件 (4).png

nginx.conf 配置文件的語法規則：

  1. 配置文件由指令與指令塊構成
  2. 每條指令以 “;” 分號結尾，指令與參數間以空格符號分隔
  3. 指令塊以 {} 大括號將多條指令組織在一起
  4. include 語句允許組合多個配置文件以提升可維護性
  5. 通過 # 符號添加注釋，提高可讀性
  6. 通過 $ 符號使用變量
  7. 部分指令的參數支持正則表達式，例如常用的 location 指令

配置文件 main 段核心參數

user

指定運行 Nginx 的 woker 子進程的屬主和屬組，其中組可以不指定。

#語法：user USERNAME [GROUP]

user nginx lion; # 用戶是nginx;組是lion

pid

指定運行 Nginx master 主進程的 pid 文件存放路徑。

pid /opt/nginx/logs/nginx.pid # master主進程的的pid存放在nginx.pid的文件

worker_rlimit_nofile_number

指定worker子進程可以打開的最大文件句柄數。

worker_rlimit_nofile 20480; # 可以理解成每個worker子進程的最大連接數量。

worker_rlimit_core

指定 worker 子進程異常終止后的 core 文件，用於記錄分析問題。

worker_rlimit_core 50M; # 存放大小限制
working_directory /opt/nginx/tmp; # 存放目錄

worker_processes_number

指定 Nginx 啟動的 worker 子進程數量。

worker_processes 4; # 指定具體子進程數量
worker_processes auto; # 與當前cpu物理核心數一致

worker_cpu_affinity

將每個 worker 子進程與我們的 cpu 物理核心綁定。

worker_cpu_affinity 0001 0010 0100 1000; # 4個物理核心，4個worker子進程

未命名文件 (1).png

將每個 worker 子進程與特定 CPU 物理核心綁定，優勢在於，避免同一個 worker 子進程在不同的 CPU 核心上切換，緩存失效，降低性能。但其並不能真正的避免進程切換。

worker_priority

指定 worker 子進程的 nice 值，以調整運行 Nginx 的優先級，通常設定為負值，以優先調用 Nginx 。

worker_priority -10; # 120-10=110，110就是最終的優先級

Linux 默認進程的優先級值是120，值越小越優先； nice 值范圍為 -20 到 +19 。

備注：應用的默認優先級值是120加上 nice 值等於它最終的值，這個值越小，優先級越高。

worker_shutdown_timeout

指定 worker 子進程優雅退出時的超時時間。

worker_shutdown_timeout 5s;

timer_resolution

worker 子進程內部使用的計時器精度，調整時間間隔越大，系統調用越少，有利於性能提升；反之，系統調用越多，性能下降。

timer_resolution 100ms;

在 Linux 系統中，用戶需要獲取計時器時需要向操作系統內核發送請求，有請求就必然會有開銷，因此這個間隔越大開銷就越小。

daemon

指定 Nginx 的運行方式，前台還是后台，前台用於調試，后台用於生產。

daemon off; # 默認是on，后台運行模式

配置文件 events 段核心參數

use

Nginx 使用何種事件驅動模型。

use method; # 不推薦配置它，讓nginx自己選擇

method 可選值為：select、poll、kqueue、epoll、/dev/poll、eventport

worker_connections

worker 子進程能夠處理的最大並發連接數。

worker_connections 1024 # 每個子進程的最大連接數為1024

accept_mutex

是否打開負載均衡互斥鎖。

accept_mutex on # 默認是off關閉的，這里推薦打開

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 解析 hosts

# 添加如下內容，其中 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 時，會進行“正則匹配”；

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 則只取定義路徑。

alias

它也是指定靜態資源目錄位置，它只能寫在 location 中。

location /image {
	alias /opt/nginx/static/image/;
}

#當用戶訪問 www.test.com/image/1.png 時，實際在服務器找的路徑是 /opt/nginx/static/image/1.png

注意： 使用 alias 末尾一定要添加 / ，並且它只能位於 location 中。 

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 文件。

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 ; # 返回重定向地址
}

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 靜態資源。

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 命令。

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/ 路徑下的文件展示出來，如下圖所示：

image.png

Nginx內置變量

nginx 常用的內置全局變量，你可以在配置中隨意使用：

實例演示：

server{
	listen 8081;
	server_name var.lion-test.club;
	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://var.lion-test.club: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常用配置

Nginx應用核心概念 

代理是在服務器和客戶端之間假設的一層服務器，代理將接收客戶端的請求並將它轉發給服務器，然后將服務端的響應轉發給客戶端。

不管是正向代理還是反向代理，實現的都是上面的功能。

image.png

正向代理

正向代理，意思是一個位於客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求並指定目標(原始服務器)，然后代理向原始服務器轉交請求並將獲得的內容返回給客戶端。

正向代理是為我們服務的，即為客戶端服務的，客戶端可以根據正向代理訪問到它本身無法訪問到的服務器資源。

正向代理對我們是透明的，對服務端是非透明的，即服務端並不知道自己收到的是來自代理的訪問還是來自真實客戶端的訪問。

反向代理

反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然后將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器。

反向代理是為服務端服務的，反向代理可以幫助服務器接收來自客戶端的請求，幫助服務器做請求轉發，負載均衡等。

反向代理對服務端是透明的，對我們是非透明的，即我們並不知道自己訪問的是代理服務器，而服務器知道反向代理在為它服務。

反向代理的優勢：

  • 隱藏真實服務器；
  • 負載均衡便於橫向擴充后端動態服務；
  • 動靜分離，提升系統健壯性；

那么“動靜分離”是什么？負載均衡又是什么？

動靜分離

動靜分離是指在 web 服務器架構中，將靜態頁面與動態頁面或者靜態內容接口和動態內容接口分開不同系統訪問的架構設計方法，進而提示整個服務的訪問性和可維護性。

一般來說，都需要將動態資源和靜態資源分開，由於 Nginx 的高並發和靜態資源緩存等特性，經常將靜態資源部署在 Nginx 上。如果請求的是靜態資源，直接到靜態資源目錄獲取資源，如果是動態資源的請求，則利用反向代理的原理，把請求轉發給對應后台應用去處理，從而實現動靜分離。

使用前后端分離后，可以很大程度提升靜態資源的訪問速度，即使動態服務不可用，靜態資源的訪問也不會受到影響。

負載均衡

一般情況下，客戶端發送多個請求到服務器，服務器處理請求，其中一部分可能要操作一些資源比如數據庫、靜態資源等，服務器處理完畢后，再將結果返回給客戶端。

這種模式對於早期的系統來說，功能要求不復雜，且並發請求相對較少的情況下還能勝任，成本也低。隨着信息數量不斷增長，訪問量和數據量飛速增長，以及系統業務復雜度持續增加，這種做法已無法滿足要求，並發量特別大時，服務器容易崩。

很明顯這是由於服務器性能的瓶頸造成的問題，除了堆機器之外，最重要的做法就是負載均衡。

請求爆發式增長的情況下，單個機器性能再強勁也無法滿足要求了，這個時候集群的概念產生了，單個服務器解決不了的問題，可以使用多個服務器，然后將請求分發到各個服務器上，將負載分發到不同的服務器，這就是負載均衡，核心是「分攤壓力」。 Nginx 實現負載均衡，一般來說指的是將請求轉發給服務器集群。

舉個具體的例子，晚高峰乘坐地鐵的時候，入站口經常會有地鐵工作人員大喇叭“請走 B 口， B 口人少車空....”，這個工作人員的作用就是負載均衡。

Nginx 實現負載均衡的策略：

  • 輪詢策略：默認情況下采用的策略，將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的，但是如果其中某一台服務器壓力太大，出現延遲，會影響所有分配在這台服務器下的用戶。
  • 最小連接數策略：將請求優先分配給壓力較小的服務器，它可以平衡每個隊列的長度，並避免向壓力大的服務器添加更多的請求。
  • 最快響應時間策略：優先分配給響應時間最短的服務器。
  • 客戶端 ip 綁定策略：來自同一個 ip 的請求永遠只分配一台服務器，有效解決了動態網頁存在的 session 共享問題。

Nginx實戰配置

upstream

用於定義上游服務器（指的就是后台提供的應用服務器）的相關信息。

未命名文件 (2).png

語法：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 隨機負載均衡算法；

server

定義上游服務器地址。

語法：server address [parameters]

上下文：upstream

parameters 可選值：

  • weight=number 權重值，默認為1；
  • max_conns=number 上游服務器的最大並發連接數；
  • fail_timeout=time 服務器不可用的判定時間；
  • max_fails=numer 服務器不可用的檢查次數；
  • backup 備份服務器，僅當其他服務器都不可用時才會啟用；
  • down 標記服務器長期不可用，離線維護；

keepalive

限制每個 worker 子進程與上游服務器空閑長連接的最大數量。

keepalive connections;

上下文：upstream

示例：keepalive 16;

keepalive_requests

單個長連接可以處理的最多 HTTP 請求個數。

語法：keepalive_requests number;

默認值：keepalive_requests 100;

上下文：upstream

keepalive_timeout

空閑長連接的最長保持時間。

語法：keepalive_timeout time;

默認值：keepalive_timeout 60s;

上下文：upstream

配置示例

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;
}

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 參數原則：

  1. URL 必須以 http 或 https 開頭；
  2. URL 中可以攜帶變量；
  3. URL 中是否帶 URI ，會直接影響發往上游請求的 URL ；

接下來讓我們來看看兩種常見的 URL 用法：

  1. proxy_pass http://192.168.100.33:8081 
  2. proxy_pass http://192.168.100.33:8081/

這兩種用法的區別就是帶 / 和不帶 / ，在配置代理時它們的區別可大了：

  • 不帶 / 意味着 Nginx 不會修改用戶 URL ，而是直接透傳給上游的應用服務器；
  • 帶 / 意味着 Nginx 會修改用戶 URL ，修改方法是將 location 后的 URL 從用戶 URL 中刪除；

不帶 / 的用法：

location /bbs/{
  proxy_pass http://127.0.0.1:8080;
}

分析：

  1. 用戶請求 URL：/bbs/abc/test.html 
  2. 請求到達 Nginx 的 URL：/bbs/abc/test.html 
  3. 請求到達上游應用服務器的 URL：/bbs/abc/test.html 

帶 / 的用法：

location /bbs/{
  proxy_pass http://127.0.0.1:8080/;
}

分析：

  1. 用戶請求 URL： /bbs/abc/test.html 
  2. 請求到達 Nginx 的 URL： /bbs/abc/test.html 
  3. 請求到達上游應用服務器的URL： /abc/test.html 

並沒有拼接上 /bbs ，這點和 root 與 alias 之間的區別是保持一致的。

配置反向代理

這里為了演示更加接近實際，作者准備了兩台雲服務器，它們的公網 IP 分別是：121.42.11.34 與 121.5.180.193 。

我們把 121.42.11.34 服務器作為上游服務器，做如下配置：

# /etc/nginx/conf.d/proxy.conf
server{
  listen 8080;
  server_name localhost;
  
  location /proxy/ {
    root /usr/share/nginx/html/proxy;
    index index.html;
  }
}

# /usr/share/nginx/html/proxy/index.html
<h1> 121.42.11.34 proxy html </h1>

配置完成后重新加載配置文件 nginx -s reload 。

把 121.5.180.193 服務器作為代理服務器，做如下配置：

# /etc/nginx/conf.d/proxy.conf
upstream back_end {
  server 121.42.11.34:8080 weight=2 max_conns=1000 fail_timeout=10s max_fails=3;
  keepalive 32;
  keepalive_requests 80;
  keepalive_timeout 20s;
}

server {
  listen 80;
  server_name proxy.lion.club;
  location /proxy {
  	proxy_pass http://back_end/proxy;
  }
}

本地機器要訪問 proxy.lion.club 域名，因此需要配置本地 hosts ，通過命令：vim /etc/hosts 進入配置文件，添加如下內容：

121.5.180.193 proxy.lion.club

image.png

分析：

  1. 當訪問 proxy.lion.club/proxy 時通過 upstream 的配置找到 121.42.11.34:8080 ；
  2. 因此訪問地址變為 http://121.42.11.34:8080/proxy ；
  3. 連接到 121.42.11.34 服務器，找到 8080 端口提供的 server ；
  4. 通過 server 找到 /usr/share/nginx/html/proxy/index.html 資源，最終展示出來。

配置負載均衡

配置負載均衡主要是要使用 upstream 指令。

我們把 121.42.11.34 服務器作為上游服務器，做如下配置：

server{
  listen 8020;
  location / {
  	return 200 'return 8020 \n';
  }
}

server{
  listen 8030;
  location / {
  	return 200 'return 8030 \n';
  }
}

server{
  listen 8040;
  location / {
  	return 200 'return 8040 \n';
  }
}

把 121.5.180.193 服務器作為代理服務器，做如下配置：

upstream demo_server {
  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;
  }
}

配置完成后重啟 Nginx 服務器。並且在需要訪問的客戶端配置好 ip 和域名的映射關系。

# /etc/hosts

121.5.180.193 balance.lion.club

在客戶端機器執行 curl http://balance.lion.club/balance/ 命令：

image.png

不難看出，負載均衡的配置已經生效了，每次給我們分發的上游服務器都不一樣。就是通過簡單的輪詢策略進行上游服務器分發。

接下來，我們再來了解下 Nginx 的其它分發策略。

hash 算法

通過指定關鍵字作為 hash key ，基於 hash 算法映射到特定的上游服務器中。關鍵字可以包含有變量、字符串。

upstream demo_server {
  hash $request_uri;
  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;
  }
}

hash $request_uri 表示使用 request_uri 變量作為 hash 的 key 值，只要訪問的 URI 保持不變，就會一直分發給同一台服務器。

ip_hash

根據客戶端的請求 ip 進行判斷，只要 ip 地址不變就永遠分配到同一台主機。它可以有效解決后台服務器 session 保持的問題。

upstream demo_server {
  ip_hash;
  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;
  }
}

最少連接數算法

各個 worker 子進程通過讀取共享內存的數據，來獲取后端服務器的信息。來挑選一台當前已建立連接數最少的服務器進行分配請求。

語法：least_conn;

上下文：upstream;

示例：

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;
  }
}

配置緩存

緩存可以非常有效的提升性能，因此不論是客戶端（瀏覽器），還是代理服務器（ Nginx ），乃至上游服務器都多少會涉及到緩存。可見緩存在每個環節都是非常重要的。下面讓我們來學習 Nginx 中如何設置緩存策略。

proxy_cache

存儲一些之前被訪問過、而且可能將要被再次訪問的資源，使用戶可以直接從代理服務器獲得，從而減少上游服務器的壓力，加快整個訪問速度。

語法：proxy_cache zone | off ; # zone 是共享內存的名稱

默認值：proxy_cache off;

上下文：http、server、location

proxy_cache_path

設置緩存文件的存放路徑。

語法：proxy_cache_path path [level=levels] ...可選參數省略，下面會詳細列舉

默認值：proxy_cache_path off

上下文：http

參數含義：

  • path 緩存文件的存放路徑；
  • level path的目錄層級；
  • keys_zone 設置共享內存；
  • inactive 在指定時間內沒有被訪問，緩存會被清理，默認10分鍾；

proxy_cache_key

設置緩存文件的 key 。

語法：proxy_cache_key

默認值：proxy_cache_key $scheme$proxy_host$request_uri;

上下文：http、server、location

proxy_cache_valid

配置什么狀態碼可以被緩存，以及緩存時長。

語法：proxy_cache_valid [code...] time;

上下文：http、server、location

配置示例：proxy_cache_valid 200 304 2m;; # 說明對於狀態為200和304的緩存文件的緩存時間是2分鍾

proxy_no_cache

定義相應保存到緩存的條件，如果字符串參數的至少一個值不為空且不等於“ 0”，則將不保存該響應到緩存。

語法：proxy_no_cache string;

上下文：http、server、location

示例：proxy_no_cache $http_pragma    $http_authorization;

proxy_cache_bypass

定義條件，在該條件下將不會從緩存中獲取響應。

語法：proxy_cache_bypass string;

上下文：http、server、location

示例：proxy_cache_bypass $http_pragma    $http_authorization;

upstream_cache_status 變量

它存儲了緩存是否命中的信息，會設置在響應頭信息中，在調試中非常有用。

MISS: 未命中緩存
HIT： 命中緩存
EXPIRED: 緩存過期
STALE: 命中了陳舊緩存
REVALIDDATED: Nginx驗證陳舊緩存依然有效
UPDATING: 內容陳舊，但正在更新
BYPASS: X響應從原始服務器獲取

配置實例

我們把 121.42.11.34 服務器作為上游服務器，做如下配置：

server {
  listen 1010;
  root /usr/share/nginx/html/1010;
  location / {
  	index index.html;
  }
}

server {
  listen 1020;
  root /usr/share/nginx/html/1020;
  location / {
  	index index.html;
  }
}

把 121.5.180.193 服務器作為代理服務器，做如下配置：

proxy_cache_path /etc/nginx/cache_temp levels=2:2 keys_zone=cache_zone:30m max_size=2g inactive=60m use_temp_path=off;

upstream cache_server{
  server 121.42.11.34:1010;
  server 121.42.11.34:1020;
}

server {
  listen 80;
  server_name cache.lion.club;
  location / {
    proxy_cache cache_zone; # 設置緩存內存，上面配置中已經定義好的
    proxy_cache_valid 200 5m; # 緩存狀態為200的請求，緩存時長為5分鍾
    proxy_cache_key $request_uri; # 緩存文件的key為請求的URI
    add_header Nginx-Cache-Status $upstream_cache_status # 把緩存狀態設置為頭部信息，響應給客戶端
    proxy_pass http://cache_server; # 代理轉發
  }
}

緩存就是這樣配置，我們可以在 /etc/nginx/cache_temp 路徑下找到相應的緩存文件。

對於一些實時性要求非常高的頁面或數據來說，就不應該去設置緩存，下面來看看如何配置不緩存的內容。

...

server {
  listen 80;
  server_name cache.lion.club;
  # URI 中后綴為 .txt 或 .text 的設置變量值為 "no cache"
  if ($request_uri ~ \.(txt|text)$) {
  	set $cache_name "no cache"
  }
  
  location / {
    proxy_no_cache $cache_name; # 判斷該變量是否有值，如果有值則不進行緩存，如果沒有值則進行緩存
    proxy_cache cache_zone; # 設置緩存內存
    proxy_cache_valid 200 5m; # 緩存狀態為200的請求，緩存時長為5分鍾
    proxy_cache_key $request_uri; # 緩存文件的key為請求的URI
    add_header Nginx-Cache-Status $upstream_cache_status # 把緩存狀態設置為頭部信息，響應給客戶端
    proxy_pass http://cache_server; # 代理轉發
  }
}

HTTPS

在學習如何配置 HTTPS 之前，我們先來簡單回顧下 HTTPS 的工作流程是怎么樣的？它是如何進行加密保證安全的？

HTTPS 工作流程

  1. 客戶端（瀏覽器）訪問 https://www.baidu.com 百度網站；
  2. 百度服務器返回 HTTPS 使用的 CA 證書；
  3. 瀏覽器驗證 CA 證書是否為合法證書；
  4. 驗證通過，證書合法，生成一串隨機數並使用公鑰（證書中提供的）進行加密；
  5. 發送公鑰加密后的隨機數給百度服務器；
  6. 百度服務器拿到密文，通過私鑰進行解密，獲取到隨機數（公鑰加密，私鑰解密，反之也可以）；
  7. 百度服務器把要發送給瀏覽器的內容，使用隨機數進行加密后傳輸給瀏覽器；
  8. 此時瀏覽器可以使用隨機數進行解密，獲取到服務器的真實傳輸內容；

這就是 HTTPS 的基本運作原理，使用對稱加密和非對稱機密配合使用，保證傳輸內容的安全性。

關於HTTPS更多知識，可以查看另外一篇文章《學習 HTTP 協議》。

配置證書

下載證書的壓縮文件，里面有個 Nginx  文件夾，把 xxx.crt 和 xxx.key 文件拷貝到服務器目錄，再進行如下配置：

server {
  listen 443 ssl http2 default_server;   # SSL 訪問端口號為 443
  server_name lion.club;         # 填寫綁定證書的域名(我這里是隨便寫的)
  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;
  }
}

配置跨域 CORS

跨域的定義

同源策略限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。通常不允許不同源間的讀操作。

同源的定義

如果兩個頁面的協議，端口（如果有指定）和域名都相同，則兩個頁面具有相同的源。

下面給出了與 URL http://store.company.com/dir/page.html 的源進行對比的示例：

http://store.company.com/dir2/other.html 同源
https://store.company.com/secure.html 不同源，協議不同
http://store.company.com:81/dir/etc.html 不同源，端口不同
http://news.company.com/dir/other.html 不同源，主機不同

不同源會有如下限制：

  • Web 數據層面，同源策略限制了不同源的站點讀取當前站點的 Cookie 、 IndexDB 、 LocalStorage 等數據。
  • DOM 層面，同源策略限制了來自不同源的 JavaScript 腳本對當前 DOM 對象讀和寫的操作。
  • 網絡層面，同源策略限制了通過 XMLHttpRequest 等方式將站點的數據發送給不同源的站點。

Nginx 解決跨域的原理

例如：

  • 前端 server 的域名為： fe.server.com 
  • 后端服務的域名為： dev.server.com 

現在我在 fe.server.com 對 dev.server.com 發起請求一定會出現跨域。

現在我們只需要啟動一個 Nginx 服務器，將 server_name 設置為 fe.server.com 然后設置相應的 location 以攔截前端需要跨域的請求，最后將請求代理回 dev.server.com 。如下面的配置：

server {
	listen   		 80;
	server_name  fe.server.com;
	location / {
		proxy_pass dev.server.com;
	}
}

這樣可以完美繞過瀏覽器的同源策略： fe.server.com 訪問 Nginx 的 fe.server.com 屬於同源訪問，而 Nginx 對服務端轉發的請求不會觸發瀏覽器的同源策略。

配置開啟 gzip 壓縮

GZIP 是規定的三種標准 HTTP 壓縮格式之一。目前絕大多數的網站都在使用 GZIP 傳輸 HTML 、CSS 、 JavaScript 等資源文件。

對於文本文件， GZiP 的效果非常明顯，開啟后傳輸所需流量大約會降至 1/4~1/3 。

並不是每個瀏覽器都支持 gzip 的，如何知道客戶端是否支持 gzip 呢，請求頭中的 Accept-Encoding 來標識對壓縮的支持。

image.png

啟用 gzip 同時需要客戶端和服務端的支持，如果客戶端支持 gzip 的解析，那么只要服務端能夠返回 gzip 的文件就可以啟用 gzip 了,我們可以通過 Nginx 的配置來讓服務端支持 gzip 。下面的 respone 中 content-encoding:gzip ，指服務端開啟了 gzip 的壓縮方式。

image.png

# # 默認off，是否開啟gzip
gzip on; 
# 要采用 gzip 壓縮的 MIME 文件類型，其中 text/html 被系統強制啟用；
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

# ---- 以上兩個參數開啟就可以支持Gzip壓縮了 ---- #

# 默認 off，該模塊啟用后，Nginx 首先檢查是否存在請求靜態文件的 gz 結尾的文件，如果有則直接返回該 .gz 文件內容；
gzip_static on;

# 默認 off，nginx做為反向代理時啟用，用於設置啟用或禁用從代理服務器上收到相應內容 gzip 壓縮；
gzip_proxied any;

# 用於在響應消息頭中添加 Vary：Accept-Encoding，使代理服務器根據請求頭中的 Accept-Encoding 識別是否啟用 gzip 壓縮；
gzip_vary on;

# gzip 壓縮比，壓縮級別是 1-9，1 壓縮級別最低，9 最高，級別越高壓縮率越大，壓縮時間越長，建議 4-6；
gzip_comp_level 6;

# 獲取多少內存用於緩存壓縮結果，16 8k 表示以 8k*16 為單位獲得；
gzip_buffers 16 8k;

# 允許壓縮的頁面最小字節數，頁面字節數從header頭中的 Content-Length 中進行獲取。默認值是 0，不管頁面多大都壓縮。建議設置成大於 1k 的字節數，小於 1k 可能會越壓越大；
# gzip_min_length 1k;

# 默認 1.1，啟用 gzip 所需的 HTTP 最低版本；
gzip_http_version 1.1;

配置正向代理

如果把局域網外的Internet想象成一個巨大的資源庫，則局域網中的客戶端要訪問Internet，則需要通過代理服務器來訪問，這種代理服務就稱為正向代理。

Nginx正向代理涉及到的指令較少，下面直接貼上其配置文件內容：

...  
server {  
    resolver 192.168.1.1; #指定DNS服務器IP地址  
    listen 8080;  
    location / {  
        proxy_pass http://$http_host$request_uri; #設定代理服務器的協議和地址  
    }  
}  
...

其中：

resolver 必須的，表示DNS服務器 
location 表示匹配用戶訪問的資源，並作進一步轉交和處理，可用正則表達式匹配 
proxy_pass 表示需要代理的地址 
$http_host 表示用戶訪問資源的主機部分 
$request_uri 表示用戶訪問資源的URI部分。 

如，http://nginx.org/download/nginx-1.6.3.tar.gz，則$http_host=nginx.org，$request_uri=/download/nginx-1.6.3.tar.gz。

可以不設置監聽端口號，nginx默認監聽80端口，除非你要修改監聽端口，可以用listen字段指定。

可以看出，對於正向代理，只是對用戶的訪問進行一個轉發，不做其他處理。

配置Nginx黑白名單

Nginx利用deny和allow指令來實現黑白名單的配置，利用黑白名單進行安全配置。

#語法
allow address | CIDR | all;
deny address | CIDR | all;

#模塊：http/server/location
#參數說明：
#allow：允許訪問。
#deny：禁止訪問。
#address：具體的ip地址。
#CIDR：ip加掩碼形式地址。
#all：所有ip地址。

1、黑名單

在這個配置下，234、235和236的ip訪問不了服務器，會顯示403 Forbidden，而其他ip都可以訪問。

2、白名單

配置策略：白名單配置邏輯是配置允許的ip訪問，禁止其他所有的地址訪問。

配置詳解：在這個配置下，234、235和236的ip可以訪問服務器，而其他所有ip都不允許訪問，顯示403 Forbidden。

配置禁止訪問文件或文件夾

location ^~ /project/deny.txt {
    alias   /webroot/proj/;
    deny  all;
}
  • ^~ /project/ 意思是接受從外部訪問（如瀏覽器）的 URL 地址，比如www.domain.com/project；
  • ^~ /project/deny.txt 意思是這一條 location 明確是對其起作用的；
  • alias /webroot/proj/ 意思是將 對 /project 的訪問解析到 /webroot/proj 目錄；
  • deny  all 意思是屏蔽任何來源

也可以把 deny all 改換成 return 404，這樣將返回 404 而不是 403 Forbidden，更有“欺騙性”。

Nginx高可用

一般是Nginx + Keepalived來實現Nginx的高可用。

什么是Keepalived

Keepalived是一個免費開源的，用C編寫的類似於layer3, 4 & 7交換機制軟件，具備我們平時說的第3層、第4層和第7層交換機的功能。主要提供loadbalancing（負載均衡）和 high-availability（高可用）功能，負載均衡實現需要依賴Linux的虛擬服務內核模塊（ipvs），而高可用是通過VRRP協議實現多台機器之間的故障轉移服務。 

Keepalived的所有功能是配置keepalived.conf文件來實現的。

附錄

配置優化 – NGINX.CONF

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 【Nginx】如何配置Nginx日志？這是最全面的一篇了！！ 全面解析Linux如何啟動/停止/重啟Nginx nginx 實現valid_referer全面解析 非常全面的vim配置文件 nginx 配置 Nginx基本配置 lnmp全面優化集合nginx+mysql+php nginx配置logrotate 配置 nginx配置(windows配置） Nginx的使用（二）Nginx配置wordpress
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM