基礎(chǔ)配置信息

# ===========  全局配置  ===========
worker_processes 1;  # 設(shè)置工作進(jìn)程數(shù)為1

#error_log  logs/error.log;             # 指定了錯(cuò)誤日志的位置
#error_log  logs/error.log  notice;     # 設(shè)置了錯(cuò)誤日志的級別為 notice，表示只記錄通知級別的錯(cuò)誤
#error_log  logs/error.log  info;       # 設(shè)置了錯(cuò)誤日志的級別為 info，表示只記錄信息級別的錯(cuò)誤

#pid        logs/nginx.pid;             # 指定了進(jìn)程 ID 文件的位置


# =========== events塊 =================
events {
    worker_connections 1024;  # 設(shè)置每個(gè)工作進(jìn)程的最大連接數(shù)
}

# ===========  http塊 ==================
http {
    include mime.types;  # 包含MIME類型配置文件
    default_type application/octet-stream;  # 默認(rèn)文件類型為二進(jìn)制流

    sendfile on;  # 啟用文件傳輸優(yōu)化
    keepalive_timeout 65;  # 客戶端與服務(wù)器之間的連接保持時(shí)間
    client_max_body_size 20M; # 設(shè)置最大請求體大小為20MB

	# 定義一個(gè) 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 壓縮功能。將服務(wù)器響應(yīng)的內(nèi)容進(jìn)行壓縮，以減少傳輸?shù)臄?shù)據(jù)量。
	# 這有助于提高網(wǎng)站的加載速度，特別是對于大型文件或文本內(nèi)容來說效果更明顯。
	# gzip  on;


	# ======== server塊（虛擬主機(jī)） 【可配置多個(gè)】=============
	server {
		# 見下面應(yīng)用場景，根據(jù)具體場景具體配置
	}

}
	
# =========== 日志格式解析 ==============
# 定義一個(gè) Nginx 訪問日志的格式，稱為 main：
# $remote_addr: 客戶端的IP地址。
# $remote_user: 客戶端的用戶名（如果有）。
# $time_local: 請求的本地時(shí)間。
# $request: 客戶端請求的內(nèi)容。
# $status: 服務(wù)器響應(yīng)的狀態(tài)碼。
# $body_bytes_sent: 發(fā)送給客戶端的字節(jié)數(shù)。
# $http_referer: 客戶端請求的來源頁面。
# $http_user_agent: 客戶端的用戶代理（通常是瀏覽器信息）。
# $http_x_forwarded_for: 客戶端的原始IP地址（如果使用了代理服務(wù)器）。
# 這個(gè)格式將這些信息按照一定的順序記錄到訪問日志中，方便后續(xù)分析和監(jiān)控服務(wù)器的訪問情況。

應(yīng)用場景一：配置web服務(wù)器

server {

	listen 80;  # 監(jiān)聽端口80
	server_name localhost;  # 指定服務(wù)器的域名
	charset utf-8; # 設(shè)置字符集為UTF-8
	# 指定了上面配置的訪問日志位置【不需要可省略】
	# access_log  logs/host.access.log  main;	

	# 配置靜態(tài)文件服務(wù)和前端應(yīng)用
	location / {
		# 指定前端應(yīng)用的根目錄，路徑用 / 符號。
		root 【路徑】;
		# 嘗試匹配文件，如果找不到則重定向到index.html
		try_files $uri $uri/ /index.html;
		# 指定默認(rèn)的索引文件
		index index.html index.htm;
	}
	
	# 配置錯(cuò)誤頁面
	error_page 500 502 503 504 /50x.html;
	location = /50x.html {
		root html;
	}

}

應(yīng)用場景二：反向代理服務(wù)器

server {

	listen 80;  
	server_name localhost;  
	charset utf-8; 
	# access_log  logs/host.access.log  main;	

	# 配置用于處理請求路徑以 /prod-api/ 開頭的請求。這通常用于配置反向代理
	location /prod-api/ {
		# 設(shè)置反向代理請求的頭部信息。它將客戶端請求中的 Host 頭部傳遞給后端服務(wù)器
		proxy_set_header Host $http_host;
		
		# 設(shè)置 X-Real-IP 頭部，將客戶端的真實(shí) IP 地址傳遞給后端服務(wù)器。
        proxy_set_header X-Real-IP $remote_addr;
        
        # 設(shè)置自定義的 REMOTE-HOST 頭部，同樣將客戶端的 IP 地址傳遞給后端服務(wù)器。
        proxy_set_header REMOTE-HOST $remote_addr;
        
        # 設(shè)置 X-Forwarded-For 頭部，將客戶端的 IP 地址添加到已有的 X-Forwarded-For 頭部中，以便后端服務(wù)器知道請求的來源。
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

		# 指定了反向代理的目標(biāo)地址，將請求轉(zhuǎn)發(fā)到 http://localhost/，即本地的后端服務(wù)器
        proxy_pass http://localhost/;
	}
	
}

