摘要:本文同步在個(gè)人博客上,歡迎關(guān)注這篇文章整理了在前端開(kāi)發(fā)中,在開(kāi)發(fā)環(huán)境下使用重寫及代理功能的方法。表示該規(guī)則是使用正則定義的,區(qū)分大小寫。因此牢記在上下文中使用,而在上下文中使用。
本文同步在個(gè)人博客shymean.com上,歡迎關(guān)注
這篇文章整理了在前端開(kāi)發(fā)中,在開(kāi)發(fā)環(huán)境下使用nginx重寫uri及代理功能的方法。
參考
nginx中文文檔
前端開(kāi)發(fā)者必備的 Nginx 知識(shí)
Nginx與前端開(kāi)發(fā)
location匹配
參考
一文弄懂Nginx的location匹配
多個(gè)項(xiàng)目共用同一個(gè)域名時(shí),往往需要根據(jù)url將請(qǐng)求轉(zhuǎn)發(fā)到不同的項(xiàng)目上,此時(shí)需要配置location
location [ = | ~ | ~* | ^~ ] uri { ... }
在location指令和uri請(qǐng)求中間可以添加可選的修飾符,四種修飾符的含義分別如下
= 表示精確匹配。只有請(qǐng)求的url路徑與后面的字符串完全相等時(shí),才會(huì)命中。
~ 表示該規(guī)則是使用正則定義的,區(qū)分大小寫。
~* 表示該規(guī)則是使用正則定義的,不區(qū)分大小寫。
^~ 表示如果該符號(hào)后面的字符是最佳匹配,采用該規(guī)則,不再進(jìn)行后續(xù)的查找。
當(dāng)不添加任何修飾符時(shí),則使用請(qǐng)求資源路徑與配置的uri進(jìn)行前綴匹配:如果請(qǐng)求資源路徑以配置的uri開(kāi)頭,則表示可命中該規(guī)則。
需要注意的是,不能同時(shí)存在相同的uri匹配規(guī)則,即
location /img/ {} location ^~ /img/ {}
會(huì)提示錯(cuò)誤
nginx: [emerg] duplicate location "/img/" in /usr/local/etc/nginx/servers/test.conf:61
注意uri末尾帶斜杠與不帶斜杠會(huì)被視作兩條匹配規(guī)則,他們的處理也是不一樣的,在下面的例子中也有提到(上面引用的文章里面關(guān)于這點(diǎn)描述貌似錯(cuò)了)。
location的具體的匹配過(guò)程為
首先先檢查無(wú)修飾符的規(guī)則,并進(jìn)行前綴匹配,選擇最長(zhǎng)匹配的項(xiàng)并記錄下來(lái)。
然后檢查是否存在精確匹配的location(使用了=修飾符),如果存在,則結(jié)束查找,使用它的配置。
然后查找是否存在最優(yōu)匹配,如果存在,則選擇最優(yōu)匹配結(jié)果最長(zhǎng)的項(xiàng),并使用它的配置
然后按順序查找使用正則修飾符定義的location,如果匹配,則停止查找,使用它定義的配置。
最后,如果沒(méi)有匹配的正則location,則使用前面記錄的最長(zhǎng)匹配前綴字符location。
從上面的匹配過(guò)程可以看出,匹配順序是:
精準(zhǔn)匹配 > 最優(yōu)匹配 > 按順序的正則匹配 > 最長(zhǎng)的前綴匹配
接下來(lái)我們將編寫一些測(cè)試來(lái)練習(xí)location,其大概形式如下
# uri表示location的需要匹配的規(guī)則 location uri { # config表示某個(gè)config配置 [ config ] }
為了驗(yàn)證"存在多個(gè)location時(shí),到底是哪個(gè)location匹配規(guī)則生效"的問(wèn)題,我們可以將請(qǐng)求轉(zhuǎn)發(fā)到某個(gè)不存在的文件上,然后使用錯(cuò)誤日志查看某個(gè)請(qǐng)求對(duì)應(yīng)的location是啥
現(xiàn)在,讓我們開(kāi)始動(dòng)手測(cè)試吧
server { listen 80; server_name test.com; index index.html; error_log /usr/local/etc/nginx/logs/error.log error; location / { root /Users/Txm/A/; } location /img { root /Users/Txm/B/; } location /img/ { root /Users/Txm/C/; } }
接下來(lái)準(zhǔn)備了一些請(qǐng)求鏈接,通過(guò)訪問(wèn)并查看日志,就可以知道請(qǐng)求到底去了那個(gè)地方
請(qǐng)求url | 匹配規(guī)則 | 備注 |
---|---|---|
test.com/s/img/1.png | A | 只有/符合前綴匹配規(guī)則 |
test.com/img212/1.pn… | B | 只有/img符合前綴匹配,/img/不符合 |
test.com/img/1/1.png | C | /img/和/img末尾有無(wú)/是有區(qū)別的 |
test.com/img/1.png | C | /img/比/img的前綴匹配更長(zhǎng),更符合 |
接下來(lái)測(cè)試正則匹配,往上面的server模塊中添加如下location配置
location ~* /im { root /Users/Txm/D/; } location ~* .png { root /Users/Txm/E/; }
此時(shí)再訪問(wèn)/img212/1.png、/img/1/1.png和/img/1.png這三個(gè)鏈接,都會(huì)命中規(guī)則D,如上面的匹配規(guī)則:
正則匹配的優(yōu)先級(jí)大于前綴匹配,因此不會(huì)匹配規(guī)則ABC
正則匹配是按照定義的順序進(jìn)行匹配的,如果命中,則停止查找,因此雖然規(guī)則E也符合規(guī)則,但是沒(méi)有被命中
我們繼續(xù)來(lái)測(cè)試^~最優(yōu)匹配
location ~ /bund { root /Users/Txm/F/; } location ~ /bundle/1 { root /Users/Txm/F1/; } location ^~ /bundl { root /Users/Txm/G/; } location ^~ /bundle/ { root /Users/Txm/G1/; } location ~ .js$ { root /Users/Txm/H/; }
我們用http://test.com/bundle/1.js這個(gè)鏈接來(lái)進(jìn)行測(cè)試,理論上來(lái)說(shuō)這個(gè)鏈接符合上述所有規(guī)則,實(shí)際上該請(qǐng)求命中規(guī)則G1,我的理解是:
最優(yōu)匹配的優(yōu)先級(jí)高于正則匹配
存在多個(gè)最優(yōu)匹配的規(guī)則時(shí),命中匹配長(zhǎng)度最長(zhǎng)的規(guī)則
因此此處命中了G1,如果刪除G1,則根據(jù)優(yōu)先級(jí)應(yīng)該匹配G,繼續(xù)刪除G,此時(shí)狀態(tài)回到了上面的正則匹配,根據(jù)正則按順序匹配的規(guī)則,此時(shí)應(yīng)該匹配F。
最后,讓我們測(cè)試一下精準(zhǔn)匹配,精準(zhǔn)匹配表示請(qǐng)求的路徑與配置的uri要完全一致才可以
location = /img { root /Users/Txm/I/; }
請(qǐng)求url | 匹配規(guī)則 | 備注 |
---|---|---|
test.com/img | I | 精準(zhǔn)匹配優(yōu)先級(jí)最高 |
test.com/img/ | D | 不滿足精準(zhǔn)匹配和最優(yōu)匹配,在順序上滿足正則匹配D |
root 和alias
參考
nginx的location、root、alias指令用法和區(qū)別
上面整理了location的語(yǔ)法和匹配規(guī)則,但是location并不會(huì)改變請(qǐng)求的uri,實(shí)際上請(qǐng)求到的文件路徑是由其他指令進(jìn)行處理的。
root與alias都可以用來(lái)指定文件的路徑,他們的主要區(qū)別在于nginx如何解釋location后面的uri,這會(huì)使兩者分別以不同的方式將請(qǐng)求映射到服務(wù)器文件上
root的處理方式:root路徑+location路徑
alias的處理方式:使用alias路徑替換location路徑
以http://test.com/test/index.html請(qǐng)求為例,
server_name test.com; location /test/ { # 當(dāng)配置為root時(shí),實(shí)際請(qǐng)求的Users/Txm/nginx_test/test/index.html # root可以放在 http、server、location、if等多個(gè)配置段下面 # root /Users/Txm/nginx_test/; # 當(dāng)配置為alias時(shí),實(shí)際請(qǐng)求的是/Users/Txm/nginx_test/index.html # alias只能放在location中 # 注意alias末尾必須跟/ alias /Users/Txm/nginx_test/; }
換句話說(shuō),alias是一個(gè)目錄別名的定義,root則是最上層目錄的定義。
結(jié)合location,使用root或alias就可以把請(qǐng)求的url映射到磁盤上對(duì)應(yīng)的真實(shí)目錄。但是在某些時(shí)候,僅僅有目錄卻沒(méi)有真實(shí)文件也是不夠的(最常見(jiàn)的場(chǎng)景大概是開(kāi)發(fā)環(huán)境沒(méi)有生成環(huán)境文件名的緩存hash值和.min.等后綴),此時(shí)可以通過(guò)rewrite重寫請(qǐng)求uri路徑。
rewrite
參考
rewrite文檔
一篇文章說(shuō)透Nginx的rewrite模塊
rewrite模塊允許使用正則修改請(qǐng)求的URI,發(fā)起內(nèi)部跳轉(zhuǎn)再匹配location,或者直接做30x重定向返回客戶端。
rewrite regex replacement [flag]
其中的regex是PCRE風(fēng)格的正則,rewrite的運(yùn)行規(guī)則如下
如果regex匹配當(dāng)前請(qǐng)求的uri,則replacement 會(huì)被當(dāng)作是新的uri參與后續(xù)處理。
如果在server級(jí)別設(shè)置該選項(xiàng),那么他們將在location之前生效。
如果新URI字符中有關(guān)于協(xié)議的任何東西,比如http://或者h(yuǎn)ttps://等,則終止處理并直接響應(yīng)302
如果同一個(gè)上下文中(server、location、if)有多個(gè)能夠匹配uri的rewrite正則,則會(huì)根據(jù)rewrite指令出現(xiàn)的先后順序連續(xù)進(jìn)行重寫替換,并將替換后的replacement當(dāng)作新的uri參與后續(xù)處理
如果想要終止匹配,可以使用第三個(gè)參數(shù)flag,其取值如下
last表示停止處理任何rewrite相關(guān)的指令,并用替換后的uri開(kāi)始下一輪的location匹配
break表示停止處理任何rewrite相關(guān)的指令,且直接使用該uri來(lái)處理請(qǐng)求,不再進(jìn)行l(wèi)ocation匹配
redirect如果不包含協(xié)議,且是一個(gè)新的uri,則用新的uri匹配的location去處理請(qǐng)求,不會(huì)進(jìn)行30x跳轉(zhuǎn);但是他也可以直接返回30x,讓瀏覽器自己進(jìn)行重定向請(qǐng)求
permanent與redirect相同,區(qū)別在于它是直接返回301永久重定向
需要注意的是last和break的區(qū)別,如果在location中使用location,則會(huì)再次以新的URI重新發(fā)起重定向,并再次進(jìn)行l(wèi)ocation匹配,如果新的uri和舊的uri都再次匹配到一個(gè)相同的location,就會(huì)發(fā)生死循環(huán),當(dāng)這種循環(huán)超過(guò)10次時(shí),nginx就會(huì)返回500。因此牢記:在server上下文中使用last,而在location上下文中使用break。
接下來(lái)讓我們通過(guò)一些例子來(lái)驗(yàn)證rewrite的規(guī)則。
server { listen 80; server_name test2.com; index index.html; root /Users/Txm/nginx_test/; access_log /usr/local/etc/nginx/logs/test2.access.log; error_log /usr/local/etc/nginx/logs/error2.log error; rewrite ^/baidu http://www.baidu.com; rewrite ^/bai http://image.baidu.com; return 403; }
請(qǐng)求url | 最終rewrite的uri | 備注 |
---|---|---|
test2.com/bai | image.baidu.com | |
test2.com/baidu | www.baidu.com | 匹配到baidu,則直接返回 |
然后增加location |
location /bundle/ { rewrite ^/bundle/(.*?)$ /dist/$1 break; } location /dist/ { rewrite ^/dist/(.*?)$ /src/$1 break; }
請(qǐng)求url | 最終rewrite的uri | 備注 |
---|---|---|
test2.com/bundle/1.js | /Users/Txm/nginx_test/dist/1.js | break不再進(jìn)行l(wèi)ocation匹配 |
test2.com/dist/1.js | /Users/Txm/nginx_test/src/1.js |
然后將/bundle/里面的標(biāo)識(shí)符break修改為last,
location /bundle/ { rewrite ^/bundle/(.*?)$ /dist/$1 break; }
則可以看見(jiàn)最終的uri跟/dist/一樣,重寫成了/Users/Txm/nginx_test/src/1.js,因此牢記在location中使用break的警告。
通過(guò)rewrite,我們可以重寫路徑,將一些原本不存在的文件修改為實(shí)際存在磁盤上的文件,下面是一個(gè)去掉.min后綴和-hash后綴的重寫規(guī)則,可以將歷史項(xiàng)目中使用grunt打包的靜態(tài)資源映射到src對(duì)應(yīng)源文件去
rewrite ^(.*?)((.min)?-.*?)(..*?)$ $1$4 last;
nginx代理的一些用法
反向代理是為服務(wù)端服務(wù)的,反向代理可以幫助服務(wù)器接收來(lái)自客戶端的請(qǐng)求,幫助服務(wù)器做請(qǐng)求轉(zhuǎn)發(fā),負(fù)載均衡等。
反向代理對(duì)服務(wù)端是透明的,對(duì)我們是非透明的,即我們并不知道自己訪問(wèn)的是代理服務(wù)器,而服務(wù)器知道反向代理在為他服務(wù)。
正向代理是為我們服務(wù)的,即為客戶端服務(wù)的,客戶端可以根據(jù)正向代理訪問(wèn)到它本身無(wú)法訪問(wèn)到的服務(wù)器資源,一種應(yīng)用場(chǎng)景是:假設(shè)公司的局域網(wǎng)不允許訪問(wèn)外網(wǎng),則局域網(wǎng)中的客戶端要訪問(wèn)Internet,則需要通過(guò)代理服務(wù)器來(lái)訪問(wèn)。
正向代理對(duì)我們是透明的,對(duì)服務(wù)端是非透明的,即服務(wù)端并不知道自己收到的是來(lái)自代理的訪問(wèn)還是來(lái)自真實(shí)客戶端的訪問(wèn)。
下面是在前端開(kāi)發(fā)中,可以使用nginx代理實(shí)現(xiàn)的一些功能場(chǎng)景
在本地開(kāi)發(fā)環(huán)境模擬線上請(qǐng)求場(chǎng)景
代碼運(yùn)行環(huán)境可以分為本地開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境和線上生產(chǎn)環(huán)境。以現(xiàn)有開(kāi)發(fā)流程中某個(gè)web項(xiàng)目為例:
開(kāi)發(fā)時(shí)是本地啟動(dòng)的3015端口號(hào)
測(cè)試時(shí)在提測(cè)平臺(tái)根據(jù)工單拉取相關(guān)服務(wù),通過(guò)k8s部署在容器并運(yùn)行服務(wù),最終輸入一系列的host列表
工單可上線時(shí),通過(guò)發(fā)布平臺(tái)合并代碼到develop及master,然后按命令步驟部署到生產(chǎn)服務(wù)器上
假設(shè)訪問(wèn)服務(wù)的鏈接是http://m.xxx.com/h5/test為了達(dá)到三個(gè)環(huán)境相同的訪問(wèn)場(chǎng)景,一般來(lái)說(shuō)需要做下面處理:
需要訪問(wèn)生產(chǎn)環(huán)境時(shí),直接在瀏覽器輸入當(dāng)前鏈接即可,線上的域名一般會(huì)預(yù)先解析到對(duì)應(yīng)的服務(wù)器上ip上,默認(rèn)情況下輸入域名訪問(wèn)到的就是生產(chǎn)環(huán)境的服務(wù)。
可以把測(cè)試環(huán)境理解成生產(chǎn)環(huán)境的鏡像,應(yīng)用也是部署在一臺(tái)服務(wù)器上,需要訪問(wèn)測(cè)試環(huán)境時(shí),我們就需要將域名指向測(cè)試服務(wù)器的ip地址
在本地開(kāi)發(fā)時(shí),如果需要通過(guò)域名訪問(wèn)本地開(kāi)發(fā)環(huán)境,則可以通過(guò)修改host,然后將域名請(qǐng)求域名代理到本地node服務(wù)
127.0.0.1 xxx.com
然后修改nginx配置,通過(guò)nginx將xxx.com域名的請(qǐng)求代理到本地的服務(wù)端口號(hào)上面
server { listen 80; server_name m.xxx.com; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_pass http://127.0.0.1:3015; } }
這里推薦一個(gè)超級(jí)好用的host修改工具:SwitchHosts,可以很方便地在本地、測(cè)試環(huán)境、生成環(huán)境進(jìn)行域名切換。
將線上請(qǐng)求資源文件映射到本地
由于生產(chǎn)環(huán)境的靜態(tài)資源如樣式表、JavaScript文件一般是經(jīng)過(guò)壓縮和打包的,為了緩存控制甚至為文件名添加了hash后綴,如果在某些時(shí)候需要對(duì)線上代碼進(jìn)行調(diào)試,一般由兩種方式
第一種方式是通過(guò)charles等抓包工具,將請(qǐng)求的文件通過(guò)Map Local的方式映射到本地磁盤上,此時(shí)請(qǐng)求資源實(shí)際返回的是本地文件,然后可以通過(guò)修改本地文件來(lái)達(dá)到調(diào)試的目的。這種方式適合未經(jīng)過(guò)代碼合并打包處理的文件,在維護(hù)一些使用requirejs、seajs等模塊管理工具加載文件的老項(xiàng)目比較有用。
第二種將靜態(tài)資源域名配置到本地,然后通過(guò)nginx的location、alias和rewrite實(shí)現(xiàn)靜態(tài)資源文件代理
server { listen 80; server_name cnd.shymean.com; location /wargame/ { alias /Users/Txm/github/wargame/dist/; # 移除請(qǐng)求如jquery.min-a2dfg.js鏈接上的hash值a2dfg # http://cnd.shymean.com/wargame/jquery.min-a2dfg.js 實(shí)際返回文件為 /Users/Txm/github/wargame/dist/jquery.min.js rewrite ^(.+)/(.+)[-.]w+.(w+)$ $1/$2.$3 last; } location /blog/ { # 直接映射到本地目錄 alias /Users/Txm/blog/public/; } }
nginx配置跨域
正向代理一個(gè)經(jīng)典的場(chǎng)景是使用nginx繞開(kāi)瀏覽器的跨域限制,在前后端分離的開(kāi)發(fā)調(diào)試過(guò)程中,本地起的前端功能可能是localhost:port域名形式,一般情況下會(huì)使用本地mock數(shù)據(jù)進(jìn)行開(kāi)發(fā),如果需要直接訪問(wèn)遠(yuǎn)程接口進(jìn)行聯(lián)調(diào),則會(huì)遇見(jiàn)跨域問(wèn)題。
這種場(chǎng)景主要是在開(kāi)發(fā)時(shí)頁(yè)面域名(localhost)和接口域名(api.xxx.com)不一致導(dǎo)致的,通過(guò)nginx的location和proxy_pass,將指定請(qǐng)求代理到對(duì)應(yīng)服務(wù)商,從瀏覽器的角度來(lái)看,請(qǐng)求的都是同一個(gè)域名,也就不存在跨域限制了
server { listen 80; server_name shymean.com; location /api/ { # 局域網(wǎng)中后臺(tái)開(kāi)發(fā)的本地服務(wù),用于聯(lián)調(diào) proxy_pass http://192.168.132.253:7654; } }
另外一種場(chǎng)景是:出于性能優(yōu)化的目的,一些靜態(tài)資源等往往使用多帶帶的cdn域名,當(dāng)業(yè)務(wù)需要使用跨域資源(如在canvas上繪制網(wǎng)絡(luò)圖片最后需要調(diào)用canvas.toDataURL),此時(shí)也會(huì)存在跨域限制,通過(guò)nginx的add_header功能可以非常簡(jiǎn)單地實(shí)現(xiàn)CORS。
# 靜態(tài)資源 map $http_origin $imgCorsHost { default 0; "~http://shymean.com" http://shymean.com; "~https://shymean.com" https://shymean.com; } server { listen 80; listen 443; server_name cdn.shymean.com; root /Users/Txm/Desktop/blog/static; add_header Access-Control-Allow-Origin $imgCorsHost; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization"; if ($request_method = "OPTIONS") { return 204; } }
從上面的例子中可以看到,如果需要指定Access-Control-Allow-Origin為多個(gè)域名,可以使用nginx的map結(jié)構(gòu)。
通過(guò)nginx修改響應(yīng)的內(nèi)容
有時(shí)會(huì)有一些只在開(kāi)發(fā)環(huán)境下生效的邏輯,如引入mock代碼、向移動(dòng)端頁(yè)面增加eruda調(diào)試工具等。
在本地開(kāi)發(fā)時(shí),可以通過(guò)運(yùn)行時(shí)指定環(huán)境變量為development來(lái)判斷是否為生產(chǎn)環(huán)境,從而修改響應(yīng)內(nèi)容
<% if(!app.isProduction()) { %> <%- IncludeAssets("start:statics/h5/act/js/_mock.js") %> <% } %>
上面這種方式,在代碼中增加額外的環(huán)境判斷代碼,然后注入mock代碼,通過(guò)nginx通過(guò)攔截并修改響應(yīng)內(nèi)容,可以同樣實(shí)現(xiàn)這個(gè)功能。在最開(kāi)始實(shí)現(xiàn)這個(gè)需求的時(shí)候,花了大量時(shí)間來(lái)查閱相關(guān)的實(shí)現(xiàn)方法,發(fā)現(xiàn)最簡(jiǎn)單的方式應(yīng)該是通過(guò)openresty來(lái)實(shí)現(xiàn)。參考:
Lua + OpenResty修改response body
location ~* 1.js$ { body_filter_by_lua_file /usr/local/etc/openresty/lua/hello.lua; }
然后新增hello.lua腳本,編寫相關(guān)邏輯
-- body_filter_by_lua, body filter模塊,ngx.arg[1]代表輸入的chunk,ngx.arg[2]代表當(dāng)前chunk是否為last local chunk, eof = ngx.arg[1], ngx.arg[2] local buffered = ngx.ctx.buffered if not buffered then buffered = {} -- XXX we can use table.new here ngx.ctx.buffered = buffered end if chunk ~= "" then buffered[#buffered + 1] = chunk ngx.arg[1] = nil end if eof then local whole = table.concat(buffered) ngx.ctx.buffered = nil whole = string.gsub(whole, "console.log", "console.warn") ngx.arg[1] = whole end
需要注意的是,修改后的whole內(nèi)容長(zhǎng)度,不能超過(guò)之前原本的內(nèi)容長(zhǎng)度,否則后面的數(shù)據(jù)會(huì)被截取掉,估計(jì)跟content-length頭部有關(guān)。關(guān)于openresty和lua,之前接觸的也不是很多,后面會(huì)繼續(xù)深入學(xué)習(xí)一下。
小結(jié)
本文總結(jié)了幾個(gè)與nginx匹配uri相關(guān)的一些指令,包括
使用location匹配uri
使用root和alias指定請(qǐng)求資源目錄
使用rewrite重寫uri及后續(xù)匹配規(guī)則
結(jié)合uri和代理,我們就可以把請(qǐng)求導(dǎo)向自己需要的資源上去,從而滿足開(kāi)發(fā)環(huán)境的多種開(kāi)發(fā)需求。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/6676.html
摘要:?jiǎn)⒂没蚪梅磻?yīng)是否啟用壓縮響應(yīng)報(bào)文不是所有瀏覽器都支持壓縮機(jī)制設(shè)置一個(gè)響應(yīng)的壓縮級(jí)別??山邮艿闹翟诘街g。 博文參考 http://wiki.nginx.org/HttpUpstreamConsistentHash http://wiki.nginx.org/HttpUpstreamFairModule http://wiki.nginx.org/HttpUpstreamRequest...
摘要:?jiǎn)⒂没蚪梅磻?yīng)是否啟用壓縮響應(yīng)報(bào)文不是所有瀏覽器都支持壓縮機(jī)制設(shè)置一個(gè)響應(yīng)的壓縮級(jí)別。可接受的值在到之間。 博文參考 http://wiki.nginx.org/HttpUpstreamConsistentHash http://wiki.nginx.org/HttpUpstreamFairModule http://wiki.nginx.org/HttpUpstreamRequest...
摘要:安裝簡(jiǎn)單配置簡(jiǎn)潔啟動(dòng)快速便捷支持熱部署支持擁有高度模塊化的設(shè)計(jì)。備注在版本之前,不能在中使用權(quán)重。不能與同時(shí)使用。當(dāng)有服務(wù)器需要剔除,必須手動(dòng)掉。表示把請(qǐng)求轉(zhuǎn)發(fā)給連接數(shù)較少的后端服務(wù)器。表示當(dāng)前的暫時(shí)不參與負(fù)載均衡。表示預(yù)留的備份機(jī)器。 本文已同步到專業(yè)技術(shù)網(wǎng)站 www.sufaith.com, 該網(wǎng)站專注于前后端開(kāi)發(fā)技術(shù)與經(jīng)驗(yàn)分享, 包含Web開(kāi)發(fā)、Nodejs、Python、Lin...
摘要:語(yǔ)法如果相對(duì)域名或參數(shù)字符串起作用,可以使用全局變量匹配,也可以使用反向代理。不能返回限速,可以通過(guò)指令設(shè)置如果請(qǐng)求的文件名不存在,則反向代理到。 location正則寫法 一個(gè)示例: location = / { # 精確匹配 / ,主機(jī)名后面不能帶任何字符串 [ configuration A ] } location / { # 因?yàn)樗械牡刂范家?/ 開(kāi)...
閱讀 849·2019-08-30 15:55
閱讀 1421·2019-08-30 13:55
閱讀 2001·2019-08-29 17:13
閱讀 2853·2019-08-29 15:42
閱讀 1343·2019-08-26 14:04
閱讀 1030·2019-08-26 13:31
閱讀 3281·2019-08-26 11:34
閱讀 842·2019-08-23 18:25