欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

阿里云國際版使用Nginx作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器的處理方法

 更新時(shí)間：2022年05月10日 14:38:40   作者：87cloud  
本文介紹了使用NGINX作為HTTPS流量轉(zhuǎn)發(fā)代理的兩種方法。它總結(jié)了NGINX使用HTTP?CONNECT隧道和NGINX流充當(dāng)HTTPS轉(zhuǎn)發(fā)代理的解決方案的原則，環(huán)境構(gòu)建要求，應(yīng)用場(chǎng)景和關(guān)鍵問題

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)用場(chǎng)景和主要問題。

今天87cloud詳談下阿里云國際如何使用NGINX作為HTTPS轉(zhuǎn)發(fā)代理服務(wù)器

HTTP/HTTPS 轉(zhuǎn)發(fā)代理的分類

首先，讓我們仔細(xì)看看轉(zhuǎn)發(fā)代理的分類。

分類依據(jù)：代理對(duì)客戶是否透明

  • 通用代理：在這里，代理地址和端口是在客戶端上的瀏覽器或系統(tǒng)環(huán)境變量中手動(dòng)配置的。例如，當(dāng)您在客戶端上指定 Squid 服務(wù)器的 IP 地址和端口 3128 時(shí)。
  • 透明代理：客戶端上不需要代理設(shè)置。“代理”角色對(duì)客戶端是透明的。例如，企業(yè)網(wǎng)絡(luò)上的 Web 網(wǎng)關(guān)設(shè)備是透明代理。

分類依據(jù)：代理是否加密HTTPS

  • 隧道代理：這是一個(gè)透明傳輸流量的代理。代理服務(wù)器專門通過 TCP 透明地傳輸 HTTPS 流量。它不會(huì)解密或感知其代理流量的特定內(nèi)容?？蛻舳伺c目標(biāo)服務(wù)器執(zhí)行直接 TLS/SSL 交互。本文介紹了與此類型相關(guān)的NGINX代理模式。
  • 中間人 （MITM） 代理：代理服務(wù)器解密 HTTPS 流量，使用自簽名證書完成與客戶端的 TLS/SSL 握手，并完成與目標(biāo)服務(wù)器的正常 TLS 交互。在客戶端-代理-服務(wù)器鏈接上設(shè)置了兩個(gè) TLS/SSL 會(huì)話。

注意：在這種情況下，客戶端在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ù)器通常會(huì)終止 HTTPS 加密流量并將其轉(zhuǎn)發(fā)到后端實(shí)例。HTTPS 流量的加密、解密和身份驗(yàn)證發(fā)生在客戶端和反向代理服務(wù)器之間。

另一方面，當(dāng)充當(dāng)轉(zhuǎn)發(fā)代理并處理客戶端發(fā)送的流量時(shí)，代理服務(wù)器不會(huì)在客戶端請(qǐng)求的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請(qǐng)求在客戶端和代理之間建立HTTP CONNECT隧道。CONNECT 請(qǐng)求必須指定客戶端需要訪問的目標(biāo)主機(jī)和端口?；ヂ?lián)網(wǎng)草案中的原始圖表如下：

有關(guān)整個(gè)過程的詳細(xì)信息，請(qǐng)參閱 HTTP：權(quán)威指南中的圖表。以下步驟簡(jiǎn)要概述了該過程。

1） 客戶端向代理服務(wù)器發(fā)送 HTTP CONNECT 請(qǐng)求。
2） 代理服務(wù)器使用 HTTP CONNECT 請(qǐng)求中的主機(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)境為例，讓我們?cè)敿?xì)看看這過程。

1） 環(huán)境安裝

對(duì)于新環(huán)境安裝，請(qǐng)參閱安裝連接模塊的常見安裝步驟（中文內(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)用場(chǎng)景