!!! 反向代理也可以基于請求路徑轉(zhuǎn)發(fā)到不同服務(wù)器 !!!

server {
	listen 80;
	server_name example.com;

	# 轉(zhuǎn)發(fā)到北京地區(qū)服務(wù)器
	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;
	}
	
	# 轉(zhuǎn)發(fā)到廣州地區(qū)服務(wù)器
	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;
	}

	# 其他路徑的請求，可根據(jù)需要配置
	
}

!!!反向代理路徑結(jié)尾加不加 / 符號的區(qū)別?。?！

#  ------ 結(jié)尾帶斜杠的情況 ------------
location /beijing/ {
	proxy_pass http://localhost:81/;
}

這個(gè)配置中，location /beijing/ 表示匹配以 /beijing/ 開頭的請求路徑。
當(dāng)收到類似 /beijing/foo 的請求時(shí)，會將請求轉(zhuǎn)發(fā)到 http://localhost:81/foo，
即會將原始請求中的 /beijing/ 部分去掉，并將剩余部分 /foo 附加到 proxy_pass 指定的地址后面。
【location/beijing/foo  ==> http://localhost:81/foo】

#  ------ 結(jié)尾不帶斜杠的情況 ------------
location /beijing/ {
	proxy_pass http://localhost:81;
}
在這個(gè)配置中，當(dāng)收到類似 /beijing/foo 的請求時(shí)， 
會將請求轉(zhuǎn)發(fā)到 http://localhost:81，不會將原始請求中的 /beijing/ 部分去掉。
因此，代理服務(wù)器收到的路徑仍然是 /beijing/foo
【location/beijing/foo  ==> http://localhost:81/beijing/foo】

應(yīng)用場景三：URL重定向

# ============== 域名重定向 ========================

server {
    listen 80;
    server_name example.com;

	# 使用 rewrite 實(shí)現(xiàn)重定向到新地址，permanent 表示 301 永久重定向，不加則為302 臨時(shí)重定向
	# rewrite 重定向配置更加靈活，但它需要在每個(gè)請求上執(zhí)行正則表達(dá)式匹配和重寫操作，相對而言稍微耗費(fèi)一些性能
	location / {
    	rewrite ^/(.*)$ http://new.example.com/$1 permanent;
    }
    
	# 使用return 重定向，不涉及正則表達(dá)式的匹配和重寫規(guī)則，更高效
	return 302 http://new.example.com$request_uri;

}

# ============== 路徑重定向 =================
server {
    listen 80;
    server_name example.com;

	location / {
    	rewrite ^/old-path/(.*)$ /new-path/$1;
    }

}

如果只是簡單的重定向操作，并且不需要進(jìn)行復(fù)雜的路徑重寫或捕獲，推薦使用 return 301 的方式來實(shí)現(xiàn)重定向。這樣能夠更直接、更高效地達(dá)到重定向的目的，避免不必要的正則表達(dá)式匹配和重寫操作。
.
.
.
301 重定向：
····性質(zhì)：301 表示所請求的資源已被永久移動(dòng)到新的 URL。這意味著瀏覽器下次訪問相同的原始 URL 時(shí)應(yīng)該直接使用新的 URL。
····特點(diǎn)：
Ⅰ、瀏覽器會緩存重定向的新 URL，下次訪問相同的舊 URL 時(shí)會直接跳轉(zhuǎn)到新 URL，不再發(fā)起請求舊 URL。
Ⅱ、搜索引擎會將原始 URL 的搜索排名轉(zhuǎn)移到新的 URL 上。
.
.
.
302 重定向：
····性質(zhì)：302 表示所請求的資源暫時(shí)被移動(dòng)到新的 URL，但將來可能會恢復(fù)到原始 URL。
····特點(diǎn)：
Ⅰ、瀏覽器會暫時(shí)緩存重定向的新 URL，下次訪問相同的舊 URL 時(shí)會再次請求舊 URL，不直接跳轉(zhuǎn)到新 URL。
Ⅱ、搜索引擎不會更新原始 URL 的搜索排名，認(rèn)為這種重定向是臨時(shí)的。
.
選擇：
301 應(yīng)該用于永久性重定向，如果你確定資源將永久地移到新的 URL，并且不再使用舊 URL。
302 應(yīng)該用于臨時(shí)性重定向，如果資源只是暫時(shí)移動(dòng)到新的 URL，將來可能會恢復(fù)到原始 URL。

