在nginx中proxy_pass根據path路徑轉發時的"/"問題怎么處理

這篇文章將為大家詳細講解有關在nginx中proxy_pass根據path路徑轉發時的"/"問題怎么處理，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

在nginx中配置proxy_pass時，如果是按照^~匹配路徑時,要注意proxy_pass后的url最后的/。當加上了/，相當于是絕對根路徑，則nginx不會把location中匹配的路徑部分代理走;如果沒有/，則會把匹配的路徑部分也給代理走。

比如下面設置：

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header Host js.test.com;
proxy_pass http://js.test.com/;
}

如上面的配置，如果請求的url是http://servername/wangshibo/test.html會被代理成http://js.test.com/test.html

而如果這么配置

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header Host js.test.com;
proxy_pass http://js.test.com;
}

則請求的url是http://servername/wangshibo/test.html會被代理到http://js.test.com/wangshibo/test.html

當然，可以用如下的rewrite來實現/的功能

location ^~ /wangshibo/
{
proxy_cache js_cache;
proxy_set_header Host js.test.com;
rewrite /wangshibo/(.+)$ /$1 break;
proxy_pass http://js.test.com;
}

列舉下面一例

1）第一種配置

[root@BJLX_16_202_V vhosts]# cat ssl-wangshibo.conf
upstream at {
  server 192.168.1.202:8080 max_fails=3 fail_timeout=30s;
}
  
server {
  listen 443;
  server_name www.wangshibo.com;
  ssl on;
  
  ### SSL log files ###
  access_log logs/wangshibo_access.log;
  error_log logs/wangshibo_error.log;
  
### SSL cert files ###
  ssl_certificate ssl/wang.cer;  
  ssl_certificate_key ssl/wang.key;
  
  location /attendance/ {
  proxy_pass http://at;                             //不需要加上"/"          
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
    }
  
}

訪問https://www.wangshibo.com/attendance/和http://192.168.1.202:8080/attendance結果是一致的。

2）第二種配置

[root@BJLX_16_202_V vhosts]# cat ssl-wangshibo.conf
upstream at {
  server 192.168.1.202:8080 max_fails=3 fail_timeout=30s;
}
  
server {
  listen 443;
  server_name www.wangshibo.com;
  ssl on;
  
  ### SSL log files ###
  access_log logs/wangshibo_access.log;
  error_log logs/wangshibo_error.log;
  
### SSL cert files ###
  ssl_certificate ssl/wang.cer;  
  ssl_certificate_key ssl/wang.key;
  
  location / {
  proxy_pass http://at/attendance/;                         //一定要加上"/"            
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
    }  
}

訪問https://www.wangshibo.com和http://192.168.1.202:8080/attendance結果是一致的。

如下配置，想要實現的需求：

192.168.1.27是后端的real server，8080端口是公司的ehr人事系統端口。

又由于該系統涉及到微信接口訪問，即http://ehr.wang.com/attendance和http://ehr.wang.com/app

由于是內部系統，安全考慮，所以要求：

1）登錄ehr人事系統的時候要求使用內網登錄，即http://192.168.1.27:8080,訪問前要先登錄公司VPN
2）登錄微信接口http://ehr.wang.com/attendance和http://ehr.wang.com/app使用外網登錄，即使用解析后域名登錄。
3）訪問http://ehr.wang.com，強制跳轉為https://ehr.wang.com/attendance

[root@BJLX_4_21_P vhosts]# cat ehr.conf
server {
  listen 80;
  server_name ehr.wang.com;
  
  access_log logs/ehr_access.log;
  error_log  logs/ehr_error.log;
 
  return   301 https://$server_name$request_uri;   
}
 
[root@BJLX_4_21_P vhosts]# cat ssl-ehr.conf
upstream ehr {
  server 192.168.1.27:8080 max_fails=3 fail_timeout=30s;
}
 
