綜述

nginx官方網(wǎng)站講解proxy_pass時(shí)，只給了規(guī)則的說(shuō)明，并沒(méi)有給出具體的示例輔助理解。

對(duì)于英語(yǔ)不太好的人，理解起來(lái)真的很頭痛，只能通過(guò)測(cè)試來(lái)驗(yàn)證對(duì)英文意思的猜測(cè)。

nginx對(duì)proxy_pass的官方說(shuō)明見(jiàn)http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

其將proxy_pass的轉(zhuǎn)發(fā)規(guī)則分為3類：

• location為簡(jiǎn)單配置（非正則表達(dá)式），proxy_pass的url帶path路徑
• location為簡(jiǎn)單配置（非正則表達(dá)式），proxy_pass的url不帶path路徑
• nginx無(wú)法確認(rèn)url的替換規(guī)則

url中帶path路徑

判斷條件

如果域名后面帶了“/”，則認(rèn)為是url中帶了path路徑。比如：

• proxy_pass http://127.0.0.1/
• proxy_pass http://127.0.0.1/aaa
• proxy_pass http://127.0.0.1/aaa/

轉(zhuǎn)發(fā)規(guī)則

nginx官網(wǎng)原文如下：

If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive:

location /name/ {
proxy_pass http://127.0.0.1/remote/;
}

個(gè)人理解如下：

使用proxy_pass配置的url去替換location指定的部分。

如下圖就是使用http://127.0.0.1/remote/去替換path中/name/這一段

url中不帶path路徑

判斷條件

與第一點(diǎn)相反，proxy_pass指定url中只有域名，比如ttp://127.0.0.1

轉(zhuǎn)發(fā)規(guī)則

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI:

location /some/path/ {
proxy_pass http://127.0.0.1;
}

個(gè)人理解如下：

轉(zhuǎn)發(fā)url=proxy_pass配置的url+原始url中path部分

nginx無(wú)法確認(rèn)url的替換規(guī)則

這種場(chǎng)景nginx又細(xì)分成3類

location指定的是正則表達(dá)式

nginx官方要求配置proxy_pass時(shí)，不能帶path路徑。

When location is specified using a regular expression, and also inside named locations.
In these cases, proxy_pass should be specified without a URI.

path路徑在location中使用rewrite重寫(xiě)了

比如

location /name/ {
rewrite /name/([^/]+) /users?name=$1 break;
proxy_pass http://127.0.0.1/test;
}

In this case, the URI specified in the directive is ignored and the full changed request URI is passed to the server.

這種場(chǎng)景，nginx會(huì)忽略proxy_pass中配置的path路徑，然后使用proxy_pass中指定的域名加上rewrite中指定的path路徑即為轉(zhuǎn)發(fā)后的url。

proxy_pass配置的url中帶變量

比如

location /name/ {
proxy_pass http://127.0.0.1$request_uri;
}

In this case, if URI is specified in the directive, it is passed to the server as is, replacing the original request URI.

這種場(chǎng)景，如果proxy_pass配置的url經(jīng)過(guò)變量轉(zhuǎn)換后帶path路徑，則直接使用該url。

其他

實(shí)際上，“nginx無(wú)法確認(rèn)url的替換規(guī)則”3個(gè)細(xì)分類可能存在交叉的地方，這個(gè)nginx沒(méi)有提到，大家只能動(dòng)手自己去測(cè)試nginx的混合場(chǎng)景的規(guī)則了。

比如我們系統(tǒng)后端服務(wù)是沒(méi)有context-path的，后面為了容器化需要添加context-path，詳細(xì)背景見(jiàn)之前的博客。

為了對(duì)前端屏蔽變化，因此需要修改nginx的轉(zhuǎn)發(fā)規(guī)則。

如下圖所示，這樣就涉及到“location指定的是正則表達(dá)式”和“proxy_pass配置的url中帶變量”混合場(chǎng)景了。

If the location is given by regular expression, can not be a URI part in proxy_pass directive, unless there are variables in the directive

如果location使用正則表達(dá)式，proxy_pass中不能指定path，除非proxy_pass中包含變量。

補(bǔ)充說(shuō)明

當(dāng)時(shí)分析nginx轉(zhuǎn)發(fā)規(guī)則，是為了解決轉(zhuǎn)發(fā)時(shí)，url增加公共前綴，當(dāng)時(shí)不理解為啥在正則表達(dá)場(chǎng)景下不能通過(guò)在proxy_pass中配置公共前綴，達(dá)到增加公共前綴的目的(像簡(jiǎn)單模式那樣，使用proxy_pass替換掉url中正則表達(dá)式匹配上的那部分)。

