從手動改 Header 到腳本自動化：ProxyPin 如何接進我的移動端調試工作流

ProxyPin 是什麼，能幹嘛，適合誰

ProxyPin 是一款跑在 Android 上的網路抓包工具——它通過 VPN 模式攔截手機上所有 App 的 HTTP/HTTPS 請求與回應，並且能夠解讀加密流量。簡單說，就是把手機上「看不見的網路請求」變成可讀的明文，讓你看到 App 在什麼時候、用什麼參數、向哪個服務器發了什麼數據。

它的獨特之處不止在抓包本身。ProxyPin 內建了一個 QuickJS 腳本引擎，提供 onRequest / onResponse 兩個鉤子，能在請求發出前和回應收到後執行自定義邏輯；工具箱還內建了 URL 編解碼、Base64、Unicode 轉義、MD5、正則測試、二維碼生成等輔助功能。這些加在一起，覆蓋了移動端調試流程中大部分單點工具的需求。

適合誰？移動端開發者、測試人員、任何需要觀察 App 網路行為的人——特別是那些經常需要在模擬器裡反覆驗證接口調試場景的人。更多功能細節可以參考 ProxyPin官網 的完整指南。

安裝

ProxyPin 是 Android APK，35.69M，當前版本 1.3.0。安裝分兩種場景，各自不同：

真機安裝：直接 ProxyPin下載 APK 安裝就行，首次啟動需要授予 VPN 權限。但 Android 7.0 之後有個麻煩——系統預設不信任用戶自己安裝的證書，HTTPS 流量只能看到加密的亂碼。要解決這個，真機得先 root，然後在 ProxyPin 裡打開「HTTPS 代理」→「安裝根證書」，把匯出的證書文件移到 /system/etc/security/cacerts/，還要用 openssl 計算 hash 值後重命名成 {hash}.0 格式（例如 abcd1234.0），不然 Android 系統不认。

模擬器安裝（雷電 / 夜神 / MuMu / BlueStacks）：這是我推薦的場景。主流 Android 模擬器默認自帶 root 權限，安裝 APK 後直接把證書拖進系統目錄就能生效，不用額外開 ADB 或手動修改權限。唯一要注意的是網路模式——NAT 模式下模擬器和電腦不在同一個區網，ProxyPin 掃碼連接桌面端時會失敗，要切到橋接模式，或者讓模擬器連電腦開的熱點。

首次啟動必須做的事：一定要在 HTTPS 代理設置裡點「安裝根證書」，並打開「啟用 HTTPS 代理」開關。跳過這一步的話，你只能攔截到加密的亂碼，調試等於白跑。

舊流程：一個問題下來的 7 次 App 切換

說說以前我是怎麼做移動端接口調試的——這條鏈跑起來大概是這樣：

手機開代理 → Charles 抓包 → 發現要改 Header 注入一個臨時測試 Token → 手動打開 App 重新觸發請求（或者用 mitmproxy 的 map_local，還要額外寫一份靜態配置文件）→ 抓到的請求體是 Base64 密文看不懂 → 切到另一個解碼 App 粘貼轉換 → 要把回應數據發給後端同事排查 → 手機截圖 + 微信發送。

算一下，一個調試問題下來至少 7 次 App 切換，15~20 分鐘，還有兩個讓人頭大的重複勞動：每次重開模擬器都要重新裝一遍證書（以前沒注意預裝系統目錄），以及每次換 Token 都要手動改 Header。這些動作本身不難，但反覆做的時候會讓整個調試節奏被打斷。

新流程：把 ProxyPin 接進鏈條

把 ProxyPin 嵌進來之後，這條鏈被壓縮了。我重新畫了一遍，流程變成：

1. 模擬器啟動（證書預裝系統目錄，零手動操作）
2. ProxyPin 自動掃碼連接桌面端配置
3. QuickJS 腳本的 onRequest 鉤子自動注入測試 Token（邏輯寫一次，永久生效）
4. 編碼數據在工具箱裡直接轉換（不用切 App）
5. 回應數據用二維碼生成器快速分享給同事

全程 2~3 次操作，3~5 分鐘就能跑完一次完整的請求修改→驗證→協作鏈條。上下游配合的工具也很簡單：模擬器作為運行環境、腳本引擎替代手動改 Header、工具箱替代散碎的解碼工具、二維碼生成器替代手機截圖+微信的分享流程。

兩個最容易斷鏈的環節

流程拼接完不代表一路順風。我實際跑了幾週之後，發現兩個地方最容易讓這條鏈斷掉：

模擬器證書的 hash 重命名

Android 系統證書目錄要求文件名必須是 {hash}.0 格式，其中 hash 值要用 openssl x509 -inform PEM -subject_hash_old -in proxypin.crt 命令計算得到。我第一次裝模擬器證書的時候，直接把 ProxyPin 匯出的 .crt 文件拖進 /system/etc/security/cacerts/ 目錄就重啟了，結果整個下午都在懷疑是不是 ProxyPin 版本有問題、是不是模擬器的 root 沒開好，最後才發現是忘了做 hash 重命名。這一步不做，Android 系統就不认這個證書，HTTPS 流量照樣是亂碼。

流程裡把這個動作前置：模擬器第一次安裝 ProxyPin 時就把證書重命名好放進系統目錄，之後重開模擬器不需要再動。

QuickJS 腳本的 context.storage 跨調用

onRequest 鉤子會在每個請求發出前被調用，但同一個腳本的 context 對象在所有調用之間是共享的——context.storage 可以用來保存跨請求的臨時數據。比如我寫一個腳本，第一次請求時從回應裡解析出一個臨時 Token，存進 context.storage['temp-token']，之後的每個請求就自動從 storage 讀出來注入 Header。這樣測試場景下要換 Token 不用手動改每次請求，邏輯封裝在腳本裡一次搞定。

但 context 有個容易忽略的坑：如果 onRequest 返回 null，請求會直接被屏蔽，不會發送到服務器。寫腳本的時候如果邏輯分支裡不小心 return null 掉，會以為是服務器掛了或者接口有問題，排查起來很費勁。我的做法是在腳本開頭固定加一行註釋 // 不要在 onRequest 裡 return null，提醒自己。

效果與邊界

效果：每個調試問題平均節省 12 分鐘，App 切換從 7 次降到 2 次以內。腳本自動注入 Token 這個動作，以前每次都要手改 Header，現在寫一次永久生效。模擬器證書預裝之後，重開模擬器零手動操作。

這套流程什麼時候不划算？只有在需要動態邏輯的場景才值。如果只是固定的 URL 重定向、靜態 Header 注入，用 ProxyPin 自帶的「請求重寫」配置更簡單——不用寫腳本，幾個下拉選單就搞定。非 root 真機的證書安裝還是麻煩，這種情況下模擬器優先。還有，QuickJS 雖然輕量，但複雜邏輯寫多了性能不如原生請求重寫，腳本控制在幾行以內是最佳實踐。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。