綜述

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

對于英語不太好的人，理解起來真的很頭痛，只能通過測試來驗證對英文意思的猜測。

nginx對proxy_pass的官方說明見http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

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

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

url中帶path路徑

判斷條件

如果域名后面帶了“/”，則認為是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/;
}

個人理解如下：

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

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

url中不帶path路徑

判斷條件

與第一點相反，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;
}

個人理解如下：

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

nginx無法確認url的替換規(guī)則

這種場景nginx又細分成3類

location指定的是正則表達式

nginx官方要求配置proxy_pass時，不能帶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重寫了

比如

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.

這種場景，nginx會忽略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.

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

其他

實際上，“nginx無法確認url的替換規(guī)則”3個細分類可能存在交叉的地方，這個nginx沒有提到，大家只能動手自己去測試nginx的混合場景的規(guī)則了。

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

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

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

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使用正則表達式，proxy_pass中不能指定path，除非proxy_pass中包含變量。

補充說明

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

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

我們需要通過url中的租戶id進行分流，nginx配置如下

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

當(dāng)時第一眼看到這個配置時，感覺灰度分流不會生效，只會走正式邊。因為我們的url是/api/tenants開頭，location配置中少了“/api”，結(jié)果測試發(fā)現(xiàn)分流正常。

初步分析，nignx中的正則表達式與我們自己寫代表中的正則表達一樣，它是對整個url進行匹配。

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

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

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

proxy_pass中包含變量后，nginx這認為你指定了完整的url，因此交叉場景下，proxy_pass包含變量優(yōu)先級更高。

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

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

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

比如：

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

或者

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

可以在server層級指定resolver，比如

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

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

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

背景同上

我們要將服務(wù)由虛擬機遷到公司的docker部署平臺，這樣可以自動部署，監(jiān)控擴容啥的也更方便。

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

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

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

問題排查思路如下：

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

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

2.google如何修改Host頭，找到配置項"proxy_set_header Host $proxy_host",配置后驗證ok。

總結(jié)

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

最新評論