應(yīng)用場景四：防盜鏈

》防止其他網(wǎng)站引用我們的圖片資源，避免資源消耗。

server {
    listen 80;
    server_name example.com;

	# 使用正則表達(dá)式匹配請求的 URL，限制只對圖片文件（jpg、jpeg、png、gif）生效。
    location ~* \.(jpg|jpeg|png|gif)$ {
        # 設(shè)置防盜鏈規(guī)則
        valid_referers none blocked example.com *.example.com;
        if ($invalid_referer) {
            # 防盜鏈規(guī)則不匹配的處理，例如返回 403 Forbidden
            return 403;
        }
        # 允許符合防盜鏈規(guī)則的請求訪問圖片資源
        # 這里可以配置圖片資源的存放路徑
        root /path/to/your/image/directory;
    }

    # 其他配置項(xiàng)可以根據(jù)需求添加
}

# ----------------------------------------------------
valid_referers：設(shè)置允許訪問資源的 Referer（來源）規(guī)則。
	none：禁止所有 Referer。
	blocked：允許空 Referer。
	example.com：允許指定的域名 example.com 的 Referer。
	*.example.com：允許所有子域名的 Referer。


if ($invalid_referer)：檢查請求的 Referer 是否不符合防盜鏈規(guī)則。
如果 $invalid_referer 為 true，表示請求的 Referer 不在允許的列表中。
在這種情況下，可以返回 403 Forbidden 狀態(tài)碼，拒絕訪問資源。

root /path/to/your/image/directory;：配置圖片資源的存放路徑，可以根據(jù)實(shí)際情況替換為你的圖片存放目錄。

應(yīng)用場景五：根據(jù)設(shè)備類型重定向/代理/訪問 不同域名/資源

# 一：根據(jù)if判斷設(shè)備類型，進(jìn)行 rewrite 重定向。不滿足if則正常執(zhí)行接下去的配置信息（pc端配置）
# ========================== =========================

# 定義 resolver，指定 DNS 解析服務(wù)器(使用 Google 的公共 DNS)
# 根據(jù)情況而定是否需要，有些本地?zé)o法解析dns，導(dǎo)致訪問失敗，則需要用到此命令。
resolver 8.8.8.8;

server {
	listen 8098;
	server_name example.com;
	

		
	# 判斷是否為手機(jī)端訪問
	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)) {
		# 如果是手機(jī)端訪問，則重定向到 PC 端頁面
		rewrite ^(.*)$ http://app.example.com$request_uri;
	}
	
	# 配置 PC 端頁面的根目錄和其他配置項(xiàng)
    root /path/to/pc/website;
    index index.html index.htm;

    # 其他 PC 端配置項(xiàng)
}


# 二：根據(jù)設(shè)備類型反向代理不同域名【反向代理會隱藏真實(shí)的 url 信息】
# ========================== =========================

# 定義設(shè)備類型映射表
map $http_user_agent $proxy_backend {
    default http://pc.example.com;  # 默認(rèn)設(shè)備類型為桌面端（pc端）
    ~*mobile http://app.example.com;  # 匹配包含 mobile 的 User-Agent 為手機(jī)端
    ~*tablet http://ipad.example.com;  # 匹配包含 tablet 的 User-Agent 為平板端
}

# 定義 resolver，指定 DNS 解析服務(wù)器(使用 Google 的公共 DNS)
# 根據(jù)情況而定是否需要，有些本地?zé)o法解析dns，導(dǎo)致訪問失敗，則需要用到此命令。
resolver 8.8.8.8;

server {
	listen 80;
	server_name example.com;
	
    location / {
    	# 使用 proxy_pass 將請求代理到根據(jù)設(shè)備類型選擇的后端服務(wù)器
    	proxy_pass $proxy_backend;
    }
}

# 三： 根據(jù)不同設(shè)備類型進(jìn)行靈活配置
# ========================== =========================

# 定義設(shè)備類型映射表
map $http_user_agent $device_type {
    default desktop;  # 默認(rèn)設(shè)備類型為桌面端（pc端）
    ~*mobile mobile;  # 匹配包含 mobile 的 User-Agent 為手機(jī)端
    ~*tablet tablet;  # 匹配包含 tablet 的 User-Agent 為平板端
}