在 L7 解決方案中，HTTP CONNECT 請(qǐng)求必須建立隧道，因此，代理服務(wù)器是客戶端必須感知的公共代理。在客戶端上手動(dòng)配置 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 連接已建立”，客戶端就會(huì)啟動(dòng) 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流量的代理，會(huì)導(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握手期間使用第一個(gè)ClientHello數(shù)據(jù)包中包含的SNI字段。從版本1.11.5開始，NGINX支持ngx_stream_ssl_preread_module。此模塊有助于從 ClientHello 數(shù)據(jù)包獲取 SNI 和 ALPN。對(duì)于L4轉(zhuǎn)發(fā)代理，從ClientHello數(shù)據(jù)包中提取SNI的能力至關(guān)重要，否則NGINX流解決方案將無法實(shí)現(xiàn)。但是，這也帶來了一個(gè)限制，即在 TLS/SSL 握手期間，所有客戶端都必須在 ClientHello 數(shù)據(jù)包中包含 SNI 字段。否則，NGINX流代理將不知道客戶端需要訪問的目標(biāo)域名。

環(huán)境建設(shè)

1） 環(huán)境安裝

對(duì)于新安裝的環(huán)境，請(qǐng)參考常用安裝步驟（中文內(nèi)容），直接在“configure”命令下添加、、和選項(xiàng)。請(qǐ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)境添加上述三個(gè)與流相關(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)用場(chǎng)景

作為L(zhǎng)4轉(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） 由于客戶端上的手動(dòng)代理設(shè)置，訪問嘗試失敗。

L4 轉(zhuǎn)發(fā)代理透明地傳輸上層 HTTPS 流量，不需要 HTTP CONNECT 即可建立隧道。因此，沒有必要在客戶端上設(shè)置 HTTP（S） 代理。關(guān)鍵問題是，在客戶端上手動(dòng)設(shè)置 HTTP（S） 代理是否可確保訪問嘗試成功。使用 cURL 的“-x”參數(shù)設(shè)置轉(zhuǎn)發(fā)代理服務(wù)器并測(cè)試對(duì)此服務(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請(qǐng)求直接轉(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

在透明代理模式（由手動(dòng)綁定主機(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 后，前面的請(qǐng)求將在 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)用場(chǎ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)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

相關(guān)文章

  • Nginx實(shí)現(xiàn)404錯(cuò)誤自動(dòng)跳轉(zhuǎn)到首頁的配置過程

    Nginx實(shí)現(xiàn)404錯(cuò)誤自動(dòng)跳轉(zhuǎn)到首頁的配置過程

    當(dāng)用戶在訪問網(wǎng)站的過程中遇到404錯(cuò)誤時(shí),通常情況下應(yīng)該顯示一個(gè)友好的錯(cuò)誤頁面,而不是僅僅顯示一個(gè)簡(jiǎn)單的錯(cuò)誤提示,在Nginx中,可以通過配置來實(shí)現(xiàn)404錯(cuò)誤自動(dòng)跳轉(zhuǎn)到首頁的功能,下面將詳細(xì)介紹如何進(jìn)行配置,需要的朋友可以參考下
    2023-12-12
  • nginx中斜杠(/)詳解

    nginx中斜杠(/)詳解

    本文主要介紹了nginx中斜杠(/)詳解，配置location、proxy_pass時(shí)，加“/”與不加“/”的區(qū)別，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下
    2022-01-01
  • Nginx同時(shí)支持Http和Https的配置詳解

    Nginx同時(shí)支持Http和Https的配置詳解

    這篇文章主要介紹了Nginx同時(shí)支持Http和Https的配置詳解，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2020-08-08
  • 三步配置輕量級(jí)服務(wù)器nginx小結(jié)

    三步配置輕量級(jí)服務(wù)器nginx小結(jié)

    Nginx是一個(gè)安裝非常的簡(jiǎn)單 , 配置文件非常簡(jiǎn)潔,本文就來介紹一下三步配置輕量級(jí)服務(wù)器nginx,具有一定的參考價(jià)值,感興趣的可以了解一下
    2023-08-08
  • 利用Nginx實(shí)現(xiàn)URL重定向的簡(jiǎn)單方法

    利用Nginx實(shí)現(xiàn)URL重定向的簡(jiǎn)單方法

    使用Nginx的重定向功能時(shí),除了可以重定向到新域名,還可以將請(qǐng)求重定向到特定的協(xié)議上,下面這篇文章主要給大家介紹了關(guān)于如何利用Nginx實(shí)現(xiàn)URL重定向的簡(jiǎn)單方法,需要的朋友可以參考下
    2022-04-04
  • 云服務(wù)器使用寶塔搭建Python環(huán)境,運(yùn)行django程序

    云服務(wù)器使用寶塔搭建Python環(huán)境,運(yùn)行django程序

    本文詳細(xì)講解了在云服務(wù)器使用寶塔搭建Python環(huán)境，運(yùn)行django程序的方法。對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2021-12-12
  • CentOS 4.0安裝配置Nginx的方法

    CentOS 4.0安裝配置Nginx的方法

    這篇文章主要介紹了CentOS 4.0安裝配置Nginx的方法,需要的朋友可以參考下
    2014-11-11
  • Windows下Nginx + PHP5 的安裝與配置方法

    Windows下Nginx + PHP5 的安裝與配置方法

    Nginx 是一個(gè)輕量級(jí)的高性能 Http WebServer，以事件驅(qū)動(dòng)方式編寫，因此相比 Apache 而言，Nginx 更加穩(wěn)定、性能更好，而且配置簡(jiǎn)單，資源占用較低。以下是我在 Windows 7 安裝中 Nginx 和 PHP5.3 的步驟。
    2010-07-07
  • nginx共享內(nèi)存機(jī)制詳解

    nginx共享內(nèi)存機(jī)制詳解

    這篇文章主要介紹了nginx共享內(nèi)存機(jī)制詳解,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-12-12
  • Nginx 代理轉(zhuǎn)發(fā)阿里云OSS上傳的實(shí)現(xiàn)代碼

    Nginx 代理轉(zhuǎn)發(fā)阿里云OSS上傳的實(shí)現(xiàn)代碼

    這篇文章主要介紹了Nginx 代理轉(zhuǎn)發(fā)阿里云OSS上傳的實(shí)現(xiàn)代碼，小編覺得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧
    2018-09-09

最新評(píng)論