后面在定位我們灰度分流配置時(shí)，頓悟nginx轉(zhuǎn)發(fā)規(guī)則這樣設(shè)計(jì)的目的。

我們需要通過(guò)url中的租戶id進(jìn)行分流，nginx配置如下

    location ~ /tenants/(租戶id)/ {
        proxy_pass https://$gray;
    }
    location ~ / {
        proxy_pass https://$production;
    }

當(dāng)時(shí)第一眼看到這個(gè)配置時(shí)，感覺(jué)灰度分流不會(huì)生效，只會(huì)走正式邊。因?yàn)槲覀兊膗rl是/api/tenants開(kāi)頭，location配置中少了“/api”，結(jié)果測(cè)試發(fā)現(xiàn)分流正常。

初步分析，nignx中的正則表達(dá)式與我們自己寫(xiě)代表中的正則表達(dá)一樣，它是對(duì)整個(gè)url進(jìn)行匹配。

并不像普通模式那樣從url起始位置開(kāi)始進(jìn)行匹配（當(dāng)然如果需要從起始位置開(kāi)始匹配，也可以通過(guò)指定"^"）。

因此正則表達(dá)式匹配上的部分，可能是url中間的一部分，這樣就不好實(shí)用proxy_pass替換掉location中指定的部分。

所以nignx要求，正則表達(dá)式場(chǎng)景下，配置proxy_pass時(shí)不能帶path路徑，除非proxy_pass指定的就是完整的url，這樣nginx要么直接使用proxy_pass中指定的url，要么使用原始url中的path+proxy_pass中指定的域名。

proxy_pass中包含變量后，nginx這認(rèn)為你指定了完整的url，因此交叉場(chǎng)景下，proxy_pass包含變量?jī)?yōu)先級(jí)更高。

淌坑指導(dǎo)-no resolver defined to resolve

當(dāng)proxy_pass指定的url中帶變量時(shí)，必須指定resolver。

具體解釋見(jiàn)https://stackoverflow.com/questions/17685674/nginx-proxy-pass-with-remote-addr(這個(gè)解釋也沒(méi)給出細(xì)節(jié)，nginx官方也沒(méi)給出具體解釋)

比如：

set $originaddr http://origin.example.com;
proxy_pass $originaddr;

或者

proxy_pass http://origin.example.com$request_uri;

可以在server層級(jí)指定resolver，比如

server {
    resolver xx.xx.xx.xx;
     … …
}

具體resolver配置那個(gè)IP，可以查看系統(tǒng)默認(rèn)配置的DNS服務(wù)器- cat /etc/resolv.conf

趟坑指導(dǎo)-“proxy_set_header Host $proxy_host”

背景同上

我們要將服務(wù)由虛擬機(jī)遷到公司的docker部署平臺(tái)，這樣可以自動(dòng)部署，監(jiān)控?cái)U(kuò)容啥的也更方便。

我們服務(wù)很多，nginx上面配置了很多轉(zhuǎn)發(fā)規(guī)則，為了對(duì)前端屏蔽后端的組網(wǎng)變化，我們保留了nginx，通過(guò)nginx轉(zhuǎn)發(fā)到ALB(docker通過(guò)ALB對(duì)外暴露服務(wù))。

服務(wù)上了docker后，url要增加前綴（見(jiàn)背景文章），因此nginx轉(zhuǎn)發(fā)規(guī)則要統(tǒng)一給轉(zhuǎn)發(fā)后的url增加公共前綴，配置方式見(jiàn)上述“其他”章節(jié)。

配置后發(fā)現(xiàn)仍然報(bào)404(直接訪問(wèn)ALB是ok的)。

問(wèn)題排查思路如下：

1.確認(rèn)轉(zhuǎn)發(fā)后的url是不是如自己期望的那樣

首先想通過(guò)nginx日志打印轉(zhuǎn)發(fā)后的規(guī)則，沒(méi)有發(fā)現(xiàn)合適的參數(shù)；因此通過(guò)tcpdump工具dump報(bào)文，發(fā)現(xiàn)轉(zhuǎn)發(fā)后的url正確，但是請(qǐng)求頭中的Host并不是ALB對(duì)外暴露的域名，而是我們Nignx自己的域名，因此懷疑ALB的路由規(guī)則中會(huì)包含對(duì)域名的檢測(cè)。(ALB也是一臺(tái)Nginx，Nignx可以通過(guò)server_name將轉(zhuǎn)發(fā)規(guī)則綁定到特定的域名，或者說(shuō)給不同的域名指定不同的路由規(guī)則)。

2.google如何修改Host頭，找到配置項(xiàng)"proxy_set_header Host $proxy_host",配置后驗(yàn)證ok。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論