這篇文章帶給大家的內容是關於nodejs中http代理程式庫http-proxy中常見的問題分析，有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。
http-proxy是一個nodejs的http代理程式庫，已經被webpack-dev-server整合進來，做代理使用。原因是在前後端分離大行其道的今天，我們如果需要在本地調後端api接口，不配置hostname的話，必然是一個跨域的請求。因為瀏覽器的跨域安全性限制，調取是不通的，所以本地代理就成了一個本地開發環境的必選項。
'/saasapi/*': {
target: 'http://ebk.17u.cn',
},意思呢大概就是把saasapi開頭的ajax請求重定向到http://ebk.17u.cn
本地開發沒有問題，線上如果也是用nodejs的伺服器，如果剛好也配置了代理，部署到線上出現了意想不到的問題~
一個網站主網域是17u. cn，後端如果部署了多個api服務，那麼這樣子他的api服務可能是這樣子
| 主網域 | 二級網域1 | 二級網域2 | 二級網域3 |
|---|---|---|---|
| #17u.cn | ebk.17u .cn | ebk2.17u.cn | ebk3.17u.cn |
前端同樣部署了3個nodejs服務，也同樣配置了3個代理程式。部署到線上卻發現，請求總是指向第一個二級域名，其他的二級域名存取不到。
百思不得姐！
後來仔細查看http的訊息，發現幾個服務的ajax請求發到伺服器上之後，hostname都是瀏覽器的域名，而nginx的反向代理配置都是根據hostname來做轉發的。因為我們的hostname對於nginx來說都是陌生的，所以就預設轉發到預設的第一個服務上去了。
查了http-proxy配置，哈哈，果然有這種修改的配置，只要稍微改一下就好了。
'/saasapi/*': {
target: 'http://ebk.17u.cn',
changeOrigin: true
},changeOrigin: true意思就是把hostname改為跟target一致就可以了。這樣後端nginx就可以正常轉送了。
後端api，不僅配置了二級域名，還配置了二級目錄，前端部署的服務也一樣需要二級目錄。
api位址就變成這個樣子：
ebk.17u.cn/saasapi
前端位址：
trans.17u.cn/saas
代理程式設定做對應調整
'/saas/saasapi/*': {
target: 'http://ebk.17u.cn',
changeOrigin: true,
rewrite: path => path.replace(/^\/saas\/saasapi\/cxy/, '/saasapi')
},這樣子看起來很正常吧，但是問題出在哪呢？後端把登入之後設定的cookie也設定了path：Path='/saasapi'。
這樣子問題就來了，trans.17u.cn/saas目前網域下讀取不到/saasapi下面的cookie，導致前端登入每次都通過，但就是不能正常調api，每次調取都提示沒有登入。
有問題還是先查文件。
還是發現了解決方案
cookiePathRewrite: { '/saasapi': '/saas/saasapi' }重寫cookie路徑就好了，同理如果後端介面指定了cookie的domain，一樣有方案解決
cookieDomainRewrite
還有一些其他rewrite，應該都比較好用的。
ps：在解決過程中，發現改了也總是不能成功，一度懷疑是庫的bug。後來發現需要清除掉chrome的cookie。
直接點Application -> Cookie:刪除下面的cookie是不行的。清理不掉全部的cookie，需要到Application -> clear storage中，clear site data才可以。最終成功
相關推薦：
jQuery中的方法有哪些?jQuery中常用的方法（附程式碼）
以上是nodejs中http代理程式庫http-proxy常見的問題分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
