Nginx反向代理升級--upstream改造proxy_pass

以前寫了一些nginx的東西，此次繼續，主要使用upstream針對proxy_pass轉發作個處理
通常狀況下咱們在使用nginx反向代理的時候，都是以下配置，

...
location /api {
   proxy_pass https://b.test.com; # 設置代理服務器的協議和地址
   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，針對request和response互相寫入cookie
}       
...

這樣就實現了'/api'目錄接口的轉發。功能是實現了，可是有什麼問題麼？還真有！
若是咱們能夠反向代理，若是別人也知道了咱們的接口域名也不是能夠本身搭一個nginx服務器就能夠代理到咱們的接口服務器上去？？？是否是感受很危險，是的。。。對此當時作的時候就加了一個臨時方案，在接口服務中添加一個ip白名單，白名單中的ip都是nginx服務器的ip，而後就項目上線了。這樣也實現了需求，但ip若是被僞造了怎麼辦？因而咱們想到了另外一個方案，使用內網IP代替對外開放的域名，這樣在必定程度上就直接攔截了外部的直接訪問，具體實現以下，

upstream apiServer {
    server 10.10.10.10.:8888
}
...
location /api {
   proxy_pass http://apiServer; 
   proxy_cookie_domain apiServer a.test.com; 
}       
...

咱們使用upstream定義了一個apiServer的組，將轉發都指向這裏，這時至關於咱們把可能存在的用戶直接訪問接口服務器的可能給關閉了，也就是途中紅色的那部分危險操做～～

可能你會想upstream的使用純屬多餘，的確當apiServer只有一臺機器的時候，這個的確能夠不用，可是多臺機器的時候，雖然proxy_pass雖然能夠定義多條可是太麻煩了。。。使用upstream組統一管理便可，同時使用upstream還有一些優點好比給多個server設置負載均衡，upstream組中支持經過weight參數來設置當前server在負載均衡中所佔的比重，此外還能夠經過設置backup參數指定某些服務器做爲備份機等等。詳細的配置內容仍是建議你們參考Nginx upstream官方文檔。
此外，除了安全性方面，使用內網ip進行接口轉發也省去了轉發中的DNS從新解析的過程，有利於大幅提高接口轉發效率。同時若不想破壞已經作好的SLB的話，也能夠不使用upstream，直接轉發到SLB服務器的內網ip應該也是能夠的。

綜上，在proxy_pass轉發中咱們使用了兩種方案來對安全性作一些提高

• proxy_pass轉發到外網域名，同時在接口服務器上添加訪問來源白名單，把nginx服務器的ip寫進去
• proxy_pass轉發到內網域名，多服務器的話使用upstream統一管理並實現負載均衡，也能提高轉發效率

第二種方案是否是通用的呢？這樣可行的話，咱們的接口服務器是否是都不用設置外網可訪問的域名了呢？
第二種方案是能夠通用的，可是這不意味着咱們就能夠拋棄外部可訪問的域名，由於在一個落地業務中，好比第三方受權、微信支付等狀況下外部可訪問域名仍是必需要有的。所以只有那些不須要與第三方進行通訊，好比僅供公司內部使用的管理系統等，就能夠直接拋棄外網域名了。此時我的建議就是上面兩種方案結合一下：

• proxy_pass的轉發使用內網ip，來提高轉發效率，同時對外部訪問添加白名單，只暴露須要和第三方通訊的接口便可。

這樣在安全和效率高上就都能獲得必定的提高。

若有錯誤，歡迎你們指正
好好學習，每天向上～～

---

此處添加一個修正，最第一版原文中在proxy_pass後面咱們使用了https+upstream的方式進行轉發，可是在生產環境上發現使用https出現服務器502網關問題。

...
location /api {
   proxy_pass https://apiServer; 
   proxy_cookie_domain apiServer a.test.com; 
}       
...

upstream不用寫https，把https換成了http，問題解決。