server {
  listen 443;
  server_name ehr.wang.com;
  ssl on;
 
  ### SSL log files ###
  access_log logs/ehr_access.log;
  error_log logs/ehr_error.log;
 
### SSL cert files ###
  ssl_certificate ssl/wang.cer;   
  ssl_certificate_key ssl/wang.key; 
  #ssl_session_timeout 5m;
 
  location / {
    return 301 https://ehr.wang.com/attendance;
  }
 
  location /attendance/ {
  proxy_pass http://ehr;
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #  proxy_set_header X-Forwarded-Proto https;
  #proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
  }
 
  location /app/ {
  proxy_pass http://ehr;
  proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #  proxy_set_header X-Forwarded-Proto https;
  #proxy_set_header X-Forwarded-Proto https;
  proxy_redirect off;
  }
 }

注意：

由于從瀏覽器訪問（http）到源站的real server之間要經過Nginx反向代理層（https）

需要將proxy_set_header X-Forwarded-Proto https;這一行注釋掉，否則上面的配置無效。

如果中間沒有代理層，直接是在real server本機進行nginx的反向代理（即本機nginx反代到本機的8080端口），則這個參數無效注釋（已經過驗證）

HTTP頭域（proxy_set_header）列表與解釋

HTTP 頭域是HTTP協議中請求(request)和響應(response)中的頭部信息,其實就是HTTP通信的操作參數，告訴web服務器和瀏覽器怎樣處理這個通信。

HTTP頭從一個請求信息或者響應信息的第二行開始（第一行是請求行或者響應行），以兩個CR-LF字符組結束（CR：回車符,\r，LF：換行符\n）

而每個HTTP頭是字符串形式的，用冒號分割的鍵值對，多個HTTP頭之間用CR-LF字符組隔開。

某些http頭可以有注釋，例如user-agent,server,via。但這些注釋會被服務器或者瀏覽器忽略IETF組織已經將一些核心的HTTP頭定義在RFC2616規范中，
這些HTTP頭是每個基于HTTP協議的軟件必須實現的，而其他一些更新和擴展的頭域也必須被基于HTTP的軟件實現。當然，各個軟件也可以定義自己的頭域。

另一方面，RFC2616規范中并沒有限制每個HTTP頭的長度，或者限制HTTP頭的數量，但出于性能和安全的考慮，多數服務器都會自己作規定，例如apache2.3
就規定每個HTTP頭不能超過8190個字節，每個請求不能超過100個HTTP頭。

以下來看看發送一個請求(request)時候，可能包含的各個HTTP頭和它的解釋。

標準的請求頭--

Accept: 瀏覽器（或者其他基于HTTP的客戶端程序）可以接收的內容類型（Content-types）,例如 Accept: text/plain

Accept-Charset：瀏覽器能識別的字符集，例如 Accept-Charset: utf-8

Accept-Encoding：瀏覽器可以處理的編碼方式，注意這里的編碼方式有別于字符集，這里的編碼方式通常指gzip,deflate等。例如 Accept-Encoding: gzip, deflate

Accept-Language：瀏覽器接收的語言，其實也就是用戶在什么語言地區，例如簡體中文的就是 Accept-Language: zh-CN

Authorization：在HTTP中，服務器可以對一些資源進行認證保護，如果你要訪問這些資源，就要提供用戶名和密碼，這個用戶名和密碼就是在Authorization頭中附帶的，格式是“username:password”字符串的base64編碼，例如：Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==中，basic指使用basic認證方式，　QWxhZGRpbjpvcGVuIHNlc2FtZQ==使用base64解碼就是“Aladdin:open sesame”

Cache-Control：這個指令在request和response中都有，用來指示緩存系統（服務器上的，或者瀏覽器上的）應該怎樣處理緩存，因為這個頭域比較重要，特別是希望使用緩　存改善性能的時候，內容也較多，所以我想在下一篇博文中主要介紹一下。

Connection：告訴服務器這個user agent（通常就是瀏覽器）想要使用怎樣的連接方式。值有keep-alive和close。http1.1默認是keep-alive。keep-alive就是瀏覽器和服務器　的通信連接會被持續保存，不會馬上關閉，而close就會在response后馬上關閉。但這里要注意一點，我們說HTTP是無狀態的，跟這個是否keep-alive沒有關系，不要認為keep-alive是對HTTP無狀態的特性的改進。

