簡介：?簡潔，又能觸達痛點的一站式前端代理解決方案，你值得擁有。

作者：寒斜

說到前端代理，相信每一個做過前后端聯調的同學都有遇到過。當下涉及前后端工程項目的研發，主流模式一定是前后端的分離。它讓前后端的角色分工更加明確，對項目的研發質量提供了更好的保障。但同時也帶來了諸多調試上的不便。

我們這里以 web 開發為例， 前后端工程分開，并且開啟了各自的服務，前端的服務主要是為了方便前端開發實時觀測所寫代碼的呈現結果，這里為了保障更加真實的工程效果，我們希望優先走真實的后臺接口拿數據，但因為瀏覽器自身的跨域限制，前端無法直接讓從瀏覽器發起的請求 到達后端的服務器。

這個時候就必須加入一層代理的能力，幫助我們解決跨域的問題。

解決的方法很簡單，只需要在 webpack 里面配置一下代理的地址，就可以開始前后端聯調之旅了。可是……多數情況下，聯調的情況往往比單純的后端給你提供一個 ip 地址要復雜。

你可能要面對這樣的情景

情景 1

后端的工程一般需要對接口增加一些限制，像登錄認證多數情況下是必不可少的，這時候你直接配置代理的服務地址并發起請求，往往會收到這樣的提示：

情景 2

1 對多，很真實的例子。現在的項目組的研發配比一般都是一個前端對多個后端，后端同學并發開發，到跟前端聯調的時候轉為并行，這個時候我們可能會遇到 每個后端同學針對自己的服務都做了一個不同的服務部署，因為還沒有到最終大家把代碼合并，并且放到一個服務地址讓前端聯調的階段，這個時候前端只能不停的切換代理。

情景 3

除了登錄驗證的情況，還有比較特殊的就是，我們的后端服務被隱藏到了堡壘機的后面。相當于安全驗證的等級又提高了一層，像我們客戶的專有云環境就是這種。這個時候普通的代理設定包括使用 host 就沒有辦法解決了。

你可能的解決方案

情景 1 的解決方案

繞過登錄權限的法子很簡單-按照正常方式登錄，從接口獲取cookie信息，然后用某些方式讓你的本地請求帶上這段cookie，讓服務端識別通過即可。這時候如果測試服務端是以域名方式提供服務，你可以引入 ihosts這種 host管理工具，并且配置好本地ip 跟測試服務域名的映射，激活他就行，因為相同域名不同端口是可以共享cookie的，所以可以順利訪問到。但是，如果測試服務只提供ip訪問，又設定了登錄驗證，這個時候就沒法通過綁定host的方式實現cookie傳輸了，我們會想到webpack,但是非常遺憾的是 webpack 的cookie 設定比較復雜，通過搜索學習搞定這件事的時間往往會很長，而且你可能需要不停的是錯最終才有可能達到成功的結果。顯然，對于一個調試的小小需求來說這個代價還是有點大。

情景 2 的解決方案

設定多個代理配置，對應不同開發環境的時候進行切換，不過需要重新啟動項目，還得自己寫邏輯判斷具體環境的差別。

情景 3 的解決方案

利用某些現有的代理工具，比如 Charles，PostMan。chrome 插件 SwitchyOmega 等，PostMan,SwitchyOmega 更適合后端模擬發起請求測試自己的接口， Charles 比較全面，可以用來抓包，也可以用來做代理調試，但是配置起來相對復雜。或者熟悉nginx 的同學可以用nginx做代理實現，但對于新手而言以上這些方式實現可調通代理的成本還是太高了。

到底怎樣才能 5 分鐘解決前后端聯調問題？

那究竟有沒有更好的即簡潔，又能觸達痛點的一站式解決方案呢，答案是必須有，這里給大家推薦提款 利器 -?Alibaba CloudTookit vscode 插件版。插件的安裝非常方便打開 vscode ，選中插件面板，搜索 “Alibaba Cloud Tookit”選中并安裝即可。

接下來就用實際的例子給大家看看 CloudTookit 相關的“療效”。

真實部署環境前段聯調

很多情況下前端研發希望在更加貼近真實的環境中做聯調，遇到問題的時候我們需要在類似預發這種環境中進行本地聯調測試，這個時候勢必會遇到較為嚴格的鑒權問題，比如我們現在聯調某款云產品的預發環境，需要拿到 sec_token，并且需要把登錄驗證的 cookie 也拿到才能通過校驗 ，但是我們都知道，常規的 webpack 代理對鑒權的設置并不直接友好。

