前端經常需要一些特殊的調試環境，這時有一個科學的 Web 調試代理工具（以下稱代理工具）顯得尤其重要
我用的第一個代理工具是 Charles，功能多但缺點也很明顯，笨重、配置麻煩，爬
後來換到了 Zan Proxy
Zan Proxy 是一個 Node.js 編寫的代理工具，跟大雜燴 Charles 不一樣，專注於 Web 調試，輕量、配置方便，雖然功能很簡單，但對我來說夠用了
配置都是在一個 Web 頁進行，界面很舒服，我用它做一些簡單的轉發請求、修改響應頭、mock 數據
但隨著工作內容的發展，需要的調試環境也越來越複雜，Zan Proxy 已經慢慢不能滿足我的需求
LightProxy 適時地出現在了我的視野
LightProxy 是一款基於 whistle 的本地代理抓包軟件（其實直接用 whistle 也差不多
下面通過一些我自己使用的規則來介紹它
請求轉發
player.bilibili.com http://127.0.0.1:8080
^*s1.hdslb.com/bfs/static/player/main/video*.js file:///Users/diygod/Code/bilibili/js-common/packages/video/dist/release/video.js
^*s1.hdslb.com/bfs/static/player/main/video*.js.map file:///Users/diygod/Code/bilibili/js-common/packages/video/dist/release/video.js.map
（1）項目接口和 CDN 都被限制某些域名可以用，所以需要這樣一個東西做開發環境
比用 webpack 開一個 80 端口的 server 再綁 hosts 優雅 80 倍
（2）可以用來代理線上文件
把本地編譯好的項目文件代理到真實線上環境，這裡用到了通配符來匹配路徑
修改響應內容
m.bilibili.com resAppend://`
<script src="https://cdn.jsdelivr.net/npm/eruda"></script>
<script>eruda.init();</script>
`
修改移動端頁面的響應內容，讓頁面加載調試工具 Eruda，方便移動端調試
值得一提的是 whistle 有個很神經病的地方，whistle 本身並不支持這樣的行內寫法，需要很麻煩地在另一個面板設置 {key} 或者使用本地文件
所以 LightProxy 做了一層轉義，把行內代碼保存成了一個臨時文件，打開 whistle 可以看到實際發給 whistle 的配置是類似這樣的
m.bilibili.com resAppend:///var/folders/_l/hbcxcqh522s_vls68417h2m40000gn/T/lightproxy/0-152.txt
修改響應頭
/.*bilivideo\.com\/.*300(\d){2}\.m4s/ resHeaders://`{
'x-service-module': 'test-video'
}`
/.*bilivideo\.com\/.*302(\d){2}\.m4s/ resHeaders://`{
'x-service-module': 'test-audio'
}`
/.*bilivideo\.com\/.*\.flv/ resHeaders://`{
'x-service-module': 'test-flv'
}`
這裡用了正則來給不同類型的文件匹配不同的規則
修改 cookie
m.bilibili.com/video/ resCookies://`{
ab: '0000test',
}`
在移動端修改 cookie 並不是那麼方便，所以我用了這個規則，本質上是修改響應頭的 Set-Cookie
host 轉發
172.22.33.166 s1.hdslb.com player.bilibili.com static.hdslb.com
除了支持各種匹配模式，還支持傳統 hosts 語法規則，SwitchHosts 可以扔掉了
模擬網絡異常
*.bilivideo.com replaceStatus://403 includeFilter://m:get
*.bilivideo.com resSpeed://2000
*.bilivideo.com resDelay://3000
各種模擬網絡異常的功能深深戳中了我的痛點
例子中的 *.bilivideo.com 匹配 bilibili 視頻 CDN 地址
（1）模擬 CDN 狀態碼，用來調試 CDN 地址超時或異常，沒有 LightProxy 的日子裡只能在代碼裡 mock 或很蠢地等很久等視頻地址超時
（2）模擬慢速，用來調試卡頓或自動清晰度切換，可以用來代替 Chrome Network Throttling
（3）模擬 CDN 請求超時，用來調試 CDN 拉流超時，沒有 LightProxy 的時候只能小心翼翼地控制 Chrome Network Throttling，太小了會導致請求失敗，太大了超時又不夠長
Node.js 規則
LightProxy 還有一個很酷的功能，使用 Node.js 書寫規則，以下是官方的一個 demo，我暫時還沒有這個功能的使用場景，但就是感覺很酷
github.com/alibaba/lightproxy scriptfile://`
exports.handleRequest = async (ctx, next) => {
// do sth
// ctx.fullUrl 可以獲取請求url
// ctx.headers 可以獲取請求頭
// ctx.options 裡面包含一些特殊的請求頭字段，分別可以獲取一些額外信息，如請設置的規則等
// ctx.method 獲取和設置請求方法
// const reqBody = await ctx.getReqBody(); 獲取請求body的Buffer數據，如果沒有數據返回null
// const reqText = await ctx.getReqText(); 獲取請求body的文本，如果沒有返回''
// const formData = await ctx.getReqForm(); 獲取表單對象，如果不是表單，返回空對象{}
// ctx.req.body = String| Buffer | Stream | null，修改請求的內容
// next方法可以設置next({ host, port });
// 只有執行next方法後才可以把正常的請求發送出去
const { statusCode, headers } = await next();
// do sth
// const resBody = yield ctx.getResBody();
// const resText = yield ctx.getResText();
// ctx.status = 404; 修改響應狀態碼
// ctx.set(headers); 批量修改響應頭
// ctx.set('x-test', 'abc'); 修改響應頭
// ctx.body = String| Buffer | Stream | null; 修改響應內容
ctx.body = 'test';
};`
從以上例子中相信大家已經對 LightProxy /whistle 的用法有了自己的理解
最後還有一個值得一提的事情是，用了這些調試代理工具之後魔法上網怎麼辦？
調試和魔法上網用的是不同的代理，我是一個面向 Google 編程的人，代理一直切來切去太麻煩，我的做法是系統代理交給 Surge 接管，利用 Surge 分流，新建一個 LightProxy 代理，然後編輯 Surge 規則，只把需要調試的請求分給 LightProxy
以上就是我目前的 Web 調試代理實踐