一.發現問題
配置nginx代理的時候，發現location配置的路徑和代理的上下文路徑的組合不同，服務端接收到的uri的路徑不同，導致了controller的RequestMapping匹配出現問題，所以就仔細研究了一下nginx路徑配置的細節問題；
二.實驗過程
關於nginx的location路徑和proxy_pass代理的上下文路徑細節問題，以下分為四種情況來說明：
所有請求nginx服務的url都為：http://192.168.0.105:8087/api/system/common/doLogin，
下面通過nginx配置的路徑不同，來觀察服務端接收到的uri是什么樣的；
1.情況一：
location后的路徑為“/api”，代理服務的上下文為空（http://192.168.0.105:8089），看下圖：
服務端接收到的uri為：
這個結果說明代理的時候，按照請求路徑中的/api匹配到了對應的代理，代理到服務端的時候，把請求的ip和port替換為代理服務的ip和port，而對應的uri則完全沒有變化，是整體的復制過去。
請求nginx：http://192.168.0.105:8087/api/system/common/doLogin
Nginx代理替換之后：http://192.168.0.105:8089/api/system/common/doLogin
代理過程：將圖中紅色部分替換為綠色部分，其他都不變，然后發送到服務端:
2.情況二：
location后的路徑為“/api”，代理服務的上下文為“/”（http://192.168.0.105:8089/），看下圖：
服務端接收的uri為：
這個結果說明按照請求路徑中的/api匹配到了對應的代理之后，把請求中的“/api”替換為代理服務上下文路徑“/”，“/api”之后的路徑不變，替換如下：
請求nginx：http://192.168.0.105:8087/api/system/common/doLogin
Nginx代理替換之后：http://192.168.0.105:8089/ /system/common/doLogin
代理過程：將紅色的部分替換為綠色的部分，其他都不變，然后發送服務端:
3.情況三：
location后的路徑為“/api/”，代理服務的上下文為空（http://192.168.0.105:8089），看下圖：
服務端接收的uri為：
這個結果和情況一是一樣的，按照請求路徑中的/api/匹配到了對應的代理，代理到服務端的時候，把請求的ip和port替換為代理服務的ip和port，而對應的uri則完全沒有變化，是整體的復制過去。
請求nginx：http://192.168.0.105:8087/api/system/common/doLogin
Nginx代理替換之后：http://192.168.0.105:8089/api/system/common/doLogin
代理過程：將紅色部分替換為綠色部分，其他部分不變:
4.情況四：
location后的路徑為“/api/”，代理服務的上下文為“/”（http://192.168.0.105:8089/），看下圖：
服務端接收的uri為：
這個結果說明和情況二是一樣的，按照請求路徑中的/api/匹配到了對應的代理之后，把請求中的“/api/”替換為代理服務上下文路徑“/”，“/api/”之后的路徑不變，替換如下：
請求nginx：http://192.168.0.105:8087/api/system/common/doLogin
Nginx代理替換之后：http://192.168.0.105:8089/system/common/doLogin
代理過程：將紅色部分替換為綠色部分，其他部分不變:
三.解決問題：
根據上述四種情況總結，歸結為兩種代理過程：
1.如果代理proxy_pass只有ip和port，沒有上下文，則代理過程只替換掉nginx請求的ip和port，其他部分都不變，然后發送。
2.如果代理proxy_pass除了ip和port外，還有上下文，則代理過程中，除了替換ip和port之外,還會將location的路徑替換為proxy_pass中的上下文， 然后將剩余的路徑拼接，發送。