# 配置服務(wù)器塊
server {
    listen 80;
    server_name example.com;

    # 根據(jù)設(shè)備類型進(jìn)行配置
    if ($device_type = mobile) {
        
    }

    if ($device_type = tablet) {
        
    }

    # 默認(rèn)情況下為pc端
    #進(jìn)行pc端配置
}

應(yīng)用場景六：！負(fù)載均衡服務(wù)器！

1、輪詢策略（Round Robin）

》輪詢是最常見的負(fù)載均衡策略。請求按照順序依次分配給后端服務(wù)器，每個(gè)請求都按照列表中服務(wù)器的順序進(jìn)行分發(fā)。當(dāng)請求達(dá)到服務(wù)器列表的末尾時(shí)，重新開始從第一個(gè)服務(wù)器分發(fā)。輪詢適用于后端服務(wù)器性能相近、無需特別考慮請求的處理時(shí)間等情況。
》也可以理解為是一個(gè)特殊的加權(quán)策略，不過服務(wù)器組中的各個(gè)服務(wù)器的權(quán)重都是1。

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

# 后面的均衡策略沒有 server ，則說明和這里是一樣的，不過多重復(fù)。
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、加權(quán)輪詢 （Weighted Round Robin）

》加權(quán)輪詢在輪詢的基礎(chǔ)上引入權(quán)重因素，即給每個(gè)服務(wù)器分配一個(gè)權(quán)重值，用于調(diào)節(jié)每臺服務(wù)器處理請求的比例。權(quán)重高的服務(wù)器將獲得更多的請求。這種策略適用于服務(wù)器性能不均衡的情況，通過調(diào)整權(quán)重可以實(shí)現(xiàn)更靈活的負(fù)載均衡。
》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）

》最少連接策略將請求分配給當(dāng)前連接數(shù)最少的服務(wù)器，以保持服務(wù)器的負(fù)載均衡。這種策略可以避免出現(xiàn)某些服務(wù)器連接數(shù)過載的情況，從而提高系統(tǒng)的整體性能。

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

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

》IP 哈希策略根據(jù)請求的源 IP 地址計(jì)算哈希值，然后將請求分發(fā)到特定的服務(wù)器。相同 IP 地址的請求始終被分發(fā)到相同的服務(wù)器，這有助于保持會話的一致性，適用于需要會話粘性的應(yīng)用場景。

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

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

》URL 哈希策略根據(jù)請求的 URL 計(jì)算哈希值，然后將請求分發(fā)到特定的服務(wù)器。相同 URL 的請求始終被分發(fā)到相同的服務(wù)器，這對于緩存和特定資源的分發(fā)具有一定的優(yōu)勢。

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

6、最短響應(yīng)時(shí)間（Least Time）

》最短響應(yīng)時(shí)間策略將請求分配給具有最短平均響應(yīng)時(shí)間的服務(wù)器。通過實(shí)時(shí)監(jiān)測服務(wù)器的響應(yīng)時(shí)間，負(fù)載均衡器可以動(dòng)態(tài)調(diào)整請求的分發(fā)，以確保向用戶提供更快的響應(yīng)和更好的體驗(yàn)。

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

7、公平策略（Fair）

》公平策略會根據(jù)服務(wù)器的響應(yīng)時(shí)間和負(fù)載情況動(dòng)態(tài)調(diào)整請求的分發(fā)，以確保每個(gè)服務(wù)器獲得相等的負(fù)載。這種策略可以避免某些服務(wù)器被過載或負(fù)載不均衡的情況。

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

負(fù)載均衡服務(wù)器的健康檢查

》當(dāng)后端服務(wù)器因?yàn)楣收匣虿豢捎脮r(shí)，負(fù)載均衡器可以自動(dòng)剔除這些服務(wù)器，以確保流量不會被發(fā)送到無法正常處理請求的服務(wù)器上。以下是幾種常見的策略以及對應(yīng)的配置樣例：

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

》通過定期向后端服務(wù)器發(fā)送健康檢查請求（如 HTTP 請求或 TCP 連接），負(fù)載均衡器根據(jù)響應(yīng)結(jié)果判斷服務(wù)器的健康狀態(tài)。不可用的服務(wù)器會自動(dòng)從負(fù)載均衡器的服務(wù)器列表中剔除，直到恢復(fù)正常后再重新加入。

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：這是一個(gè)負(fù)載均衡模塊的指令，用于配置健康檢查參數(shù)。
interval=3000：指定健康檢查的間隔時(shí)間，單位為毫秒（ms）。在此配置中，健康檢查每隔 3 秒進(jìn)行一次。
rise=2：指定服務(wù)器被標(biāo)記為健康的連續(xù)成功檢查次數(shù)。如果服務(wù)器連續(xù)成功檢查的次數(shù)達(dá)到設(shè)定的值，則被標(biāo)記為健康狀態(tài)。
fall=3：指定服務(wù)器被標(biāo)記為不健康的連續(xù)失敗檢查次數(shù)。如果服務(wù)器連續(xù)失敗檢查的次數(shù)達(dá)到設(shè)定的值，則被標(biāo)記為不健康狀態(tài)。
timeout=1000：指定健康檢查的超時(shí)時(shí)間，單位為毫秒（ms）。如果健康檢查在設(shè)定的超時(shí)時(shí)間內(nèi)沒有收到響應(yīng)，則認(rèn)為檢查失敗。

