阿里云國際版使用Nginx作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器的處理方法
NGINX最初被設(shè)計(jì)為反向代理服務(wù)器。但是，隨著不斷發(fā)展，NGINX也可以作為實(shí)現(xiàn)轉(zhuǎn)發(fā)代理的選項(xiàng)之一。轉(zhuǎn)發(fā)代理本身并不復(fù)雜，它解決的關(guān)鍵問題是如何加密HTTPS流量。本文介紹了使用NGINX作為HTTPS流量轉(zhuǎn)發(fā)代理的兩種方法，以及它們的應(yīng)用場景和主要問題。
今天87cloud詳談下阿里云國際如何使用NGINX作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器
HTTP/HTTPS 轉(zhuǎn)發(fā)代理的分類
首先，讓我們仔細(xì)看看轉(zhuǎn)發(fā)代理的分類。
分類依據(jù)：代理對客戶是否透明
- 通用代理：在這里，代理地址和端口是在客戶端上的瀏覽器或系統(tǒng)環(huán)境變量中手動配置的。例如，當(dāng)您在客戶端上指定 Squid 服務(wù)器的 IP 地址和端口 3128 時(shí)。
- 透明代理：客戶端上不需要代理設(shè)置。“代理”角色對客戶端是透明的。例如，企業(yè)網(wǎng)絡(luò)上的 Web 網(wǎng)關(guān)設(shè)備是透明代理。
分類依據(jù)：代理是否加密HTTPS
- 隧道代理：這是一個透明傳輸流量的代理。代理服務(wù)器專門通過 TCP 透明地傳輸 HTTPS 流量。它不會解密或感知其代理流量的特定內(nèi)容?？蛻舳伺c目標(biāo)服務(wù)器執(zhí)行直接 TLS/SSL 交互。本文介紹了與此類型相關(guān)的NGINX代理模式。
- 中間人 （MITM） 代理：代理服務(wù)器解密 HTTPS 流量，使用自簽名證書完成與客戶端的 TLS/SSL 握手，并完成與目標(biāo)服務(wù)器的正常 TLS 交互。在客戶端-代理-服務(wù)器鏈接上設(shè)置了兩個 TLS/SSL 會話。
注意：在這種情況下，客戶端在TLS握手過程中實(shí)際獲取了代理服務(wù)器的自簽名證書，默認(rèn)情況下證書鏈的驗(yàn)證不成功。代理自簽名證書中的根 CA 證書必須在客戶端上受信任。因此，客戶端知道此過程中的代理。如果將自簽名根 CA 證書推送到客戶端（在企業(yè)的內(nèi)部環(huán)境中實(shí)現(xiàn)），則可實(shí)現(xiàn)透明代理。
轉(zhuǎn)發(fā)代理處理 HTTPS 流量時(shí)需要特殊處理
在充當(dāng)反向代理時(shí)，代理服務(wù)器通常會終止 HTTPS 加密流量并將其轉(zhuǎn)發(fā)到后端實(shí)例。HTTPS 流量的加密、解密和身份驗(yàn)證發(fā)生在客戶端和反向代理服務(wù)器之間。
另一方面，當(dāng)充當(dāng)轉(zhuǎn)發(fā)代理并處理客戶端發(fā)送的流量時(shí)，代理服務(wù)器不會在客戶端請求的URL中看到目標(biāo)域名，因?yàn)镠TTP流量已加密并封裝在TLS / SSL中，如下圖所示。因此，與 HTTP 流量不同，HTTPS 流量在代理實(shí)現(xiàn)期間需要一些特殊處理。
NGINX解決方案
根據(jù)前面幾節(jié)中的分類，當(dāng)NGINX用作HTTPS代理時(shí)，代理是透明的傳輸（隧道）代理，既不解密也不感知上層流量。具體來說，有兩種NGINX解決方案可用：第7層（L7）和第4層（L4）。以下各節(jié)詳細(xì)介紹了這些解決方案。
HTTP 連接隧道 （L7 解決方案）
歷史背景
早在1998年TLS還沒有正式上市的時(shí)候，推廣SSL協(xié)議的網(wǎng)景就提出使用Web代理進(jìn)行SSL流量的隧道。核心思想是使用HTTP CONNECT請求在客戶端和代理之間建立HTTP CONNECT隧道。CONNECT 請求必須指定客戶端需要訪問的目標(biāo)主機(jī)和端口?；ヂ?lián)網(wǎng)草案中的原始圖表如下：
有關(guān)整個過程的詳細(xì)信息，請參閱 HTTP：權(quán)威指南中的圖表。以下步驟簡要概述了該過程。
1） 客戶端向代理服務(wù)器發(fā)送 HTTP CONNECT 請求。
2） 代理服務(wù)器使用 HTTP CONNECT 請求中的主機(jī)和端口信息與目標(biāo)服務(wù)器建立 TCP 連接。
3） 代理服務(wù)器向客戶端返回 HTTP 200 響應(yīng)。
4） 客戶端與代理服務(wù)器建立 HTTP CONNECT 隧道。在 HTTPS 流量到達(dá)代理服務(wù)器后，代理服務(wù)器通過 TCP 連接透明地將 HTTPS 流量傳輸?shù)竭h(yuǎn)程目標(biāo)服務(wù)器。代理服務(wù)器僅透明地傳輸 HTTPS 流量，不解密 HTTPS 流量。
ngx_http_proxy_connect_module
作為反向代理服務(wù)器，NGINX并不正式支持HTTP CONNECT方法。但是，由于NGINX的模塊化和可擴(kuò)展功能，阿里巴巴@chobits提供了連接模塊（中文內(nèi)容）來支持HTTP CONNECT方法，以擴(kuò)展NGINX作為轉(zhuǎn)發(fā)代理。ngx_http_proxy_connect_module
環(huán)境建設(shè)
以 CentOS 7 環(huán)境為例，讓我們詳細(xì)看看這過程。
1） 環(huán)境安裝
對于新環(huán)境安裝，請參閱安裝連接模塊的常見安裝步驟（中文內(nèi)容）。ngx_http_proxy_connect_module
安裝相應(yīng)版本的修補(bǔ)程序，并在“configure”命令下添加參數(shù)，如以下示例所示。--add-module=/path/to/ngx_http_proxy_connect_module
./configure \ --user=www \ --group=www \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-threads \ --add-module=/root/src/ngx_http_proxy_connect_module
此外，為現(xiàn)有環(huán)境添加，如下所示。ngx_http_proxy_connect_module
# 停止NGINX服務(wù) # systemctl stop nginx # 備份原執(zhí)行文件 # cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak # 在源代碼路徑重新編譯 # cd /usr/local/src/nginx-1.16.0 ./configure \ --user=www \ --group=www \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-threads \ --add-module=/root/src/ngx_http_proxy_connect_module # make # 不要make install # 將新生成的可執(zhí)行文件拷貝覆蓋原來的nginx執(zhí)行文件 # cp objs/nginx /usr/local/nginx/sbin/nginx # /usr/bin/nginx -V nginx version: nginx/1.16.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-threads --add-module=/root/src/ngx_http_proxy_connect_module
2） 配置 nginx.conf 文件
執(zhí)行以下命令以配置文件。nginx.conf
server {
listen 443;
# dns resolver used by forward proxying
resolver 114.114.114.114;
# forward proxy for CONNECT request
proxy_connect;
proxy_connect_allow 443;
proxy_connect_connect_timeout 10s;
proxy_connect_read_timeout 10s;
proxy_connect_send_timeout 10s;
# forward proxy for non-CONNECT request
location / {
proxy_pass http://$host;
proxy_set_header Host $host;
}
}應(yīng)用場景
在 L7 解決方案中，HTTP CONNECT 請求必須建立隧道，因此，代理服務(wù)器是客戶端必須感知的公共代理。在客戶端上手動配置 HTTP（S） 代理服務(wù)器的 IP 地址和端口。使用 cURL 的“-x”參數(shù)訪問客戶端，如下所示。
# curl https://www.baidu.com -svo /dev/null -x 39.105.196.164:443
* About to connect() to proxy 39.105.196.164 port 443 (#0)
* Trying 39.105.196.164...
* Connected to 39.105.196.164 (39.105.196.164) port 443 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:443
> CONNECT www.baidu.com:443 HTTP/1.1
> Host: www.baidu.com:443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection Established
< Proxy-agent: nginx
<
* Proxy replied OK to CONNECT request
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=baidu.com,O="Beijing Baidu Netcom Science Technology Co., Ltd",OU=service operation department,L=beijing,ST=beijing,C=CN
...
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.baidu.com
> Accept: */*
>
< HTTP/1.1 200 OK
...
{ [data not shown]由“-v”參數(shù)打印的上述詳細(xì)信息指示客戶端首先與代理服務(wù)器 39.105.196.164 建立 HTTP CONNECT 隧道。一旦代理回復(fù)為“HTTP/1.1 200 連接已建立”，客戶端就會啟動 TLS/SSL 握手并將流量發(fā)送到服務(wù)器。
NGINX流（L4解決方案）
由于上層流量是透明傳輸?shù)模虼诉@里出現(xiàn)的關(guān)鍵問題是NGINX是否應(yīng)該充當(dāng)“L4代理”來實(shí)現(xiàn)TCP / UDP以上協(xié)議的完全透明傳輸。答案是肯定的。NGINX 1.9.0或更高版本支持ngx_stream_core_module。默認(rèn)情況下不生成此模塊。在命令下添加選項(xiàng)以啟用此模塊。-- with-streamconfigure
常見問題
使用NGINX流作為TCP層HTTPS流量的代理，會導(dǎo)致本文開頭提到的相同問題：代理服務(wù)器未獲得客戶端要訪問的目標(biāo)域名。發(fā)生這種情況是因?yàn)樵?TCP 層獲得的信息僅限于 IP 地址和端口，而不獲取域名。要獲取目標(biāo)域名，代理必須能夠從上層數(shù)據(jù)包中提取域名。因此，NGINX流不是嚴(yán)格意義上的L4代理，它必須尋求上層的幫助才能提取域名。
ngx_stream_ssl_preread_module
為了在不解密HTTPS流量的情況下獲取HTTPS流量的目標(biāo)域名，唯一的方法是在TLS/SSL握手期間使用第一個ClientHello數(shù)據(jù)包中包含的SNI字段。從版本1.11.5開始，NGINX支持ngx_stream_ssl_preread_module。此模塊有助于從 ClientHello 數(shù)據(jù)包獲取 SNI 和 ALPN。對于L4轉(zhuǎn)發(fā)代理，從ClientHello數(shù)據(jù)包中提取SNI的能力至關(guān)重要，否則NGINX流解決方案將無法實(shí)現(xiàn)。但是，這也帶來了一個限制，即在 TLS/SSL 握手期間，所有客戶端都必須在 ClientHello 數(shù)據(jù)包中包含 SNI 字段。否則，NGINX流代理將不知道客戶端需要訪問的目標(biāo)域名。
環(huán)境建設(shè)
1） 環(huán)境安裝
對于新安裝的環(huán)境，請參考常用安裝步驟（中文內(nèi)容），直接在“configure”命令下添加、、和選項(xiàng)。請考慮以下示例以更好地理解。--with-stream--with-stream_ssl_preread_module--with-stream_ssl_module
./configure \ --user=www \ --group=www \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-threads \ --with-stream \ --with-stream_ssl_preread_module \ --with-stream_ssl_module
為已安裝和已編譯的環(huán)境添加上述三個與流相關(guān)的模塊，如下所示。
# 停止NGINX服務(wù) # systemctl stop nginx # 備份原執(zhí)行文件 # cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak # 在源代碼路徑重新編譯 # cd /usr/local/src/nginx-1.16.0 # ./configure \ --user=www \ --group=www \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-threads \ --with-stream \ --with-stream_ssl_preread_module \ --with-stream_ssl_module # make # 不要make install # 將新生成的可執(zhí)行文件拷貝覆蓋原來的nginx執(zhí)行文件 # cp objs/nginx /usr/local/nginx/sbin/nginx # nginx -V nginx version: nginx/1.16.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --user=www --group=www --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-threads --with-stream --with-stream_ssl_preread_module --with-stream_ssl_module
2） 配置 nginx.conf 文件
與HTTP不同，在流塊中配置NGINX流。但是，命令參數(shù)與HTTP塊的命令參數(shù)類似。以下代碼段顯示了主配置。
stream {
resolver 114.114.114.114;
server {
listen 443;
ssl_preread on;
proxy_connect_timeout 5s;
proxy_pass $ssl_preread_server_name:$server_port;
}
}應(yīng)用場景
作為L4轉(zhuǎn)發(fā)代理，NGINX基本上透明地將流量傳輸?shù)缴蠈?，并且不需要HTTP CONNECT來建立隧道。因此，L4 解決方案適用于透明代理模式。例如，當(dāng)目標(biāo)域名通過 DNS 解析定向到代理服務(wù)器時(shí)，需要通過綁定到客戶端來模擬透明代理模式。/etc/hosts
以下代碼段顯示了客戶端上的命令：
cat /etc/hosts
...
# 把域名www.baidu.com綁定到正向代理服務(wù)器39.105.196.164
39.105.196.164 www.baidu.com
# 正常利用curl來訪問www.baidu.com即可。
# curl https://www.baidu.com -svo /dev/null
* About to connect() to www.baidu.com port 443 (#0)
* Trying 39.105.196.164...
* Connected to www.baidu.com (39.105.196.164) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=baidu.com,O="Beijing Baidu Netcom Science Technology Co., Ltd",OU=service operation department,L=beijing,ST=beijing,C=CN
* start date: 5月 09 01:22:02 2019 GMT
* expire date: 6月 25 05:31:02 2020 GMT
* common name: baidu.com
* issuer: CN=GlobalSign Organization Validation CA - SHA256 - G2,O=GlobalSign nv-sa,C=BE
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.baidu.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Connection: Keep-Alive
< Content-Length: 2443
< Content-Type: text/html
< Date: Fri, 21 Jun 2019 05:46:07 GMT
< Etag: "5886041d-98b"
< Last-Modified: Mon, 23 Jan 2017 13:24:45 GMT
< Pragma: no-cache
< Server: bfe/1.0.8.18
< Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
<
{ [data not shown]
* Connection #0 to host www.baidu.com left intact常見問題
現(xiàn)在，讓我們快速看一下有關(guān)L4解決方案的關(guān)鍵問題。
1） 由于客戶端上的手動代理設(shè)置，訪問嘗試失敗。
L4 轉(zhuǎn)發(fā)代理透明地傳輸上層 HTTPS 流量，不需要 HTTP CONNECT 即可建立隧道。因此，沒有必要在客戶端上設(shè)置 HTTP（S） 代理。關(guān)鍵問題是，在客戶端上手動設(shè)置 HTTP（S） 代理是否可確保訪問嘗試成功。使用 cURL 的“-x”參數(shù)設(shè)置轉(zhuǎn)發(fā)代理服務(wù)器并測試對此服務(wù)器的訪問。以下代碼段顯示了結(jié)果。
# curl https://www.baidu.com -svo /dev/null -x 39.105.196.164:443 * About to connect() to proxy 39.105.196.164 port 443 (#0) * Trying 39.105.196.164... * Connected to 39.105.196.164 (39.105.196.164) port 443 (#0) * Establish HTTP proxy tunnel to www.baidu.com:443 > CONNECT www.baidu.com:443 HTTP/1.1 > Host: www.baidu.com:443 > User-Agent: curl/7.29.0 > Proxy-Connection: Keep-Alive > * Proxy CONNECT aborted * Connection #0 to host 39.105.196.164 left intact
結(jié)果指示客戶端嘗試在 NGINX 之前建立 HTTP CONNECT 隧道。但是，由于NGINX透明地傳輸流量，因此CONNECT請求直接轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器。目標(biāo)服務(wù)器不接受 CONNECT 方法。因此，“代理連接中止”反映在上面的代碼段中，導(dǎo)致訪問失敗。
2） 訪問嘗試失敗，因?yàn)榭蛻舳嗽?ClientHello 數(shù)據(jù)包中不包含 SNI。
如前所述，當(dāng)NGINX流用作轉(zhuǎn)發(fā)代理時(shí)，使用從ClientHello中提取SNI字段至關(guān)重要。如果客戶端在 ClientHello 數(shù)據(jù)包中未包含 SNI，則代理服務(wù)器將不知道目標(biāo)域名，從而導(dǎo)致訪問失敗。ngx_stream_ssl_preread_module
在透明代理模式（由手動綁定主機(jī)模擬）下，使用 OpenSSL 在客戶端上進(jìn)行模擬。
# openssl s_client -connect www.baidu.com:443 -msg
CONNECTED(00000003)
>>> TLS 1.2 [length 0005]
16 03 01 01 1c
>>> TLS 1.2 Handshake [length 011c], ClientHello
01 00 01 18 03 03 6b 2e 75 86 52 6c d5 a5 80 d7
a4 61 65 6d 72 53 33 fb 33 f0 43 a3 aa c2 4a e3
47 84 9f 69 8b d6 00 00 ac c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
96 00 41 c0 12 c0 08 00 16 00 13 00 10 00 0d c0
0d c0 03 00 0a 00 07 c0 11 c0 07 c0 0c c0 02 00
05 00 04 00 ff 01 00 00 43 00 0b 00 04 03 00 01
02 00 0a 00 0a 00 08 00 17 00 19 00 18 00 16 00
23 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05
01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03
03 02 01 02 02 02 03 00 0f 00 01 01
140285606590352:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 289 bytes
?默認(rèn)情況下，OpenSSL 不包括 SNI。如代碼段所示，在發(fā)送 ClientHello 后，前面的請求將在 TLS/SSL 握手階段終止。發(fā)生這種情況是因?yàn)榇矸?wù)器不知道應(yīng)將 ClientHello 轉(zhuǎn)發(fā)到的目標(biāo)域名。s_client
使用帶有“服務(wù)器名稱”參數(shù)的 OpenSSL 來指定 SNI，將產(chǎn)生成功的訪問。
# openssl s_client -connect www.baidu.com:443 -servername www.baidu.com
結(jié)論
本文介紹了使用NGINX作為HTTPS流量轉(zhuǎn)發(fā)代理的兩種方法。它總結(jié)了NGINX使用HTTP CONNECT隧道和NGINX流充當(dāng)HTTPS轉(zhuǎn)發(fā)代理的解決方案的原則，環(huán)境構(gòu)建要求，應(yīng)用場景和關(guān)鍵問題。本文在各種情況下使用NGINX作為轉(zhuǎn)發(fā)代理時(shí)用作參考，具體情況參考www.87cloud.com
到此這篇關(guān)于阿里云國際版使用Nginx作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器的處理方法的文章就介紹到這了,更多相關(guān)Nginx作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
本文主要介紹了Nginx之QPS限制模塊的具體使用,主要介紹Nginx QPS限制模塊的原理、安裝和使用方法,具有一定的參考價(jià)值,感興趣的可以了解一下2023-09-09
最近在工作中遇到了一個問題，發(fā)現(xiàn)nginx cache居然不緩存，后來通過查找網(wǎng)上的資料找到了原因和解決方案，下面整理好分享給大家，同樣遇到這個問題的朋友們可以參考借鑒，下面和小編一起來學(xué)習(xí)學(xué)習(xí)吧。2016-10-10
nginx如何實(shí)現(xiàn)同個ip、端口訪問不同的項(xiàng)目(以路徑區(qū)分項(xiàng)目)
這篇文章主要介紹了nginx如何實(shí)現(xiàn)同個ip、端口訪問不同的項(xiàng)目(以路徑區(qū)分項(xiàng)目),具有很好的參考價(jià)值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-12-12
Nginx重定向后請求參數(shù)丟失的原因分析及解決方案
在日常開發(fā)和運(yùn)維中,我們經(jīng)常會遇到需要使用 Nginx 進(jìn)行反向代理的場景,但在配置 proxy_pass 時(shí),有時(shí)候可能會遇到請求參數(shù)丟失的問題,在這篇文章中,我們將會詳細(xì)探討這個問題并給出幾種解決方案,需要的朋友可以參考下2023-11-11
這篇文章主要介紹了Nginx實(shí)現(xiàn)正向代理實(shí)例,正向代理的作用在于正向代理隱藏了用戶，用戶的請求被代理服務(wù)器接收代替，到了服務(wù)器，服務(wù)器并不知道用戶是誰,需要的朋友可以參考下2023-08-08
這篇文章主要介紹了Nginx反斜杠自動解碼問題解決方法,有些時(shí)候是不需要解碼的,可nginx缺會自動解碼,本文講解的就是如何解決這個問題,需要的朋友可以參考下2015-02-02
nginx添加nginx-sticky-module模塊步驟的實(shí)現(xiàn)
nginx-sticky-module模塊是nginx實(shí)現(xiàn)負(fù)載均衡的一種方案,和ip_hash負(fù)載均衡算法會有區(qū)別的,本文主要介紹了nginx添加nginx-sticky-module模塊步驟的實(shí)現(xiàn),感興趣的可以了解一下2023-08-08
這篇文章主要介紹了前端必備Nginx配置詳解，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-09-09
這篇文章主要介紹了nginx中的limit_req限速設(shè)置配置示例,本文直接給出配置文件例子,其中包含大量中文注釋,需要的朋友可以參考下2015-03-03
給大家詳細(xì)整理了nginx常見的問題以及對應(yīng)問題的處理辦法，有需要的朋友參考一下吧。2017-12-12