Cookie：瀏覽器向服務器發送請求時發送cookie，或者服務器向瀏覽器附加cookie，就是將cookie附近在這里的。例如：Cookie:user=admin

Content-Length：一個請求的請求體的內存長度，單位為字節(byte)。請求體是指在HTTP頭結束后，兩個CR-LF字符組之后的內容，常見的有POST提交的表單數據，這個Content-Length并不包含請求行和HTTP頭的數據長度。

Content-MD5：使用base64進行了編碼的請求體的MD5校驗和。例如：Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Content-Type：請求體中的內容的mime類型。通常只會用在POST和PUT方法的請求中。例如：Content-Type: application/x-www-form-urlencoded

Date：發送請求時的GMT時間。例如：Date: Tue, 15 Nov 1994 08:12:31 GMT

Expect：指示需要使用服務器某些特殊的功能。（這個我不是很清楚）

From：發送這個請求的用戶的email地址。例如：From: user@example.com

Host：被服務器的域名或IP地址，如果不是通用端口，還包含該端口號，例如：Host: www.some.com:182

If-Match:通常用在使用PUT方法對服務器資源進行更新的請求中，意思就是，詢問服務器，現在正在請求的資源的tag和這個If-Match的tag相不相同，如果相同，則證明服務器上的這個資源還是舊的，現在可以被更新，如果不相同，則證明該資源被更新過，現在就不用再更新了（否則有可能覆蓋掉其他人所做的更改）。

If-Modified-Since：詢問服務器現在正在請求的資源在某個時間以來有沒有被修改過，如果沒有，服務器則返回304狀態來告訴瀏覽器使用瀏覽器自己本地的緩存，如果有修改過，則返回200，并發送新的資源（當然如果資源不存在，則返回404。）

If-None-Match：和If-Modified-Since用意差不多，不過不是根據時間來確定，而是根據一個叫ETag的東西來確定。關于etag我想在下一篇博客介紹一下。

If-Range：告訴服務器如果這個資源沒有更改過(根據If-Range后面給出的Etag判斷)，就發送這個資源中在瀏覽器缺少了的某些部分給瀏覽器，如果該資源以及被修改過，則將整個資源重新發送一份給瀏覽器。

If-Unmodified-Since：詢問服務器現在正在請求的資源在某個時刻以來是否沒有被修改過。

Max-Forwards：限制請求信息在代理服務器或網關中向前傳遞的次數。

Pragma：好像只有一個值，就是:no-cache。Pragma:no-cache 與cache-control:no-cache相同，只不過cache-control:no-cache是http1.1專門指定的，而Pragma:no-cache可以在http1.0和1.1中使用

Proxy-Authorization：連接到某個代理時使用的身份認證信息，跟Authorization頭差不多。例如：Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

Range：在HTTP頭中，"Range"字眼都表示“資源的byte形式數據的順序排列，并且取其某一段數據”的意思。Range頭就是表示請求資源的從某個數值到某個數值間的數據，例如：Range: bytes=500-999 就是表示請求資源從500到999byte的數據。數據的分段下載和多線程下載就是利用這個實現的。

Referer：指當前請求的URL是在什么地址引用的。例如在www.a.com/index.html頁面中點擊一個指向www.b.com的超鏈接，那么，這個www.b.com的請求中的Referer就是www.a.com/index.html。通常我們見到的圖片防盜鏈就是用這個實現的。

Upgrade：請求服務器更新至另外一個協議，例如：Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

User-Agent：通常就是用戶的瀏覽器相關信息。例如：User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Via：用來記錄一個請求經過了哪些代理或網關才被送到目標服務器上。例如一個請求從瀏覽器出發(假設使用http/1.0)，發送給名為 SomeProxy的內部代理，然后被轉發至www.somenet.com的公共代理（使用http/1.1），最后被轉發至目標服務器www.someweb.com，那么在someweb.com中收到的via 頭應該是： via:1.0 someProxy 1.1 www.someweb.com(apache 1.1)

Warning：記錄一些警告信息。

關于“在nginx中proxy_pass根據path路徑轉發時的"/"問題怎么處理”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。