2、主動(dòng)健康監(jiān)控（Active Health Monitoring）策略

》負(fù)載均衡器定期向后端服務(wù)器發(fā)送主動(dòng)的健康檢查請求，而不是等待客戶端請求時(shí)檢測。如果檢測到后端服務(wù)器不可用，負(fù)載均衡器將立即停止將流量發(fā)送到該服務(wù)器。

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：定義一個(gè)新的 location 塊，用于處理健康檢查的請求。
access_log off;：關(guān)閉對健康檢查請求的訪問日志記錄，避免將健康檢查請求記錄到 Nginx 的訪問日志中。
proxy_pass http://my_backend;：將健康檢查請求代理轉(zhuǎn)發(fā)到定義的后端服務(wù)器組 my_backend。
proxy_pass_check http://my_backend/health_check;：配置用于健康檢查的額外請求。負(fù)載均衡器會向后端服務(wù)器發(fā)送這個(gè)額外的檢查請求，以確定服務(wù)器的健康狀態(tài)。

3、 被動(dòng)健康監(jiān)控（Passive Health Monitoring）策略

》負(fù)載均衡器根據(jù)實(shí)際的流量情況和響應(yīng)時(shí)間來判斷服務(wù)器的健康狀態(tài)。如果后端服務(wù)器的響應(yīng)時(shí)間超過預(yù)設(shè)閾值或者出現(xiàn)錯(cuò)誤率過高的情況，負(fù)載均衡器會將該服務(wù)器標(biāo)記為不可用。

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）策略

》當(dāng)負(fù)載均衡器檢測到后端服務(wù)器不可用時(shí)，會停止向該服務(wù)器發(fā)送新的連接和請求，但允許已經(jīng)建立的連接繼續(xù)處理直到完成。這樣可以確保不影響正在進(jìn)行中的流量，并逐漸將流量從不可用的服務(wù)器轉(zhuǎn)移到其他健康的服務(wù)器。

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;：
定義在出現(xiàn)指定錯(cuò)誤時(shí)切換到下一個(gè)后端服務(wù)器的條件。在此配置中，當(dāng)后端服務(wù)器返回錯(cuò)誤、超時(shí)或 HTTP 502 錯(cuò)誤時(shí)，將切換到下一個(gè)后端服務(wù)器處理請求。

proxy_connect_timeout 2s;：
設(shè)置連接后端服務(wù)器的超時(shí)時(shí)間為 2 秒。如果在指定的時(shí)間內(nèi)無法建立連接，則視為連接超時(shí)。

proxy_set_header Connection "";：
設(shè)置請求頭中的 Connection 字段為空字符串，防止 Nginx 將連接保持設(shè)置為默認(rèn)值，避免不必要的連接保持。

nginx 科普信息

1、常用命令

//開啟服務(wù)：
start nginx

//停止服務(wù)：nginx停止命令stop與quit參數(shù)的區(qū)別在于stop是快速停止nginx，可能并不保存相關(guān)信息，
//quit是完整有序的停止nginx  ，并保存相關(guān)信息。nginx啟動(dòng)與停止命令的效果都可以通過Windows任務(wù)管理器中的進(jìn)程選項(xiàng)卡觀察。
nginx -s quit
nginx -s stop


//重啟服務(wù)：
nginx -s reload


//檢查配置文件是否有語法錯(cuò)誤
nginx -t

2、location匹配優(yōu)先級順序

精確匹配 > (以 ^~開頭)最長前綴匹配 > 正則匹配 > 普通前綴匹配（越長越大）
location = 路徑 > location ^~ >location ~ / ~* > location /test > location /文章來源地址http://www.zghlxwxcb.cn/news/detail-853491.html

★★★創(chuàng)做不易，對你有幫助的話，麻煩給個(gè)三連★★★

到了這里，關(guān)于Nginx配置大全【六大使用場景、七大負(fù)載均衡策略、四大負(fù)載健康檢查】的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！