接下來演示帶鑒權的聯調效果，預發環境 host: xx.xxx.xxx.xx mse.console.aliyun.com ，登入控制臺

未配置代理前我們看看本地啟動的效果：

可以看到數據不通。接下來直接用 Cloud Tookit 快速搞起來：

點擊查看視頻

總結下來，代理鑒權調試只要分三步：

1.登錄，拿到cookie, sec_token (注意保護鑒權數據的安全性)

2.打開vscode ,選中cloud tookit proxy，創建代理配置并粘貼cookie，保存并激活該代理

3.復制代理host ，替換webpack的代理配置，啟動項目即可

多環境對接聯調

PTS 是阿里云一款云上專門用來做性能測試的產品，目前有新老兩個版本的迭代開發需求，每個版本都分別有一個預發環境和線上環境，前端開發本身的代理跟代碼耦合，管理和切換都不方便。

老版本：pre-pts.aliyun.com, pts.aliyun.com
新版本：pts.console.aliyun.com 通過不同host 切換預發和線上

因為某些特殊功能現在又增加一個 pre-s.pts.aliyun.com 新的域，也就是說同一套前端工程代碼可能需要對接至少 5 個的聯調環境，對于開發來講其實還是很痛苦的，但是使用 Cloud Tookit 插件會有完全不同的體驗。

根據相應的域名我們打開CloutTookit 插件進行設置,為了做效果區分我取不同賬號的 cookie

proxy1 - 取完整 的pts賬號 cookie 1
proxy2- 取不完全授權的賬號 cookie 2

?

先開啟用 proxy 1 指向 pre-pts.aliyun.com，這個時候 proxy 1 用的cookie 賬號是主賬號，數據比較全，我們把代理配置到項目里，啟動項目看一下效果：

點擊視頻查看效果

接下來我們不重啟項目的情況下，切換第二套 pre-s.pts.aliyun.com，這套用的賬號沒有足夠權限，數據也不多，我們打開 proxy2, 然后直接瀏覽器執行刷新看看結果：

可以看到，非常完美的實現了聯調環境的切換，中間不需要進行項目重啟。

專有云環境聯調

由于本地環境的限制，某些項目的功能只能到真實的環境中去驗證。真實環境對安全的要求比較高，往往會采用堡壘機進行內部服務的轉發，這個時候通常的代理方式就會失效，無法進行本地跟線上的聯調工作，項目的推進效率大大降低。

說明：對于有堡壘機的訪問本身就比較麻煩，需要先通過瀏覽器代理軟件進行設置

然后通過瀏覽器訪問具體服務的域名，比如 aa.bb.cc (之前還有個登錄的環節)。接下來瀏覽器會先把請求打到指定的堡壘機代理，由堡壘機進行內部分發傳達到具體的服務。本地想要聯調依然是繞不開響應的驗證，當我們登錄好之后，取上驗證的cookie, 接下來就是 CloudTookit 繼續發威了。

首先登入系統：

訪問正式頁面獲取 cookie：

打開插件進行服務地址和堡壘機地址設定：

然后保存并激活代理，將本地的代理服務地址替換項目里的代理地址：

啟動項目，見證驚喜：

使用感受

疫情期間，我們做一個專有云的項目（跟公網不直接相通），遇到的就是堡壘機這種復雜場景，我們最開始沒辦法。登錄到標準環境后頁面上去點擊判斷問題的根源，soureMap 只能幫我們快速定位問題，沒法改動后再去驗證。只能線上看到問題，然后代碼里改好后打包扔給后端同學重新部署，一來一回往往要 3 個多小時，可想而知這效率多么低下。業務倒逼著我們去做這樣代理能力的研究。后面直接可以連到專有云環境，本地代碼調試，遇到問題秒修改秒驗證，效率大大的提了上去，也完美保障了項目的正常交付。

有次我們一個同學跟我講，我們的聯調環境又變了，這個該怎么辦？我直接把CT甩給他分分鐘就幫他搞定了。

最后

CloudtTookit 一直致力于為開發者提供高效率的開發服務，本身產品的功能是來自于廣大開發者的真實需求。真心推薦大家收藏 CloudTookit 這款小插件，不管你是做普通的項目聯調，或是有其他的聯調需求，它都可以幫你完美解決問題。如果大家有什么好的建議或者想法都可以提給我們，對好的建議我們一定會認真考慮，我們之前也享受到很多開發者社區的服務，現在也希望盡力回饋給開發者社區。一起豐富完善整個開發者生態的基礎設施。

總結

以上是生活随笔為你收集整理的5 分钟解决前后端联调问题，说一说前端代理这件事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。